By simply removing WINED3DFMT_FLAG_DEPTH_STENCIL from
WINED3DFMT_S1_UINT_D15_UNORM and WINED3DFMT_S4X4_UINT_D24_UNORM. That's also
the only way these formats could be used by GL, so this allows us to remove
them from format_texture_info[] completely.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This quirk only affects fixed-function fragment processing, which hasn't
been a supported configuration on the affected hardware for a while now.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
WINED3D_RTYPE_NONE checks both 2D and 3D resource capabilities, but has
special handling for 3D depth/stencil capabilities. For
WINED3D_RTYPE_TEXTURE_3D, WINED3D_BIND_DEPTH_STENCIL is not an allowed bind
flag, so we never get here. This fixes a regression introduced by commit
9b8847ed7b.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is easy, and sufficient in a lot of cases. However, for a more
complete implementation, we'll want to do something more similar to
vkd3d.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
To indicate whether WINED3D_BIND_DEPTH_STENCIL is valid for the format.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The idea is to get rid of the WINED3DFMT_FLAG_DEPTH and
WINED3DFMT_FLAG_STENCIL format flags, and instead introduce a flag similar to
WINED3DFMT_FLAG_RENDERTARGET that indicates whether the format can be used
with WINED3D_BIND_DEPTH_STENCIL.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This used to protect against accessing the framebuffer state on the no3d
adapter; that's no longer a concern.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When this was introduced in commit 401e99b0c0,
it protected against calling the equivalent of context_acquire() on the
equivalent of the no3d adapter. Commit
94d33d3e86 removed the call in question.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We require an implicit swapchain, so "d3d_initialized" is always true.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The main issue this addresses is that WINED3D_RESOURCE_ACCESS_GPU implies that
WINED3D_LOCATION_TEXTURE_RGB makes sense as a location for the texture.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Like we do in adapter_gl_uninit_3d() and adapter_vk_uninit_3d().
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Like the other blitters. When the GLSL blitter was introduced, the idea was
that caller would be responsible for doing this, but we never ended up
updating the other blitters.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49251
Signed-off-by: Paul Gofman <pgofman@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise we might try to bind a NULL buffer if the index buffer was not
previously loaded.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of to vkGetPhysicalDeviceFeaturess2KHR(), which doesn't
typically exist.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Henri Verbeet