question: can barriers synchronize memory accesses across workgroups

[dneto0]

From a question on the matrix chat.

How do storageBarrier and workgroupBarrier work across workgroups? My assumption is that workgroupBarrier only applies to a single workgroup, but does storageBarrier span all workgroups in a dispatch? ie if I do x.dispatchWorkgroups(1024,1024,1024), will all 1073741824 workgroups be run until the storage barrier and then resumed after the last one hits it?

[dneto0]

In short: workgroupBarrier and storageBarrier cannot be used to synchronize memory accesses between different workgroups.

From the spec, see https://www.w3.org/TR/WGSL/#scoped-operations and https://www.w3.org/TR/WGSL/#sync-builtin-functions and the last bit of https://www.w3.org/TR/WGSL/#compute-shader-workgroups (where the spec says workgroups execute independently in the sense that one workgroup can't block another workgroup).

In hopefully more digestible terms:

• a workgroupBarrier: coordinates the following among all invocations in the current workgroup:

  • memory writes to variables in workgroup address space complete, e.g. writes that were initiated actually land in the workgroup address space memory.
  • then all the invocations in the workgroup wait for each other to arrive at the barrier, i.e. this step.
  • then all the invocations int he workgroup begin executing after the barrier, and any writes to workgroup address space that were made before the barrier are now visible to any invocation in this workgroup.

• storageBarrier is the same but change "workgroup address space" to "storage (buffer) address space". But the set of invocations that are collaborating is still only the invocations in the same workgroup.

• There is no guarantee about using barriers alone to make the writes to storage buffer in one workgroup become visible to invocations in a different workgroup.

Why does WGSL have this limitation.
- This is a limitation in Metal. See #2297
- HLSL provides two variations of memory barriers for the equivalent of WGSL storage buffers: DeviceMemoryBarrier and DeviceMemoryBarrierWithGroupSync. WGSL's storageBarrier is like DeviceMemoryBarrierWithGroupSync
- Vulkan SPIR-V's barriers support "memory scope" of Device or QueueFamily, which is how you can synchronize across workgroups. To synchronize only across workgroup, use only Workgroup "memory scope".

Atomics are a different story. They can provide visibility and availability guarantees in storage address space and across workgroups.

From https://www.w3.org/TR/WGSL/#atomic-types

Atomic types in the workgroup address space have a memory scope of Workgroup, while those in the storage address space have a memory scope of QueueFamily.

Think of "QueueFamily" as device-wide.

I hope I got all that right, and I hope that's helpful.

[kdashg]

If we want to put this explanation in the spec, this becomes editorial?

[dneto0]

I lean against. There is so much more required to explain than this well. E.g. a synchronization chain through barrier -> atomic -> atomic -> barrier.
Also the above is very hand-wavy: What does it mean for a memory operation to "complete", or "land".
And I'd rather not mention some platforms in the spec.

[kdashg]

WGSL 2023-03-07 Minutes

• DN: Could have a bunch of examples of what works what doesn’t, but htat’s more like a blog post. If committee wants something like this, we can write it, but it’s not really spec material.
• AB: Sounds more like programmer’s guide rather than spec.
• KG: Over time, make it a “Discussion” for this kind of thing. That’s where we’ll put things like this.
• converted the issue to Discussion.