Name Strings

SPV_EXT_long_vector

Contact

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

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

Contributors

  • Jeff Bolz, NVIDIA

Notice

Copyright (c) 2025 The Khronos Group Inc. Copyright terms at http://www.khronos.org/registry/speccopyright.html

Status

  • Approved by the SPIR-V Working Group: 2025-10-29

  • Approved by the Khronos Board of Promoters: 2025-12-12

Version

Last Modified Date

2025-10-13

Revision

1

Dependencies

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

This extension requires SPIR-V 1.3.

This extension interacts with SPV_KHR_physical_storage_buffer.

Overview

This extension adds support for vector types with an arbitrary positive number of components, and for a number of components taken from a specialization constant. These new vector types can be used with any instructions that act on vector types with an unrestricted number of components, but support a limited set of storage classes.

This extension shares some functionality (OpTypeVectorIdEXT) with SPV_NV_cooperative_vector. It is intended to be a compilation target for GL_EXT_long_vector (GLSL) and https://github.com/microsoft/hlsl-specs/blob/main/proposals/0026-hlsl-long-vector-type.md (HLSL).

Extension Name

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

OpExtension "SPV_EXT_long_vector"

Modifications to the SPIR-V Specification, Version 1.6

2.16 Validation Rules

Modify section 2.16.1. Universal Validation Rules:

  • Vector types with more than four components (or types containing them) can only be allocated in Function, Private, Uniform, Workgroup, StorageBuffer, PhysicalStorageBuffer, PushConstant, ShaderRecordBufferKHR, CrossWorkgroup, and Generic storage classes.

  • Matrix types must be parameterized only with OpTypeVector having 2, 3, or 4 components.

3.31 Capabilities

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

Capability Implicitly Declares

5425

LongVectorEXT
Enables vector types with more than four components, one component, and OpTypeVectorIdEXT.

3.56.6 Type-Declaration Instructions

Modify OpTypeVector to allow a Component Count of 1.

OpTypeVectorIdEXT

Declare a new vector type with Component Count components of the requested scalar type.

Component Type is the type of each component in the resulting type. It must be a scalar type.
Component Count is the number of components in the resulting type. Component Count must be a constant instruction with scalar 32-bit integer type. It is treated as an unsigned value and must be greater than zero.

Capability:
LongVectorEXT

4

5288

Result <id>

<id>
Component Type

<id>
Component Count

3.56.12 Composite Instructions

Modify OpCompositeConstruct to remove the following sentence:

If constructing a vector, there must be at least two Constituent operands.

Modify OpVectorExtractDynamic, OpVectorInsertDynamic, OpVectorShuffle, to change restrictions from "must be an OpTypeVector" or "must have a type OpTypeVector" to "must be/have a vector type".

Issues

  1. How can a shader construct a vector with number of components defined by a specialization constant?

    RESOLVED: Use the instructions in SPV_EXT_replicated_composites to construct a vector with the same value replicated for all components.

  2. Which instructions support the new vector types?

    RESOLVED: Unless otherwise stated, any instruction that claims to support vector types and doesn’t have a specific limitation on the number of components (for example, GLSL.std.450 Cross requires exactly three components) supports vectors with more than four components, one component, and vectors created using OpTypeVectorIdEXT. This includes GLSL.std.450 instructions.

  3. Should OpVectorShuffle support vectors with more than four components or OpTypeVectorIdEXT?

    RESOLVED: OpVectorShuffle has a similar problem to the other composite instructions where the number of operands must match the number of components, and this makes it awkward to work with OpTypeVectorIdEXT. Also, the high level language exposure of shuffle (swizzles) doesn’t naturally extend to more components, though it is not hard to imagine a new intrinsic to expose this. Practically speaking, it’s hard to draw a line for what not to support, and this could be useful in the future, so it is supported.

  4. Do we need to forbid spec-constant-sized vectors in explicitly laid out storage classes?

    RESOLVED: Vulkan has a restriction for spec-constant sized arrays, a similar restriction will apply to spec-constant-sized vectors.

Revision History

Rev Date Author Changes

1

2025-10-13

Jeff Bolz

Initial revision of SPV_EXT_long_vector