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.
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 succeeds with the Vulkan renderer.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
ID3DDeviceContextState_GetPrivateData() takes an UINT parameter, not a DWORD.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a black screen in The Unfinished Swan.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
