wine/vkd3d
0
0
Fork 0
mirror of https://gitlab.winehq.org/wine/vkd3d.git synced 2025-12-15 08:03:30 -08:00
Code Issues Packages Projects Releases Wiki Activity

vkd3d-shader/dxil: Ignore ORDERING_SEQCST.

Browse Source 
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.
This commit is contained in:
Henri Verbeet
2025-10-08 16:24:44 +02:00
parent 0bfed6587a
commit 32a6967778
Notes: Henri Verbeet 2025-10-09 15:57:49 +02:00 
Approved-by: Giovanni Mascellani (@giomasce)
Approved-by: Henri Verbeet (@hverbeet)
Merge-Request: https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/1779
4 changed files with 9 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
libs/vkd3d-shader/dxil.c
View File

@@ -4467,6 +4467,8 @@ static void sm6_parser_emit_atomicrmw(struct sm6_parser *sm6, const struct dxil_
/* It's currently not possible to specify an atomic ordering in HLSL, and it defaults to seq_cst. */
if ((code = record->operands[i++]) != ORDERING_SEQCST)
FIXME("Unhandled atomic ordering %"PRIu64".\n", code);
else
WARN("Ignoring atomic ordering %"PRIu64".\n", code);
if ((code = record->operands[i]) != 1)
WARN("Ignoring synchronisation scope %"PRIu64".\n", code);
@@ -4484,7 +4486,7 @@ static void sm6_parser_emit_atomicrmw(struct sm6_parser *sm6, const struct dxil_
ins = state->ins;
vsir_instruction_init(ins, &sm6->p.location, op);
ins->flags = is_volatile ? VKD3DARF_SEQ_CST | VKD3DARF_VOLATILE : VKD3DARF_SEQ_CST;
ins->flags = is_volatile ? VKD3DARF_VOLATILE : 0;
if (!(src_params = instruction_src_params_alloc(ins, 2, sm6)))
return;
@@ -7326,6 +7328,8 @@ static void sm6_parser_emit_cmpxchg(struct sm6_parser *sm6, const struct dxil_re
/* It's currently not possible to specify an atomic ordering in HLSL, and it defaults to seq_cst. */
if (success_ordering != ORDERING_SEQCST)
FIXME("Unhandled success ordering %"PRIu64".\n", success_ordering);
else
WARN("Ignoring success ordering %"PRIu64".\n", success_ordering);
if (success_ordering != failure_ordering)
FIXME("Unhandled failure ordering %"PRIu64".\n", failure_ordering);
@@ -7333,7 +7337,7 @@ static void sm6_parser_emit_cmpxchg(struct sm6_parser *sm6, const struct dxil_re
FIXME("Ignoring weak cmpxchg.\n");
vsir_instruction_init(ins, &sm6->p.location, VSIR_OP_IMM_ATOMIC_CMP_EXCH);
ins->flags = is_volatile ? VKD3DARF_SEQ_CST | VKD3DARF_VOLATILE : VKD3DARF_SEQ_CST;
ins->flags = is_volatile ? VKD3DARF_VOLATILE : 0;
if (!(src_params = instruction_src_params_alloc(ins, 3, sm6)))
return;