SPV_INTEL_device_barrier

RESOLVED: Strictly speaking the "device barrier" described by this extension is only synchronizing the work-items in the current dispatch or ND-range, and not all work-items that may be executing on a device from other dispatches Using "device" does seem to be consistent with other uses of "device" in SPIR-V, though, including the Device scope, so we will continue describe the functionality as a "device barrier".

RESOLVED: Currently, there is no interaction, and Device may only be used as a Scope for Execution for an OpControlBarrier instruction. This restriction may be lifted at some point in the future.

RESOLVED: The DeviceBarrierINTEL capability allows the SPIR-V module to contain an OpControlBarrier instruction with Device as the Scope for Execution. An implementation supporting the DeviceBarrierINTEL capability must compile SPIR-V modules containing OpControlBarrier instructions with Device as the Scope for Execution, even if there are scenarios when behavior is undefined if the OpControlBarrier instruction is executed. Without this capability, a SPIR-V module that statically passes Device to OpControlBarrier as the Scope for Execution may be considered invalid, and SPIR-V consumers may assume that a dynamically passed Scope for Execution to OpControlBarrier will never be Device.

Some client APIs may require a kernel to be dispatched in a special way in order for the invocations in a kernel dispatch to synchronize. The DeviceBarrierExecutionValidINTEL built-in indicates whether behavior is defined when an invocation executes an OpControlBarrier instruction with Device as the Scope for Execution, or whether behavior is undefined. All built-in variables decorated with DeviceBarrierExecutionValidINTEL will have the same value for all invocations in a kernel dispatch.