Name Strings

SPV_INTEL_split_barrier

Contact

To report problems with this extension, please open a new issue at:

https://github.com/KhronosGroup/SPIRV-Registry

Contributors

  • Ben Ashbaugh, Intel

Notice

Copyright (c) 2022 Intel Corporation. All rights reserved.

Status

  • Shipping

Version

Last Modified Date

2022-02-24

Revision

1

Dependencies

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

This extension requires SPIR-V 1.0.

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_INTEL_split_barrier"

New Capabilities

This extension introduces the new capability:

SplitBarrierINTEL

Modifications to the SPIR-V Specification, Version 1.6

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

Capability Implicitly Declares

6141

SplitBarrierINTEL

Add to Section 3.42.20, Barrier Instructions:

OpControlBarrierArriveINTEL

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:
SplitBarrierINTEL

4

6142

Scope <id>
Execution

Scope <id>
Memory

Memory Semantics <id>
Semantics

OpControlBarrierWaitINTEL

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:
SplitBarrierINTEL

4

6143

Scope <id>
Execution

Scope <id>
Memory

Memory Semantics <id>
Semantics

Issues

None.

Revision History

Rev Date Author Changes

1

2022-02-24

Ben Ashbaugh

Initial revision