It is illegal to match a SPIR-V multisampled resource to a Vulkan resource which
is not multisampled. Vulkan considers a resource to be multisampled if its
sample count is greater than 1 (and SPIR-V does not care about the sample count).
This fixes validation errors in the case where the sample count does actually
match the resource. In order to provide correct behaviour when there is a
mismatch, or when the sample count is missing, we will need yet another
additional interface. In the absence of that it seems best to provide a best
guess.
This fixes a validation error with the not-yet-committed merge request 135, when
the d3d11 runner is run through Wine with the Vulkan backend.
The SPIR-V backend will emit a default control point phase. Inserting
inputs into the IR allows handling of declarations via the usual path
instead of an ad hoc implementation which may not match later changes
to input handling.
In SPIR-V the address must include the invocation id, but in TPF it
is implicit. Move the register index up one slot and insert an
OUTPOINTID relative address.
Normalise the incoming vkd3d_shader_instruction IR to the shader model 6
pattern. This allows generation of a single patch constant function in
SPIR-V.
Atomic ops on images with Unknown type will cause SPIR-V validation failure,
and assertion failure in Mesa debug builds. D3D12 allows atomics on typed
buffers, and this requires a distinction to be made between UAV reads and
atomic ops.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53874
We would like to generate SPIR-V for input formats other than DXBC.
The "vkd3d_" prefix is dropped, partly to make names shorter, and partly to help
clarify what is an internal function.
I prefer avoiding the vkd3d_* prefix on all internal functions, for these
reasons. However, I'm open to restoring it.
Don't assume that enums and uint32_t parameters are identical. Clang
16 changes the diagonstic for incompatible function pointer types
from a warning into an error by default.
This fixes the following error, when built (for aarch64, but probably
also for other architectures) in MSVC mode:
../src/libs/vkd3d/libs/vkd3d-shader/spirv.c:1083:13: error: incompatible function pointer types passing 'uint32_t (struct vkd3d_spirv_builder *, uint32_t, SpvDim, uint32_t, uint32_t, uint32_t, uint32_t, SpvImageFormat)' (aka 'unsigned int (struct vkd3d_spirv_builder *, unsigned int, enum SpvDim_, unsigned int, unsigned int, unsigned int, unsigned int, enum SpvImageFormat_)') to parameter of type 'vkd3d_spirv_build7_pfn' (aka 'unsigned int (*)(struct vkd3d_spirv_builder *, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int)') [-Wincompatible-function-pointer-types]
vkd3d_spirv_build_op_type_image);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/libs/vkd3d/libs/vkd3d-shader/spirv.c:612:68: note: passing argument to parameter 'build_pfn' here
SpvOp op, const uint32_t *operands, vkd3d_spirv_build7_pfn build_pfn)
^
Signed-off-by: Martin Storsjö <martin@martin.st>
Specifying R32 for UAVs created with a vector format, e.g. R32G32B32A32_FLOAT,
results in only the red being loaded/stored, potentially causing images to
contain only the red component.
Signed-off-by: Conor McCarthy <cmccarthy@codeweavers.com>
