OpenCL global memory visibility limits across work-groups without fences
0 reputation · 14 Jun 2022, 01:52 UTC
Goal
I want a producer work-group to write a result buffer in global memory and have a consumer work-group read that data reliably within the same kernel launch, without stale reads.
Constraints and uncertainty
My understanding of the OpenCL C memory model is that it is relaxed: writes to global memory by one work-item are not guaranteed visible to others without explicit synchronization. Barriers (work_group_barrier / the older barrier() with CLK_GLOBAL_MEM_FENCE) only order execution within a single work-group and do not synchronize across work-groups, which may run on different compute units. The volatile qualifier appears to prevent the compiler from caching a value in a register but does not guarantee hardware cache coherence. This leaves me unsure which mechanism, if any, is sufficient for cross-work-group visibility inside one kernel.
Questions
- Is an atomic store plus an atomic load with appropriate memory order sufficient to guarantee cross-work-group visibility of a global buffer in OpenCL 2.x, or is kernel termination the only reliable boundary?
- Does the answer differ between GPU and CPU devices, or between drivers, in practice?
- Is there a portable way to verify visibility behavior, or must this be treated as implementation-defined?