OpenCL global memory visibility limits across work-groups without fences

Answer to the exact question

In a single kernel launch, the only portable way to guarantee that a write performed by one work‑group is seen by another is to use the OpenCL 2.x atomic store/load pair with memory_order_release and memory_order_acquire and the memory_scope_device (or memory_scope_all_svm_devices if you are using SVM). This establishes a *release/acquire* ordering that, in the formal memory model, makes all preceding non‑atomic writes in the producer work‑group visible to the consumer work‑group after it observes the flag. If the device does not support scoped atomics, or if you are running on OpenCL 1.2 or earlier, the only reliable boundary is kernel termination (or a host‑side event ordering between two kernels).

Confirmed facts

• Work‑group barriers (including barrier(CLK_GLOBAL_MEM_FENCE)) only order work‑items within the same work‑group; they provide no cross‑work‑group visibility guarantees.
• The volatile qualifier prevents compiler caching but does not insert hardware fences or guarantee cache coherence across compute units.
• OpenCL 2.x’s C11‑derived memory model formally defines scoped atomics with memory_order_release/memory_order_acquire and memory_scope_device that can be used to order non‑atomic global memory accesses.
• In practice, many GPU drivers have historically shipped weak or buggy implementations of scoped atomics; the effect can vary between vendors and driver versions.
• CPU devices, which usually have a single coherent cache domain, tend to honour scoped atomics as expected, whereas discrete GPUs with per‑compute‑unit caches are the source of most stale‑read and deadlock issues.

Practical considerations

• Even if the spec guarantees ordering, a consumer that spins on a flag can deadlock if the producer’s work‑group has not yet been scheduled. GPUs may schedule work‑groups in any order or even delay them until later in the launch.
• Use a *cooperative* launch pattern (if supported by the driver) or a host‑side event barrier to ensure the producer runs before the consumer starts spinning.
• Always query CL_DEVICE_VERSION and, for OpenCL 3.x, CL_DEVICE_ATOMIC_MEMORY_CAPABILITIES to confirm that memory_scope_device and release/acquire semantics are available.
• When in doubt, split the producer and consumer into two separate kernels and order them with an event or by using an in‑order command queue. This guarantees visibility regardless of device quirks.

Steps to try on your device

1. Write a minimal kernel that:
   • Producer work‑group writes to a global buffer.
   • Producer stores 1 to an atomic flag with memory_order_release.
   • Consumer work‑group spins on atomic_load_explicit(flag, memory_order_acquire).
   • Consumer reads the global buffer after the flag becomes 1.
2. Run the kernel on your target GPU/CPU and compare the consumer’s read with the expected data.
3. If the consumer sees stale data or the kernel hangs, fall back to the two‑kernel approach with event ordering.

When to ask for more information

If you are unsure whether your device supports scoped atomics, run:

clGetDeviceInfo(device, CL_DEVICE_VERSION, ...);
// For OpenCL 3.x, also query CL_DEVICE_ATOMIC_MEMORY_CAPABILITIES

Share the returned values; they will determine whether the atomic‑store/load pattern is viable or if you must rely on kernel boundaries.