While far from ideal, we can still use swapchain_blit_gdi() to get
back-buffers to the screen.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
I.e., those used with wined3d_cs_init_object() and
wined3d_cs_destroy_object().
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise we may not be able to acquire a context to create the view. In
practice, this is only an issue for d3d9 and earlier in combination with the
Vulkan backend.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This should not change behaviour for d3d9 and earlier, where all formats
have sizes that are multiples of 4.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=43422
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Make stencil reference value dynamic, so it can be updated separately.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50380
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Analogous to the GL backend. The alternative would be to potentially
invalidate STATE_FRAMEBUFFER when changing the depth/stencil state object,
which doesn't seem worth it.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
A typical case would be between using a texture as render target and using it
as a shader resource.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This was deprecated in Wine 5.0, use the "shader_backend" setting instead.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The idea was once to use permanent bo's for textures, similar to how texture
PBOs work in the OpenGL backend. In that case we would have needed to copy to
the correct position in the bo, in order not to modify other parts of the bo.
With the current scheme, the destination offset serves no purpose.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We should simply create 3D views.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50123
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
wined3d_context_vk_init() assumes zero-initialised memory, but that's not
necessarily true in case we previously went through an
adapter_vk_init_3d()/adapter_vk_uninit_3d() pair.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
D3DENUM_NO_WHQL_LEVEL from Direct3D 8 was replaced with D3DENUM_WHQL_LEVEL in
Direct3D 9.
Signed-off-by: Rafał Harabień <rafalh92@outlook.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of comparing the requested memory type against what we actually got.
For example, we may have gotten coherent memory without having explicitly
requested it, in which case wined3d_context_vk_create_slab_bo() would fail to
find an existing slab to allocate from.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In particular, some implementations may not support the combination of
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT and VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
for all buffer types, or at all.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>