Henri Verbeet pushed to branch master at wine / vkd3d
Commits: 32a69677 by Henri Verbeet at 2025-10-09T15:39:41+02:00 vkd3d-shader/dxil: Ignore ORDERING_SEQCST.
More recent versions of the Vulkan/SPIR-V validation layers have started to complain about our usage of "SequentiallyConsistent" in our SPIR-V output. Specifically, VUID-StandaloneSpirv-MemorySemantics-10866 "Memory Semantics with SequentiallyConsistent memory order must not be used in the Vulkan API".
The SPIR-V specification says: "If the declared memory model is Vulkan, SequentiallyConsistent must not be used." However, we're using the GLSL450 memory model with SPIR-V 1.3, and "Vulkan" is not available before SPIR-V 1.5.
The Vulkan specification says "Sequentially consistent atomics and barriers are not supported and SequentiallyConsistent is treated as AcquireRelease. SequentiallyConsistent should not be used." in the "Shader Memory Access Ordering" section.
Those don't quite add up to the "... must not be used in the Vulkan API", from the validation layers, but it does seem clear that SequentiallyConsistent isn't actually supported. On the DXIL side, when targetting SPIR-V with dxc, the generated SPIR-V uses the "None"/"Relaxed" memory semantics. I wasn't immediately able to find a reference for what seq_cst is supposed to mean in the context of DXIL, but "None"/"Relaxed" does seem consistent with how the HLSL atomic/interlocked intrinsics are expected to behave, as well as with our behaviour for tpf shaders.
- - - - -
4 changed files:
- libs/vkd3d-shader/d3d_asm.c - libs/vkd3d-shader/dxil.c - libs/vkd3d-shader/spirv.c - libs/vkd3d-shader/vkd3d_shader_private.h
View it on GitLab: https://gitlab.winehq.org/wine/vkd3d/-/commit/32a69677783498d9ad091cd8d94525...