Creating a view with an unaligned offset is legal in d3d and
apparently works, both on Windows and Linux, but may violate the
Vulkan specification:
VUID-VkBufferViewCreateInfo-offset-00926(ERROR / SPEC): msgNum: -833749292 - Validation Error: [ VUID-VkBufferViewCreateInfo-offset-00926 ] Object 0: handle = 0x3c000000003c, type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0xce4dfed4 | vkCreateBufferView(): VkBufferViewCreateInfo offset (36) must be a multiple of VkPhysicalDeviceLimits::minTexelBufferOffsetAlignment (16). The Vulkan spec states: offset must be a multiple of VkPhysicalDeviceLimits::minTexelBufferOffsetAlignment (https://www.khronos.org/registry/vulkan/specs/1.2-khr-extensions/html/vkspec.html#VUID-VkBufferViewCreateInfo-offset-00926)
Without any reason to test unaligned buffer views here, just resolve this by changing the test.
This is far simpler than drawing with it.
The immediate motivation here is that the DXGI_FORMAT_R8G8B8A8_UINT test causes
a validation error when drawing, since the shader declares its resource as a
float4 texture, which does not match the UINT view format. This could be fixed
by using a different shader, but it seems more prudent to just simplify the test
to not draw at all.
Instead of having d3d11 create the wined3d texture, create it in dxgi instead,
and let d3d11 create a d3d_texture2d object to wrap it.
This is a step towards getting rid of the create_swapchain_texture() callback,
which is mildly difficult to work with and conceptually complex.
Avoid the need for manually set type attributes, and initialize the component
count for all such formats.
This fixes use of R11G11B10_FLOAT as a vertex attribute format with the GL
backend. Since it has no corresponding typeless format, prior to this commit the
component count was uninitialized and hence use of the format would result in a
GL error.
This fixes a GL error with Dark Souls Remastered. I did not immediately observe
any corresponding rendering errors, however.
DISCARD maps on deferred contexts do not seem to offer the same synchronization
guarantees as do DISCARD maps on the immediate context, at least not with
respect to subsequent NOOVERWRITE maps on the immediate context. This is not
particularly surprising, seeing as it is probably far more usual to only map a
resource on one kind of context or the other.
The test currently fails on Windows 11 on NVidia drivers, but it also fails on
Mesa, for what I think are the same reasons.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52563
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54023
Some drivers (AMD Radeon RX 6700 XT, with radeonsi from Mesa 22.2.0-rc3) emit
less than one invocation per pixel, presumably because they detect that the
shader control flow is uniform for all pixels. Having the control flow depend on
SV_Position avoids this test failure.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
There's no point in querying this multiple times, it's not going to change.
Perhaps more importantly, calling is_warp_device() inside a todo_wine block
will cause "Test succeeded inside todo block: ..." messages from
get_device_adapter_desc(). These appear to have been introduced by commit
fcc276ecb1. Arguably get_device_adapter_desc()
shouldn't use ok() in the first place.
This was originally prompted by the fact that
wined3d_extract_shader_input_signature_from_dxbc() allocates elements with
HeapAlloc(), but d3d11_input_layout_to_wined3d_declaration() attempts to free
them with free(). That's a regression introduced by commit
b951c37b87. Since we're touching the code
though, we may as well use vkd3d_shader_parse_input_signature(), and get rid
of wined3d_extract_shader_input_signature_from_dxbc().
This succeeds with the Vulkan renderer.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
