You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Blocks execution of all threads in a group until all group shared accesses have been completed and all threads in the group have reached this call.
groupMemoryBarrier:
Control the ordering of all memory transactions issued within a single shader invocation, as viewed by other invocations in the same work group.
memoryBarrierShared:
Control the ordering of memory transactions to shared variables issued within a single shader invocation.
In GroupMemoryBarrierWithGroupSync there is no mention of shared variables, and instead they refer to all accesses (including shared variables, as well as any other), which to me seems like is equivalent to what groupMemoryBarrier is doing.
Whether I'm interpreting it correctly, I don't know.
Thanks for the quick reply. I'm preparing a couple of compilation results for my thesis.
It looks like XShaderCompiler, glslang/SPIRV-CRoss, and fxc/HLSLCrossCompiler produce different variants for this intrinsic:
XShaderCompiler:
groupMemoryBarrier();
barrier();
glslang/SPIRV-Cross:
memoryBarrierShared();
barrier();
fxc/HLSLCrossCompiler:
groupMemoryBarrier();
memoryBarrierShared();
Maybe all are valid. But I'm uncertain about this :-/
@BearishSun Glslang seems to translate the
GroupMemoryBarrierWithGroupSync
intrinsic into this:But your proposal for the wrapper function translate it into this:
Do you know which of the two approaches are wrong?
Greetings,
Lukas
The text was updated successfully, but these errors were encountered: