Name Strings

SPV_EXT_split_barrier

Contact

See Issues list in the Khronos SPIRV-Headers repository: https://github.com/KhronosGroup/SPIRV-Headers

Contributors

  • Ben Ashbaugh, Intel

Status

  • Approved by the SPIR-V Working Group: 2026-05-13

  • Approved by the Khronos Board of Promoters: 2026-06-26

Version

Last Modified Date

2025-12-18

Revision

1

Dependencies

This extension is written against the SPIR-V Specification, Version 1.6 Revision 6.

This extension requires SPIR-V 1.0.

This is a promotion of SPV_INTEL_split_barrier.

Overview

This extension adds SPIR-V instructions to split a control barrier (OpControlBarrier) into two separate operations: the first indicates that an invocation has "arrived" at the barrier but should continue executing, and the second indicates that an invocation should "wait" for other invocations to arrive at the barrier before executing further.

Splitting a barrier operation may improve performance and may provide a closer match to "latch" or "barrier" operations in other parallel languages such as C++ 20.

Extension Name

To use this extension within a SPIR-V module, the appropriate OpExtension must be present in the module:

OpExtension "SPV_EXT_split_barrier"

New Capabilities

This extension introduces the new capability:

SplitBarrierEXT

Modifications to the SPIR-V Specification, Version 1.6

Modify Section 3.2.30, Capability, adding rows to the Capability table:

Capability Implicitly Declares

6141

SplitBarrierEXT

Add to Section 3.3.20, Barrier Instructions:

OpControlBarrierArriveEXT

Indicates that an invocation has arrived at a split control barrier. This may allow other invocations waiting on the split control barrier to continue executing.

When Execution is Workgroup or larger, behavior is undefined unless all invocations within Execution execute the same dynamic instance of this instruction. When Execution is Subgroup or Invocation, the behavior of this instruction in non-uniform control flow is defined by the client API.

If Semantics is not None, this instruction also serves as the start of a memory barrier similar to an OpMemoryBarrier instruction with the same Memory and Semantics operands. This allows atomically specifying both a control barrier and a memory barrier (that is, without needing two instructions). If Semantics is None, Memory is ignored.

Capability:
SplitBarrierEXT

4

6142

Scope <id>
Execution

Scope <id>
Memory

Memory Semantics <id>
Semantics

OpControlBarrierWaitEXT

Waits for other invocations of this module to arrive at a split control barrier.

When Execution is Workgroup or larger, behavior is undefined unless all invocations within Execution execute the same dynamic instance of this instruction. When Execution is Subgroup or Invocation, the behavior of this instruction in non-uniform control flow is defined by the client API.

If Semantics is not None, this instruction also serves as the end of a memory barrier similar to an OpMemoryBarrier instruction with the same Memory and Semantics operands. This ensures that memory accesses issued before arriving at the split barrier are observed before memory accesses issued after this instruction. This control is ensured only for memory accesses issued by this invocation and observed by another invocation executing within Memory scope. This allows atomically specifying both a control barrier and a memory barrier (that is, without needing two instructions). If Semantics is None, Memory is ignored.

Capability:
SplitBarrierEXT

4

6143

Scope <id>
Execution

Scope <id>
Memory

Memory Semantics <id>
Semantics

Issues

None.

Revision History

Rev Date Author Changes

1

2025-12-18

Wooyoung Kim/Ben Ashbaugh

Initial revision