# Vulkan® 1.4.303 - A Specification (with all registered extensions)

The Khronos® Vulkan Working Group
version 1.4.303, 2024-12-15 00:58:43Z
from git branch: Git branch not available commit: Git commit not available

Loading… please wait.

Search:

## 15. Shader Interfaces

When a pipeline is created, the set of shaders specified in the corresponding `VkPipelineCreateInfo` structure are implicitly linked at a number of different interfaces.

- Shader Input and Output Interface

- Vertex Input Interface

- Fragment Output Interface

- Fragment Tile Image Interface

- Fragment Input Attachment Interface

- Ray Tracing Pipeline Interface

- Shader Resource Interface

- Geometry Shader Passthrough

This chapter describes valid uses for a set of SPIR-V decorations. Any other use of one of these decorations is invalid, with the exception that, when using SPIR-V versions 1.4 and earlier: `Block`, `BufferBlock`, `Offset`, `ArrayStride`, and `MatrixStride` can also decorate types and type members used by variables in the `Private` and `Function` storage classes.

Note | In this chapter, there are references to SPIR-V terms such as the `MeshNV` execution model. These terms will appear even in a build of the specification which does not support any extensions. This is as intended, since these terms appear in the unified SPIR-V specification without such qualifiers.

### 15.1. Shader Input and Output Interfaces

When multiple stages are present in a pipeline, the outputs of one stage form an interface with the inputs of the next stage. When such an interface involves a shader, shader outputs are matched against the inputs of the next stage, and shader inputs are matched against the outputs of the previous stage.

All the variables forming the shader input and output interfaces are listed as operands to the `OpEntryPoint` instruction and are declared with the `Input` or `Output` storage classes, respectively, in the SPIR-V module. These generally form the interfaces between consecutive shader stages, regardless of any non-shader stages between the consecutive shader stages.

There are two classes of variables that can be matched between shader stages, built-in variables and user-defined variables. Each class has a different set of matching criteria.

`Output` variables of a shader stage have undefined values until the shader writes to them or uses the `Initializer` operand when declaring the variable.

#### 15.1.1. Built-In Interface Block

Shader built-in variables meeting the following requirements define the built-in interface block. They must

- be explicitly declared (there are no implicit built-ins),

- be identified with a `BuiltIn` decoration,

- form object types as described in the Built-in Variables section, and

- be declared in a block whose top-level members are the built-ins.

There must be no more than one built-in interface block per shader per interface , except for the mesh output interface where there must be at most one built-in interface block decorated with the `PerPrimitiveEXT` decoration and at most one built-in interface block without this decoration .

Built-ins must not have any `Location` or `Component` decorations.

#### 15.1.2. User-Defined Variable Interface

The non-built-in variables listed by `OpEntryPoint` with the `Input` or `Output` storage class form the user-defined variable interface. These must have numeric type or, recursively, composite types of such types. If an implementation supports `storageInputOutput16`, components can have a width of 16 bits. These variables must be identified with a `Location` decoration and can also be identified with a `Component` decoration.

#### 15.1.3. Interface Matching

An output variable, block, or structure member in a given shader stage has an interface match with an input variable, block, or structure member in a subsequent shader stage if they both adhere to the following conditions:

- They have equivalent decorations, other than:

  - `XfbBuffer`, `XfbStride`, `Offset`, and `Stream`

  - one is not decorated with `Component` and the other is declared with a `Component` of `0`

  - Interpolation decorations

  - `RelaxedPrecision` if one is an input variable and the other an output variable

- Their types match as follows:

  - if the input is declared in a tessellation control or geometry shader as an `OpTypeArray` with an `Element` `Type` equivalent to the `OpType*` declaration of the output, and neither is a structure member; or

  - if the `maintenance4` feature is enabled, they are declared as `OpTypeVector` variables, and the output has a `Component` `Count` value higher than that of the input but the same `Component` `Type`; or

  - if the output is declared in a mesh shader as an `OpTypeArray` with an `Element` `Type` equivalent to the `OpType*` declaration of the input, and neither is a structure member; or

  - if the input is decorated with `PerVertexKHR`, and is declared in a fragment shader as an `OpTypeArray` with an `Element` `Type` equivalent to the `OpType*` declaration of the output, and neither the input nor the output is a structure member; or

  - if in any other case they are declared with an equivalent `OpType*` declaration.

- If both are structures and every member has an interface match.

Note | The word “structure” above refers to both variables that have an `OpTypeStruct` type and interface blocks (which are also declared as `OpTypeStruct`).

If the pipeline is compiled as separate graphics pipeline libraries and the `graphicsPipelineLibraryIndependentInterpolationDecoration` limit is not supported, matches are not found if the interpolation decorations differ between the last pre-rasterization shader stage and the fragment shader stage.

All input variables and blocks must have an interface match in the preceding shader stage, except for built-in variables in fragment shaders. Shaders can declare and write to output variables that are not declared or read by the subsequent stage.

Matching rules for passthrough geometry shaders are slightly different and are described in the Passthrough Interface Matching section.

The value of an input variable is undefined if the preceding stage does not write to a matching output variable, as described above.

#### 15.1.4. Location Assignment

This section describes `Location` assignments for user-defined variables and how many `Location` slots are consumed by a given user-variable type. As mentioned above, some inputs and outputs have an additional level of arrayness relative to other shader inputs and outputs. This outer array level is removed from the type before considering how many `Location` slots the type consumes.

The `Location` value specifies an interface slot comprised of a 32-bit four-component vector conveyed between stages. The `Component` specifies word components within these vector `Location` slots. Only types with widths of 16, 32 or 64 are supported in shader interfaces.

Inputs and outputs of the following types consume a single interface `Location`:

- 16-bit scalar and vector types, and

- 32-bit scalar and vector types, and

- 64-bit scalar and 2-component vector types.

64-bit three- and four-component vectors consume two consecutive `Location` slots.

If a declared input or output is an array of size n and each element takes m `Location` slots, it will be assigned m × n consecutive `Location` slots starting with the specified `Location`.

If the declared input or output is an n × m 16-, 32- or 64-bit matrix, it will be assigned multiple `Location` slots starting with the specified `Location`. The number of `Location` slots assigned for each matrix will be the same as for an n-element array of m-component vectors.

An `OpVariable` with a structure type that is not a block must be decorated with a `Location`.

When an `OpVariable` with a structure type (either block or non-block) is decorated with a `Location`, the members in the structure type must not be decorated with a `Location`. The `OpVariable`’s members are assigned consecutive `Location` slots in declaration order, starting from the first member, which is assigned the `Location` decoration from the `OpVariable`.

When a block-type `OpVariable` is declared without a `Location` decoration, each member in its structure type must be decorated with a `Location`. Types nested deeper than the top-level members must not have `Location` decorations.

The `Location` slots consumed by block and structure members are determined by applying the rules above in a depth-first traversal of the instantiated members as though the structure or block member were declared as an input or output variable of the same type.

Any two inputs listed as operands on the same `OpEntryPoint` must not be assigned the same `Location` slot and `Component` word, either explicitly or implicitly. Any two outputs listed as operands on the same `OpEntryPoint` must not be assigned the same `Location` slot and `Component` word, either explicitly or implicitly.

The number of input and output `Location` slots available for a shader input or output interface is limited, and dependent on the shader stage as described in Shader Input and Output Locations. All variables in both the built-in interface block and the user-defined variable interface count against these limits. Each effective `Location` must have a value less than the number of `Location` slots available for the given interface, as specified in the “Locations Available” column in Shader Input and Output Locations.

Table 19. Shader Input and Output Locations
Shader Interface | Locations Available
--- | ---
vertex input | `maxVertexInputAttributes`
vertex output | `maxVertexOutputComponents` / 4
tessellation control input | `maxTessellationControlPerVertexInputComponents` / 4
tessellation control output | `maxTessellationControlPerVertexOutputComponents` / 4
tessellation evaluation input | `maxTessellationEvaluationInputComponents` / 4
tessellation evaluation output | `maxTessellationEvaluationOutputComponents` / 4
geometry input | `maxGeometryInputComponents` / 4
geometry output | `maxGeometryOutputComponents` / 4
fragment input | `maxFragmentInputComponents` / 4
fragment output | `maxFragmentOutputAttachments`
mesh output | `maxMeshOutputComponents` / 4
cluster culling output | `maxOutputClusterCount`

#### 15.1.5. Component Assignment

The `Component` decoration allows the `Location` to be more finely specified for scalars and vectors, down to the individual `Component` word within a `Location` slot that are consumed. The `Component` word within a `Location` are 0, 1, 2, and 3. A variable or block member starting at `Component` N will consume `Component` words N, N+1, N+2, …​ up through its size. For 16-, and 32-bit types, it is invalid if this sequence of `Component` words gets larger than 3. A scalar 64-bit type will consume two of these `Component` words in sequence, and a two-component 64-bit vector type will consume all four `Component` words available within a `Location`. A three- or four-component 64-bit vector type must not specify a non-zero `Component` decoration. A three-component 64-bit vector type will consume all four `Component` words of the first `Location` and `Component` 0 and 1 of the second `Location`. This leaves `Component` 2 and 3 available for other component-qualified declarations.

A scalar or two-component 64-bit data type must not specify a `Component` decoration of 1 or 3. A `Component` decoration must not be specified for any type that is not a scalar or vector.

A four-component 64-bit data type will consume all four `Component` words of the first `Location` and all four `Component` words of the second `Location`.

### 15.2. Vertex Input Interface

When the vertex stage is present in a pipeline, the vertex shader input variables form an interface with the vertex input attributes. The vertex shader input variables are matched by the `Location` and `Component` decorations to the vertex input attributes specified in the `pVertexInputState` member of the VkGraphicsPipelineCreateInfo structure.

The vertex shader input variables listed by `OpEntryPoint` with the `Input` storage class form the vertex input interface. These variables must be identified with a `Location` decoration and can also be identified with a `Component` decoration.

For the purposes of interface matching: variables declared without a `Component` decoration are considered to have a `Component` decoration of zero. The number of available vertex input `Location` slots is given by the `maxVertexInputAttributes` member of the `VkPhysicalDeviceLimits` structure.

See Attribute Location and Component Assignment for details.

All vertex shader inputs declared as above must have a corresponding attribute and binding in the pipeline.

### 15.3. Fragment Output Interface

When the fragment stage is present in a pipeline, the fragment shader outputs form an interface with the output attachments defined by a render pass instance. The fragment shader output variables are matched by the `Location` and `Component` decorations to specified color attachments.

The fragment shader output variables listed by `OpEntryPoint` with the `Output` storage class form the fragment output interface. These variables must be identified with a `Location` decoration. They can also be identified with a `Component` decoration and/or an `Index` decoration. For the purposes of interface matching: variables declared without a `Component` decoration are considered to have a `Component` decoration of zero, and variables declared without an `Index` decoration are considered to have an `Index` decoration of zero.

A fragment shader output variable identified with a `Location` decoration of i is associated with the color attachment indicated by VkRenderingInfo::`pColorAttachments`[i]. When using render pass objects, it is associated with the color attachment indicated by VkSubpassDescription::`pColorAttachments`[i]. Values are written to those attachments after passing through the blending unit as described in Blending, if enabled. Locations are consumed as described in Location Assignment. The number of available fragment output `Location` slots is given by the `maxFragmentOutputAttachments` member of the `VkPhysicalDeviceLimits` structure.

If the `dynamicRenderingLocalRead` feature is supported, fragment output locations can be remapped when using dynamic rendering.

To set the fragment output location mappings during rendering, call:

    // Provided by VK_VERSION_1_4
    void vkCmdSetRenderingAttachmentLocations(
        VkCommandBuffer                             commandBuffer,
        const VkRenderingAttachmentLocationInfo*    pLocationInfo);

or the equivalent command

    // Provided by VK_KHR_dynamic_rendering_local_read
    void vkCmdSetRenderingAttachmentLocationsKHR(
        VkCommandBuffer                             commandBuffer,
        const VkRenderingAttachmentLocationInfo*    pLocationInfo);

- `commandBuffer` is the command buffer into which the command will be recorded.

- `pLocationInfo` is a VkRenderingAttachmentLocationInfo structure indicating the new mappings.

This command sets the attachment location mappings for subsequent drawing commands, and must match the mappings provided to the bound pipeline, if one is bound, which can be set by chaining VkRenderingAttachmentLocationInfo to VkGraphicsPipelineCreateInfo.

Until this command is called, mappings in the command buffer state are treated as each color attachment specified in vkCmdBeginRendering having a location equal to its index in VkRenderingInfo::`pColorAttachments`. This state is reset whenever vkCmdBeginRendering is called.

Valid Usage

- VUID-vkCmdSetRenderingAttachmentLocations-dynamicRenderingLocalRead-09509
  `dynamicRenderingLocalRead` must be enabled

- VUID-vkCmdSetRenderingAttachmentLocations-pLocationInfo-09510
  `pLocationInfo->colorAttachmentCount` must be equal to the value of VkRenderingInfo::`colorAttachmentCount` used to begin the current render pass instance

- VUID-vkCmdSetRenderingAttachmentLocations-commandBuffer-09511
  The current render pass instance must have been started or resumed by vkCmdBeginRendering in this `commandBuffer`

Valid Usage (Implicit)

- VUID-vkCmdSetRenderingAttachmentLocations-commandBuffer-parameter
  `commandBuffer` must be a valid VkCommandBuffer handle

- VUID-vkCmdSetRenderingAttachmentLocations-pLocationInfo-parameter
  `pLocationInfo` must be a valid pointer to a valid VkRenderingAttachmentLocationInfo structure

- VUID-vkCmdSetRenderingAttachmentLocations-commandBuffer-recording
  `commandBuffer` must be in the recording state

- VUID-vkCmdSetRenderingAttachmentLocations-commandBuffer-cmdpool
  The `VkCommandPool` that `commandBuffer` was allocated from must support graphics operations

- VUID-vkCmdSetRenderingAttachmentLocations-renderpass
  This command must only be called inside of a render pass instance

- VUID-vkCmdSetRenderingAttachmentLocations-videocoding
  This command must only be called outside of a video coding scope

Host Synchronization

- Host access to `commandBuffer` must be externally synchronized

- Host access to the `VkCommandPool` that `commandBuffer` was allocated from must be externally synchronized

Command Properties

Command Buffer Levels | Render Pass Scope | Video Coding Scope | Supported Queue Types | Command Type
--- | --- | --- | --- | ---
Primary Secondary | Inside | Outside | Graphics | State

The `VkRenderingAttachmentLocationInfo` structure is defined as:

    // Provided by VK_VERSION_1_4
    typedef struct VkRenderingAttachmentLocationInfo {
        VkStructureType    sType;
        const void*        pNext;
        uint32_t           colorAttachmentCount;
        const uint32_t*    pColorAttachmentLocations;
    } VkRenderingAttachmentLocationInfo;

or the equivalent

    // Provided by VK_KHR_dynamic_rendering_local_read
    typedef VkRenderingAttachmentLocationInfo VkRenderingAttachmentLocationInfoKHR;

- `sType` is a VkStructureType value identifying this structure.

- `pNext` is `NULL` or a pointer to a structure extending this structure.

- `colorAttachmentCount` is the number of elements in `pColorAttachmentLocations`.

- `pColorAttachmentLocations` is a pointer to an array of `colorAttachmentCount` `uint32_t` values defining remapped locations for color attachments.

This structure allows applications to remap the locations of color attachments to different fragment shader output locations.

Each element of `pColorAttachmentLocations` set to `VK_ATTACHMENT_UNUSED` will be inaccessible to this pipeline as a color attachment; no location will map to it. Each element of `pColorAttachmentLocations` set to any other value will map the specified location value to the color attachment specified in the render pass at the corresponding index in the `pColorAttachmentLocations` array. Any writes to a fragment output location that is not mapped to an attachment must be discarded.

If `pColorAttachmentLocations` is `NULL`, it is equivalent to setting each element to its index within the array.

This structure can be included in the `pNext` chain of a VkGraphicsPipelineCreateInfo structure to set this state for a pipeline. If this structure is not included in the `pNext` chain of VkGraphicsPipelineCreateInfo, it is equivalent to specifying this structure with the following properties:

- `colorAttachmentCount` set to VkPipelineRenderingCreateInfo::`colorAttachmentCount`.

- `pColorAttachmentLocations` set to `NULL`.

This structure can be included in the `pNext` chain of a VkCommandBufferInheritanceInfo structure to specify inherited state from the primary command buffer. If VkCommandBufferInheritanceInfo::renderPass is not VK_NULL_HANDLE, or `VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT` is not specified in VkCommandBufferBeginInfo::flags, members of this structure are ignored. If this structure is not included in the `pNext` chain of VkCommandBufferInheritanceInfo, it is equivalent to specifying this structure with the following properties:

- `colorAttachmentCount` set to VkCommandBufferInheritanceRenderingInfo::`colorAttachmentCount`.

- `pColorAttachmentLocations` set to `NULL`.

Valid Usage

- VUID-VkRenderingAttachmentLocationInfo-dynamicRenderingLocalRead-09512
  If the `dynamicRenderingLocalRead` feature is not enabled, and `pColorAttachmentLocations` is not `NULL`, each element must be the value of its index within the array

- VUID-VkRenderingAttachmentLocationInfo-pColorAttachmentLocations-09513
  Elements of `pColorAttachmentLocations` that are not `VK_ATTACHMENT_UNUSED` must each be unique

- VUID-VkRenderingAttachmentLocationInfo-colorAttachmentCount-09514
  `colorAttachmentCount` must be less than or equal to `maxColorAttachments`

- VUID-VkRenderingAttachmentLocationInfo-pColorAttachmentLocations-09515
  Each element of `pColorAttachmentLocations` must be less than `maxColorAttachments`

Valid Usage (Implicit)

- VUID-VkRenderingAttachmentLocationInfo-sType-sType
  `sType` must be `VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_LOCATION_INFO`

When an active fragment shader invocation finishes, the values of all fragment shader outputs are copied out and used as blend inputs or color attachments writes. If the invocation does not set a value for them, the input values to those blending or color attachment writes are undefined.

Components of the output variables are assigned as described in Component Assignment. Output `Component` words identified as 0, 1, 2, and 3 will be directed to the R, G, B, and A inputs to the blending unit, respectively, or to the output attachment if blending is disabled. If two variables are placed within the same `Location`, they must have the same underlying type (floating-point or integer). `Component` words which do not correspond to any fragment shader output will also result in undefined values for blending or color attachment writes.

Fragment outputs identified with an `Index` of zero are directed to the first input of the blending unit associated with the corresponding `Location`. Outputs identified with an `Index` of one are directed to the second input of the corresponding blending unit.

There must be no output variable which has the same `Location`, `Component`, and `Index` as any other, either explicitly declared or implied.

Output values written by a fragment shader must be declared with either `OpTypeFloat` or `OpTypeInt`, and a `Width` of 32. If `storageInputOutput16` is supported, output values written by a fragment shader can be also declared with either `OpTypeFloat` or `OpTypeInt` and a `Width` of 16. Composites of these types are also permitted. If the color attachment has a signed or unsigned normalized fixed-point format, color values are assumed to be floating-point and are converted to fixed-point as described in Conversion From Floating-Point to Normalized Fixed-Point; If the color attachment has an integer format, color values are assumed to be integers and converted to the bit-depth of the target. Any value that cannot be represented in the attachment’s format is undefined. For any other attachment format no conversion is performed. If the type of the values written by the fragment shader do not match the format of the corresponding color attachment, the resulting values are undefined for those components.

### 15.4. Legacy Dithering

The application can enable dithering to be applied to the color output of a subpass, by using the `VK_SUBPASS_DESCRIPTION_ENABLE_LEGACY_DITHERING_BIT_EXT` flag. For use in a dynamic render pass, the `VK_RENDERING_ENABLE_LEGACY_DITHERING_BIT_EXT` flag must be used. In that case, the pipelines used must have been created with `VK_PIPELINE_CREATE_2_ENABLE_LEGACY_DITHERING_BIT_EXT`.

When dithering is enabled, the implementation may modify the output color value c by one ULP. This modification must only depend on the framebuffer coordinates (xf,yf) of the sample, as well as on the value of c.

The exact details of the dithering algorithm are unspecified, including the algorithm itself, the formats dithering is applied to, and the stage in which it is applied.

Note | This extension is intended only for use by OpenGL emulation layers, and as such the dithering algorithm applied to the subpass should be equivalent to the vendor’s OpenGL implementation, if any.

### 15.5. Fragment Tile Image Interface

When a fragment stage is present in a pipeline, the fragment shader tile image variables decorated with `Location` form an interface with the color attachments defined by the render pass instance. The fragment shader tile image variables are matched by `Location` decorations to the color attachments specified in the `pColorAttachments` array of the VkRenderingInfoKHR structure describing the render pass instance the fragment shader is executed in.

The fragment shader variables listed by `OpEntryPoint` with the `TileImageEXT` storage class and a decoration of `Location` form the fragment tile image interface. These variables must be declared with a type of `OpTypeImage`, and a `Dim` operand of `TileImageDataEXT`. The `Component` decoration is not supported for these variables.

Reading from a tile image variable with a `Location` decoration of i reads from the color attachment identified by the element of VkRenderingInfoKHR::`pColorAttachments` with a `location` equal to i. If the tile image variable is declared as an array of size N, it consumes N consecutive tile image locations, starting with the index specified. There must not be more than one tile image variable with the same `Location` whether explicitly declared or implied by an array declaration. The number of available tile image locations is the same as the number of available fragment output locations as given by the `maxFragmentOutputAttachments` member of the `VkPhysicalDeviceLimits` structure.

The basic data type (floating-point, integer, unsigned integer) of the tile image variable must match the basic format of the corresponding color attachment, or the values read from the tile image variables are undefined.

### 15.6. Fragment Input Attachment Interface

When a fragment stage is present in a pipeline, the fragment shader subpass inputs form an interface with the input attachments of the current subpass. The fragment shader subpass input variables are matched by `InputAttachmentIndex` decorations to the input attachments specified in the `pInputAttachments` array of the VkSubpassDescription structure describing the subpass that the fragment shader is executed in.

The fragment shader subpass input variables with the `UniformConstant` storage class and a decoration of `InputAttachmentIndex` that are statically used by `OpEntryPoint` form the fragment input attachment interface. These variables must be declared with a type of `OpTypeImage`, a `Dim` operand of `SubpassData`, an `Arrayed` operand of 0, and a `Sampled` operand of 2. The `MS` operand of the `OpTypeImage` must be 0 if the `samples` field of the corresponding VkAttachmentDescription is `VK_SAMPLE_COUNT_1_BIT` and multisampled-render-to-single-sampled is not enabled, and 1 otherwise.

A subpass input variable identified with an `InputAttachmentIndex` decoration of i reads from the input attachment indicated by `pInputAttachments`[i] member of `VkSubpassDescription`. If the subpass input variable is declared as an array of size N, it consumes N consecutive input attachments, starting with the index specified. There must not be more than one input variable with the same `InputAttachmentIndex` whether explicitly declared or implied by an array declaration per image aspect. A multi-aspect image (e.g. a depth/stencil format) can use the same input variable. The number of available input attachment indices is given by the `maxPerStageDescriptorInputAttachments` member of the `VkPhysicalDeviceLimits` structure.

When using dynamic rendering with the `dynamicRenderingLocalRead` feature enabled, a subpass input variable with a `InputAttachmentIndex` decoration of i can be mapped to a color, depth, or stencil attachment.

To set the input attachment index mappings during dynamic rendering, call:

    // Provided by VK_VERSION_1_4
    void vkCmdSetRenderingInputAttachmentIndices(
        VkCommandBuffer                             commandBuffer,
        const VkRenderingInputAttachmentIndexInfo*  pInputAttachmentIndexInfo);

or the equivalent command

    // Provided by VK_KHR_dynamic_rendering_local_read
    void vkCmdSetRenderingInputAttachmentIndicesKHR(
        VkCommandBuffer                             commandBuffer,
        const VkRenderingInputAttachmentIndexInfo*  pInputAttachmentIndexInfo);

- `commandBuffer` is the command buffer into which the command will be recorded.

- `pInputAttachmentIndexInfo` is a VkRenderingInputAttachmentIndexInfo structure indicating the new mappings.

This command sets the input attachment index mappings for subsequent drawing commands, and must match the mappings provided to the bound pipeline, if one is bound, which can be set by chaining VkRenderingInputAttachmentIndexInfo to VkGraphicsPipelineCreateInfo.

Until this command is called, mappings in the command buffer state are treated as each color attachment specified in vkCmdBeginRendering mapping to subpass inputs with a `InputAttachmentIndex` equal to its index in VkRenderingInfo::`pColorAttachments`, and depth/stencil attachments mapping to input attachments without these decorations. This state is reset whenever vkCmdBeginRendering is called.

Valid Usage

- VUID-vkCmdSetRenderingInputAttachmentIndices-dynamicRenderingLocalRead-09516
  `dynamicRenderingLocalRead` must be enabled

- VUID-vkCmdSetRenderingInputAttachmentIndices-pInputAttachmentIndexInfo-09517
  `pInputAttachmentIndexInfo->colorAttachmentCount` must be equal to the value of VkRenderingInfo::`colorAttachmentCount` used to begin the current render pass instance

- VUID-vkCmdSetRenderingInputAttachmentIndices-commandBuffer-09518
  The current render pass instance must have been started or resumed by vkCmdBeginRendering in this `commandBuffer`

Valid Usage (Implicit)

- VUID-vkCmdSetRenderingInputAttachmentIndices-commandBuffer-parameter
  `commandBuffer` must be a valid VkCommandBuffer handle

- VUID-vkCmdSetRenderingInputAttachmentIndices-pInputAttachmentIndexInfo-parameter
  `pInputAttachmentIndexInfo` must be a valid pointer to a valid VkRenderingInputAttachmentIndexInfo structure

- VUID-vkCmdSetRenderingInputAttachmentIndices-commandBuffer-recording
  `commandBuffer` must be in the recording state

- VUID-vkCmdSetRenderingInputAttachmentIndices-commandBuffer-cmdpool
  The `VkCommandPool` that `commandBuffer` was allocated from must support graphics operations

- VUID-vkCmdSetRenderingInputAttachmentIndices-renderpass
  This command must only be called inside of a render pass instance

- VUID-vkCmdSetRenderingInputAttachmentIndices-videocoding
  This command must only be called outside of a video coding scope

Host Synchronization

- Host access to `commandBuffer` must be externally synchronized

- Host access to the `VkCommandPool` that `commandBuffer` was allocated from must be externally synchronized

Command Properties

Command Buffer Levels | Render Pass Scope | Video Coding Scope | Supported Queue Types | Command Type
--- | --- | --- | --- | ---
Primary Secondary | Inside | Outside | Graphics | State

The `VkRenderingInputAttachmentIndexInfo` structure is defined as:

    // Provided by VK_VERSION_1_4
    typedef struct VkRenderingInputAttachmentIndexInfo {
        VkStructureType    sType;
        const void*        pNext;
        uint32_t           colorAttachmentCount;
        const uint32_t*    pColorAttachmentInputIndices;
        const uint32_t*    pDepthInputAttachmentIndex;
        const uint32_t*    pStencilInputAttachmentIndex;
    } VkRenderingInputAttachmentIndexInfo;

or the equivalent

    // Provided by VK_KHR_dynamic_rendering_local_read
    typedef VkRenderingInputAttachmentIndexInfo VkRenderingInputAttachmentIndexInfoKHR;

- `sType` is a VkStructureType value identifying this structure.

- `pNext` is `NULL` or a pointer to a structure extending this structure.

- `colorAttachmentCount` is the number of elements in `pColorAttachmentInputIndices`.

- `pColorAttachmentInputIndices` is a pointer to an array of `colorAttachmentCount` `uint32_t` values defining indices for color attachments to be used as input attachments.

- `pDepthInputAttachmentIndex` is either `NULL`, or a pointer to a `uint32_t` value defining the index for the depth attachment to be used as an input attachment.

- `pStencilInputAttachmentIndex` is either `NULL`, or a pointer to a `uint32_t` value defining the index for the stencil attachment to be used as an input attachment.

This structure allows applications to remap attachments to different input attachment indices.

Each element of `pColorAttachmentInputIndices` set to a value of `VK_ATTACHMENT_UNUSED` indicates that the corresponding attachment will not be used as an input attachment in this pipeline. Any other value in each of those elements will map the corresponding attachment to a `InputAttachmentIndex` value defined in shader code.

If `pColorAttachmentInputIndices` is `NULL`, it is equivalent to setting each element to its index within the array.

If `pDepthInputAttachmentIndex` or `pStencilInputAttachmentIndex` are set to `NULL`, they map to input attachments without a `InputAttachmentIndex` decoration. If they point to a value of `VK_ATTACHMENT_UNUSED`, it indicates that the corresponding attachment will not be used as an input attachment in this pipeline. If they point to any other value it maps the corresponding attachment to a `InputAttachmentIndex` value defined in shader code.

This structure can be included in the `pNext` chain of a VkGraphicsPipelineCreateInfo structure to set this state for a pipeline. If this structure is not included in the `pNext` chain of VkGraphicsPipelineCreateInfo, it is equivalent to specifying this structure with the following properties:

- `colorAttachmentCount` set to VkPipelineRenderingCreateInfo::`colorAttachmentCount`.

- `pColorAttachmentInputIndices` set to `NULL`.

- `pDepthInputAttachmentIndex` set to `NULL`.

- `pStencilInputAttachmentIndex` set to `NULL`.

This structure can be included in the `pNext` chain of a VkCommandBufferInheritanceInfo structure to specify inherited state from the primary command buffer. If this structure is not included in the `pNext` chain of VkCommandBufferInheritanceInfo, it is equivalent to specifying this structure with the following properties:

- `colorAttachmentCount` set to VkCommandBufferInheritanceRenderingInfo::`colorAttachmentCount`.

- `pColorAttachmentInputIndices` set to `NULL`.

- `pDepthInputAttachmentIndex` set to `NULL`.

- `pStencilInputAttachmentIndex` set to `NULL`.

Valid Usage

- VUID-VkRenderingInputAttachmentIndexInfo-dynamicRenderingLocalRead-09519
  If the `dynamicRenderingLocalRead` feature is not enabled, and `pColorAttachmentInputIndices` is not `NULL`, each element must be `VK_ATTACHMENT_UNUSED`

- VUID-VkRenderingInputAttachmentIndexInfo-dynamicRenderingLocalRead-09520
  If the `dynamicRenderingLocalRead` feature is not enabled, `pDepthInputAttachmentIndex` must be a valid pointer to a value of `VK_ATTACHMENT_UNUSED`

- VUID-VkRenderingInputAttachmentIndexInfo-dynamicRenderingLocalRead-09521
  If the `dynamicRenderingLocalRead` feature is not enabled, `pStencilInputAttachmentIndex` must be a valid pointer to a value of `VK_ATTACHMENT_UNUSED`

- VUID-VkRenderingInputAttachmentIndexInfo-pColorAttachmentInputIndices-09522
  Elements of `pColorAttachmentInputIndices` that are not `VK_ATTACHMENT_UNUSED` must each be unique

- VUID-VkRenderingInputAttachmentIndexInfo-pColorAttachmentInputIndices-09523
  Elements of `pColorAttachmentInputIndices` that are not `VK_ATTACHMENT_UNUSED` must not take the same value as the content of `pDepthInputAttachmentIndex`

- VUID-VkRenderingInputAttachmentIndexInfo-pColorAttachmentInputIndices-09524
  Elements of `pColorAttachmentInputIndices` that are not `VK_ATTACHMENT_UNUSED` must not take the same value as the content of `pStencilInputAttachmentIndex`

- VUID-VkRenderingInputAttachmentIndexInfo-colorAttachmentCount-09525
  `colorAttachmentCount` must be less than or equal to `maxColorAttachments`

Valid Usage (Implicit)

- VUID-VkRenderingInputAttachmentIndexInfo-sType-sType
  `sType` must be `VK_STRUCTURE_TYPE_RENDERING_INPUT_ATTACHMENT_INDEX_INFO`

- VUID-VkRenderingInputAttachmentIndexInfo-pColorAttachmentInputIndices-parameter
  If `colorAttachmentCount` is not `0`, and `pColorAttachmentInputIndices` is not `NULL`, `pColorAttachmentInputIndices` must be a valid pointer to an array of `colorAttachmentCount` `uint32_t` values

- VUID-VkRenderingInputAttachmentIndexInfo-pDepthInputAttachmentIndex-parameter
  If `pDepthInputAttachmentIndex` is not `NULL`, `pDepthInputAttachmentIndex` must be a valid pointer to a valid `uint32_t` value

- VUID-VkRenderingInputAttachmentIndexInfo-pStencilInputAttachmentIndex-parameter
  If `pStencilInputAttachmentIndex` is not `NULL`, `pStencilInputAttachmentIndex` must be a valid pointer to a valid `uint32_t` value

Variables identified with the `InputAttachmentIndex` must only be used by a fragment stage. The numeric format of the subpass input must match the format of the corresponding input attachment, or the values of subpass loads from these variables are undefined. If the framebuffer attachment contains both depth and stencil aspects, the numeric format of the subpass input determines if depth or stencil aspect is accessed by the shader.

See Input Attachment for more details.

#### 15.6.1. Fragment Input Attachment Compatibility

An input attachment that is statically accessed by a fragment shader must be backed by a descriptor that is equivalent to the VkImageView in the VkFramebuffer, except for `subresourceRange.aspectMask`. The `aspectMask` must be equal to the aspect accessed by the shader.

### 15.7. Ray Tracing Pipeline Interface

Ray tracing pipelines may have more stages than other pipelines with multiple instances of each stage and more dynamic interactions between the stages, but still have interface structures that obey the same general rules as interfaces between shader stages in other pipelines. The three types of inter-stage interface variables for ray tracing pipelines are:

- Ray payloads containing data tracked for the entire lifetime of the ray.

- Hit attributes containing data about a specific hit for the duration of its processing.

- Callable data for passing data into and out of a callable shader.

Ray payloads and callable data are used in explicit shader call instructions, so they have an incoming variant to distinguish the parameter passed to the invocation from any other payloads or data being used by subsequent shader call instructions.

An interface structure used between stages must match between the stages using it. Specifically:

- The hit attribute structure read in an any-hit or closest hit shader must be the same structure as the hit attribute structure written in the corresponding intersection shader in the same hit group.

- The incoming callable data for a callable shader must be the same structure as the callable data referenced by the execute callable instruction in the calling shader.

- The ray payload for a shader invoked by a ray tracing command must be the same structure for all shader stages using the payload for that ray.

Any shader with an incoming ray payload, incoming callable data, or hit attribute must only declare one variable of that type.

Table 20. Ray Pipeline Shader Interface
Shader Stage | Ray Payload | Incoming Ray Payload | Hit Attribute | Callable Data | Incoming Callable Data
--- | --- | --- | --- | --- | ---
Ray Generation | r/w |  |  | r/w |
Intersection |  |  | r/w |  |
Any-Hit |  | r/w | r |  |
Closest Hit | r/w | r/w | r | r/w |
Miss | r/w | r/w |  | r/w |
Callable |  |  |  | r/w | r/w

### 15.8. Shader Resource Interface

When a shader stage accesses buffer or image resources, as described in the Resource Descriptors section, the shader resource variables must be matched with the pipeline layout that is provided at pipeline creation time.

The set of shader variables that form the shader resource interface for a stage are the variables statically used by that stage’s `OpEntryPoint` with a storage class of `Uniform`, `UniformConstant`, `StorageBuffer`, or `PushConstant`. For the fragment shader, this includes the fragment input attachment interface.

The shader resource interface consists of two sub-interfaces: the push constant interface and the descriptor set interface.

#### 15.8.1. Push Constant Interface

The shader variables defined with a storage class of `PushConstant` that are statically used by the shader entry points for the pipeline define the push constant interface. They must be:

- typed as `OpTypeStruct`,

- identified with a `Block` decoration, and

- laid out explicitly using the `Offset`, `ArrayStride`, and `MatrixStride` decorations as specified in Offset and Stride Assignment.

There must be no more than one push constant block statically used per shader entry point.

Each statically used member of a push constant block must be placed at an `Offset` such that the entire member is entirely contained within the VkPushConstantRange for each `OpEntryPoint` that uses it, and the `stageFlags` for that range must specify the appropriate VkShaderStageFlagBits for that stage. The `Offset` decoration for any member of a push constant block must not cause the space required for that member to extend outside the range [0, `maxPushConstantsSize`).

Any member of a push constant block that is declared as an array must only be accessed with dynamically uniform indices.

#### 15.8.2. Descriptor Set Interface

The descriptor set interface is comprised of the shader variables with the storage class of `StorageBuffer`, `Uniform` or `UniformConstant` (including the variables in the fragment input attachment interface) that are statically used by the shader entry points for the pipeline.

These variables must have `DescriptorSet` and `Binding` decorations specified, which are assigned and matched with the `VkDescriptorSetLayout` objects in the pipeline layout as described in DescriptorSet and Binding Assignment.

The `Image` `Format` of an `OpTypeImage` declaration must not be Unknown, for variables which are used for `OpImageRead`, `OpImageSparseRead`, or `OpImageWrite` operations, except under the following conditions:

- For `OpImageWrite`, if the image format is listed in the storage without format list and if the `shaderStorageImageWriteWithoutFormat` feature is enabled and the shader module declares the `StorageImageWriteWithoutFormat` capability.

- For `OpImageWrite`, if the image format supports `VK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT` and the shader module declares the `StorageImageWriteWithoutFormat` capability.

- For `OpImageRead` or `OpImageSparseRead`, if the image format is listed in the storage without format list and if the `shaderStorageImageReadWithoutFormat` feature is enabled and the shader module declares the `StorageImageReadWithoutFormat` capability.

- For `OpImageRead` or `OpImageSparseRead`, if the image format supports `VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT` and the shader module declares the `StorageImageReadWithoutFormat` capability.

- For `OpImageRead`, if `Dim` is `SubpassData` (indicating a read from an input attachment).

The `Image` `Format` of an `OpTypeImage` declaration must not be Unknown, for variables which are used for `OpAtomic*` operations.

Variables identified with the `Uniform` storage class are used to access transparent buffer backed resources. Such variables must be:

- typed as `OpTypeStruct`, or an array of this type,

- identified with a `Block` or `BufferBlock` decoration, and

- laid out explicitly using the `Offset`, `ArrayStride`, and `MatrixStride` decorations as specified in Offset and Stride Assignment.

Variables identified with the `StorageBuffer` storage class are used to access transparent buffer backed resources. Such variables must be:

- typed as `OpTypeStruct`, or an array of this type,

- identified with a `Block` decoration, and

- laid out explicitly using the `Offset`, `ArrayStride`, and `MatrixStride` decorations as specified in Offset and Stride Assignment.

The `Offset` decoration for any member of a `Block`-decorated variable in the `Uniform` storage class must not cause the space required for that variable to extend outside the range [0, `maxUniformBufferRange`). The `Offset` decoration for any member of a `Block`-decorated variable in the `StorageBuffer` storage class must not cause the space required for that variable to extend outside the range [0, `maxStorageBufferRange`).

Variables identified with the `Uniform` storage class can also be used to access transparent descriptor set backed resources when the variable is assigned to a descriptor set layout binding with a `descriptorType` of `VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK`. In this case the variable must be typed as `OpTypeStruct` and cannot be aggregated into arrays of that type. Further, the `Offset` decoration for any member of such a variable must not cause the space required for that variable to extend outside the range [0,`maxInlineUniformBlockSize`).

Variables identified with a storage class of `UniformConstant` and a decoration of `InputAttachmentIndex` must be declared as described in Fragment Input Attachment Interface.

SPIR-V variables decorated with a descriptor set and binding that identify a combined image sampler descriptor can have a type of `OpTypeImage`, `OpTypeSampler` (`Sampled`=1), or `OpTypeSampledImage`.

When accessing a resource through such a variable, the resource must be selected via compile time constant expressions unless features are enabled to allow dynamically uniform or non-uniform expressions, as described below:

- Storage images (except storage texel buffers and input attachments):

  - Dynamically uniform: `shaderStorageImageArrayDynamicIndexing` and `StorageImageArrayDynamicIndexing`

  - Non-uniform: `shaderStorageImageArrayNonUniformIndexing` and `StorageImageArrayNonUniformIndexing`

- Storage texel buffers:

  - Dynamically uniform: `shaderStorageTexelBufferArrayDynamicIndexing` and `StorageTexelBufferArrayDynamicIndexing`

  - Non-uniform: `shaderStorageTexelBufferArrayNonUniformIndexing` and `StorageTexelBufferArrayNonUniformIndexing`

- Input attachments:

  - Dynamically uniform: `shaderInputAttachmentArrayDynamicIndexing` and `InputAttachmentArrayDynamicIndexing`

  - Non-uniform: `shaderInputAttachmentArrayNonUniformIndexing` and `InputAttachmentArrayNonUniformIndexing`

- Sampled images (except uniform texel buffers), samplers and combined image samplers:

  - Dynamically uniform: `shaderSampledImageArrayDynamicIndexing` and `SampledImageArrayDynamicIndexing`

  - Non-uniform: `shaderSampledImageArrayNonUniformIndexing` and `SampledImageArrayNonUniformIndexing`

- Uniform texel buffers:

  - Dynamically uniform: `shaderUniformTexelBufferArrayDynamicIndexing` and `UniformTexelBufferArrayDynamicIndexing`

  - Non-uniform: `shaderUniformTexelBufferArrayNonUniformIndexing` and `UniformTexelBufferArrayNonUniformIndexing`

- Uniform buffers:

  - Dynamically uniform: `shaderUniformBufferArrayDynamicIndexing` and `UniformBufferArrayDynamicIndexing`

  - Non-uniform: `shaderUniformBufferArrayNonUniformIndexing` and `UniformBufferArrayNonUniformIndexing`

- Storage buffers:

  - Dynamically uniform: `shaderStorageBufferArrayDynamicIndexing` and `StorageBufferArrayDynamicIndexing`

  - Non-uniform: `shaderStorageBufferArrayNonUniformIndexing` and `StorageBufferArrayNonUniformIndexing`

- Acceleration structures:

  - Dynamically uniform: Always supported.

  - Non-uniform: Always supported.

- weight image:

  - Dynamically uniform: Always supported.

  - Non-uniform: Never supported.

- Block matching image:

  - Dynamically uniform: Always supported.

  - Non-uniform: Never supported.

Example 1. Note

Implementations must take care when implementing this if subgroups are not necessarily a subset of the invocation group for their hardware (e.g. if multiple draw calls are packed together). If such an implementation needs uniformity across the subgroup for any resource access, the implementation is responsible for ensuring that indices that are only dynamically uniform across the invocation group still function as expected if they advertise the respective feature.

A combined image sampler in an array that enables sampler Y′CBCR conversion or samples a subsampled image must only be indexed by constant integral expressions.

Table 21. Shader Resource and Descriptor Type Correspondence
Resource type | Descriptor Type
--- | ---
sampler | `VK_DESCRIPTOR_TYPE_SAMPLER` or `VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER`
sampled image | `VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE` or `VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER`
storage image | `VK_DESCRIPTOR_TYPE_STORAGE_IMAGE`
combined image sampler | `VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER`
uniform texel buffer | `VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER`
storage texel buffer | `VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER`
uniform buffer | `VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER` or `VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC`
storage buffer | `VK_DESCRIPTOR_TYPE_STORAGE_BUFFER` or `VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC`
input attachment | `VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT`
inline uniform block | `VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK`
acceleration structure | `VK_DESCRIPTOR_TYPE_ACCELERATION_STRUCTURE_KHR` or `VK_DESCRIPTOR_TYPE_ACCELERATION_STRUCTURE_NV`
weight image | `VK_DESCRIPTOR_TYPE_SAMPLE_WEIGHT_IMAGE_QCOM`
block matching image | `VK_DESCRIPTOR_TYPE_BLOCK_MATCH_IMAGE_QCOM`

Table 22. Shader Resource and Storage Class Correspondence
Resource type | Storage Class | Type1 | Decoration(s)2
--- | --- | --- | ---
sampler | `UniformConstant` | `OpTypeSampler` |
sampled image | `UniformConstant` | `OpTypeImage` (`Sampled`=1) |
storage image | `UniformConstant` | `OpTypeImage` (`Sampled`=2) |
combined image sampler | `UniformConstant` | `OpTypeSampledImage` `OpTypeImage` (`Sampled`=1) `OpTypeSampler` |
uniform texel buffer | `UniformConstant` | `OpTypeImage` (`Dim`=`Buffer`, `Sampled`=1) |
storage texel buffer | `UniformConstant` | `OpTypeImage` (`Dim`=`Buffer`, `Sampled`=2) |
uniform buffer | `Uniform` | `OpTypeStruct` | `Block`, `Offset`, (`ArrayStride`), (`MatrixStride`)
storage buffer | `Uniform` | `OpTypeStruct` | `BufferBlock`, `Offset`, (`ArrayStride`), (`MatrixStride`)
`StorageBuffer` | `Block`, `Offset`, (`ArrayStride`), (`MatrixStride`)
input attachment | `UniformConstant` | `OpTypeImage` (`Dim`=`SubpassData`, `Sampled`=2) | `InputAttachmentIndex`
inline uniform block | `Uniform` | `OpTypeStruct` | `Block`, `Offset`, (`ArrayStride`), (`MatrixStride`)
acceleration structure | `UniformConstant` | `OpTypeAccelerationStructureKHR` |
sample weight image | `UniformConstant` | `OpTypeImage` (`Depth`=0, `Dim`=`2D`, `Arrayed`=1, `MS`=0, `Sampled`=1) | `WeightTextureQCOM`
block matching image | `UniformConstant` | `OpTypeImage` (`Depth`=0, `Dim`=`2D`, `Arrayed`=0, `MS`=0, `Sampled`=1) | `BlockMatchTextureQCOM`

1

  Where `OpTypeImage` is referenced, the `Dim` values `Buffer` and `Subpassdata` are only accepted where they are specifically referenced. They do not correspond to resource types where a generic `OpTypeImage` is specified.

2

  In addition to `DescriptorSet` and `Binding`.

#### 15.8.3. DescriptorSet and Binding Assignment

A variable decorated with a `DescriptorSet` decoration of s and a `Binding` decoration of b indicates that this variable is associated with the VkDescriptorSetLayoutBinding that has a `binding` equal to b in `pSetLayouts`[s] that was specified in VkPipelineLayoutCreateInfo.

`DescriptorSet` decoration values must be between zero and `maxBoundDescriptorSets` minus one, inclusive. `Binding` decoration values can be any 32-bit unsigned integer value, as described in Descriptor Set Layout. Each descriptor set has its own binding name space.

If the `Binding` decoration is used with an array, the entire array is assigned that binding value. The array must be a single-dimensional array and size of the array must be no larger than the number of descriptors in the binding. If the array is runtime-sized, then array elements greater than or equal to the size of that binding in the bound descriptor set must not be used. If the array is runtime-sized, the `runtimeDescriptorArray` feature must be enabled and the `RuntimeDescriptorArray` capability must be declared. The index of each element of the array is referred to as the arrayElement. For the purposes of interface matching and descriptor set operations, if a resource variable is not an array, it is treated as if it has an arrayElement of zero.

There is a limit on the number of resources of each type that can be accessed by a pipeline stage as shown in Shader Resource Limits. The “Resources Per Stage” column gives the limit on the number each type of resource that can be statically used for an entry point in any given stage in a pipeline. The “Resource Types” column lists which resource types are counted against the limit. Some resource types count against multiple limits. The `VK_DESCRIPTOR_TYPE_MUTABLE_EXT` descriptor type counts as one individual resource and one for every unique resource limit per descriptor set type that is present in the associated binding’s VkMutableDescriptorTypeListEXT. If multiple descriptor types in VkMutableDescriptorTypeListEXT map to the same resource limit, only one descriptor is consumed for purposes of computing resource limits.

The pipeline layout may include descriptor sets and bindings which are not referenced by any variables statically used by the entry points for the shader stages in the binding’s `stageFlags`.

However, if a variable assigned to a given `DescriptorSet` and `Binding` is statically used by the entry point for a shader stage, the pipeline layout must contain a descriptor set layout binding in that descriptor set layout and for that binding number, and that binding’s `stageFlags` must include the appropriate VkShaderStageFlagBits for that stage. The variable must be of a valid resource type determined by its SPIR-V type and storage class, as defined in Shader Resource and Storage Class Correspondence. The descriptor set layout binding must be of a corresponding descriptor type, as defined in Shader Resource and Descriptor Type Correspondence.

Note | There are no limits on the number of shader variables that can have overlapping set and binding values in a shader; but which resources are statically used has an impact. If any shader variable identifying a resource is statically used in a shader, then the underlying descriptor bound at the declared set and binding must support the declared type in the shader when the shader executes. If multiple shader variables are declared with the same set and binding values, and with the same underlying descriptor type, they can all be statically used within the same shader. However, accesses are not automatically synchronized, and `Aliased` decorations should be used to avoid data hazards (see section 2.18.2 Aliasing in the SPIR-V specification). If multiple shader variables with the same set and binding values are declared in a single shader, but with different declared types, where any of those are not supported by the relevant bound descriptor, that shader can only be executed if the variables with the unsupported type are not statically used. A noteworthy example of using multiple statically-used shader variables sharing the same descriptor set and binding values is a descriptor of type `VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER` that has multiple corresponding shader variables in the `UniformConstant` storage class, where some could be `OpTypeImage` (`Sampled`=1), some could be `OpTypeSampler`, and some could be `OpTypeSampledImage`.

Table 23. Shader Resource Limits
Resources per Stage | Resource Types
--- | ---
`maxPerStageDescriptorSamplers` or `maxPerStageDescriptorUpdateAfterBindSamplers` | sampler
combined image sampler
`maxPerStageDescriptorSampledImages` or `maxPerStageDescriptorUpdateAfterBindSampledImages` | sampled image
combined image sampler
uniform texel buffer
sample weight image
block matching image
`maxPerStageDescriptorStorageImages` or `maxPerStageDescriptorUpdateAfterBindStorageImages` | storage image
storage texel buffer
`maxPerStageDescriptorUniformBuffers` or `maxPerStageDescriptorUpdateAfterBindUniformBuffers` | uniform buffer
uniform buffer dynamic
`maxPerStageDescriptorStorageBuffers` or `maxPerStageDescriptorUpdateAfterBindStorageBuffers` | storage buffer
storage buffer dynamic
`maxPerStageDescriptorInputAttachments` or `maxPerStageDescriptorUpdateAfterBindInputAttachments` | input attachment1
`maxPerStageDescriptorInlineUniformBlocks` or `maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks` | inline uniform block
`VkPhysicalDeviceRayTracingPropertiesNV`::`maxDescriptorSetAccelerationStructures` or `maxPerStageDescriptorAccelerationStructures` or `maxPerStageDescriptorUpdateAfterBindAccelerationStructures` | acceleration structure

1

  Input attachments can only be used in the fragment shader stage

#### 15.8.4. Offset and Stride Assignment

Certain objects must be explicitly laid out using the `Offset`, `ArrayStride`, and `MatrixStride`, as described in SPIR-V explicit layout validation rules. All such layouts also must conform to the following requirements.

Note | The numeric order of `Offset` decorations does not need to follow member declaration order.

Alignment Requirements

There are different alignment requirements depending on the specific resources and on the features enabled.

Matrix types are defined in terms of arrays as follows:

- A column-major matrix with C columns and R rows is equivalent to a C element array of vectors with R components.

- A row-major matrix with C columns and R rows is equivalent to an R element array of vectors with C components.

The scalar alignment of the type of an `OpTypeStruct` member is defined recursively as follows:

- A scalar of size N has a scalar alignment of N.

- A vector type has a scalar alignment equal to that of its component type.

- An array type has a scalar alignment equal to that of its element type.

- A structure has a scalar alignment equal to the largest scalar alignment of any of its members.

- A matrix type inherits scalar alignment from the equivalent array declaration.

The base alignment of the type of an `OpTypeStruct` member is defined recursively as follows:

- A scalar has a base alignment equal to its scalar alignment.

- A two-component vector has a base alignment equal to twice its scalar alignment.

- A three- or four-component vector has a base alignment equal to four times its scalar alignment.

- An array has a base alignment equal to the base alignment of its element type.

- A structure has a base alignment equal to the largest base alignment of any of its members. An empty structure has a base alignment equal to the size of the smallest scalar type permitted by the capabilities declared in the SPIR-V module. (e.g., for a 1 byte aligned empty struct in the `StorageBuffer` storage class, `StorageBuffer8BitAccess` or `UniformAndStorageBuffer8BitAccess` must be declared in the SPIR-V module.)

- A matrix type inherits base alignment from the equivalent array declaration.

The extended alignment of the type of an `OpTypeStruct` member is similarly defined as follows:

- A scalar or vector type has an extended alignment equal to its base alignment.

- An array or structure type has an extended alignment equal to the largest extended alignment of any of its members, rounded up to a multiple of 16.

- A matrix type inherits extended alignment from the equivalent array declaration.

A member is defined to improperly straddle if either of the following are true:

- It is a vector with total size less than or equal to 16 bytes, and has `Offset` decorations placing its first byte at F and its last byte at L, where floor(F / 16) != floor(L / 16).

- It is a vector with total size greater than 16 bytes and has its `Offset` decorations placing its first byte at a non-integer multiple of 16.

Standard Buffer Layout

Every member of an `OpTypeStruct` that is required to be explicitly laid out must be aligned according to the first matching rule as follows. If the struct is contained in pointer types of multiple storage classes, it must satisfy the requirements for every storage class used to reference it.

1. If the `scalarBlockLayout` feature is enabled and the storage class is `Uniform`, `StorageBuffer`, `PhysicalStorageBuffer`, `ShaderRecordBufferKHR`, or `PushConstant` then every member must be aligned according to its scalar alignment.

2. If the `workgroupMemoryExplicitLayoutScalarBlockLayout` feature is enabled and the storage class is `Workgroup` then every member must be aligned according to its scalar alignment.

3. All vectors must be aligned according to their scalar alignment.

4. If the `uniformBufferStandardLayout` feature is not enabled, then any member of an `OpTypeStruct` with a storage class of `Uniform` and a decoration of `Block` must be aligned according to its extended alignment.

5. Every other member must be aligned according to its base alignment.

Note | Even if scalar alignment is supported, it is generally more performant to use the base alignment.

The memory layout must obey the following rules:

- The `Offset` decoration of any member must be a multiple of its alignment.

- Any `ArrayStride` or `MatrixStride` decoration must be a multiple of the alignment of the array or matrix as defined above.

If one of the conditions below applies

- The storage class is `Uniform`, `StorageBuffer`, `PhysicalStorageBuffer`, `ShaderRecordBufferKHR`, or `PushConstant`, and the `scalarBlockLayout` feature is not enabled.

- The storage class is `Workgroup`, and either the struct member is not part of a `Block` or the `workgroupMemoryExplicitLayoutScalarBlockLayout` feature is not enabled.

- The storage class is any other storage class.

the memory layout must also obey the following rules:

- Vectors must not improperly straddle, as defined above.

- The `Offset` decoration of a member must not place it between the end of a structure, an array or a matrix and the next multiple of the alignment of that structure, array or matrix.

Note | The std430 layout in GLSL satisfies these rules for types using the base alignment. The std140 layout satisfies the rules for types using the extended alignment.

### 15.9. Built-In Variables

Built-in variables are accessed in shaders by declaring a variable decorated with a `BuiltIn` SPIR-V decoration. The meaning of each `BuiltIn` decoration is as follows. In the remainder of this section, the name of a built-in is used interchangeably with a term equivalent to a variable decorated with that particular built-in. Built-ins that represent integer values can be declared as either signed or unsigned 32-bit integers.

As mentioned above, some inputs and outputs have an additional level of arrayness relative to other shader inputs and outputs. This level of arrayness is not included in the type descriptions below, but must be included when declaring the built-in.

Any two `Input` storage class `OpVariable` declarations listed as operands on the same `OpEntryPoint` must not have the same `BuiltIn` decoration. Any two `Output` storage class `OpVariable` declarations listed as operands on the same `OpEntryPoint` must not have the same `BuiltIn` decoration.

`BaryCoordKHR`

  The `BaryCoordKHR` decoration can be used to decorate a fragment shader input variable. This variable will contain a three-component floating-point vector with barycentric weights that indicate the location of the fragment relative to the screen-space locations of vertices of its primitive, obtained using perspective interpolation.

Valid Usage

- VUID-BaryCoordKHR-BaryCoordKHR-04154
  The `BaryCoordKHR` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-BaryCoordKHR-BaryCoordKHR-04155
  The variable decorated with `BaryCoordKHR` must be declared using the `Input` `Storage` `Class`

- VUID-BaryCoordKHR-BaryCoordKHR-04156
  The variable decorated with `BaryCoordKHR` must be declared as a three-component vector of 32-bit floating-point values

`BaryCoordNoPerspAMD`

  The `BaryCoordNoPerspAMD` decoration can be used to decorate a fragment shader input variable. This variable will contain the (I,J) pair of the barycentric coordinates corresponding to the fragment evaluated using linear interpolation at the fragment’s center. The K coordinate of the barycentric coordinates can be derived given the identity I + J + K = 1.0.

Valid Usage

- VUID-BaryCoordNoPerspAMD-BaryCoordNoPerspAMD-04157
  The `BaryCoordNoPerspAMD` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-BaryCoordNoPerspAMD-BaryCoordNoPerspAMD-04158
  The variable decorated with `BaryCoordNoPerspAMD` must be declared using the `Input` `Storage` `Class`

- VUID-BaryCoordNoPerspAMD-BaryCoordNoPerspAMD-04159
  The variable decorated with `BaryCoordNoPerspAMD` must be declared as a two-component vector of 32-bit floating-point values

`BaryCoordNoPerspKHR`

  The `BaryCoordNoPerspKHR` decoration can be used to decorate a fragment shader input variable. This variable will contain a three-component floating-point vector with barycentric weights that indicate the location of the fragment relative to the screen-space locations of vertices of its primitive, obtained using linear interpolation.

Valid Usage

- VUID-BaryCoordNoPerspKHR-BaryCoordNoPerspKHR-04160
  The `BaryCoordNoPerspKHR` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-BaryCoordNoPerspKHR-BaryCoordNoPerspKHR-04161
  The variable decorated with `BaryCoordNoPerspKHR` must be declared using the `Input` `Storage` `Class`

- VUID-BaryCoordNoPerspKHR-BaryCoordNoPerspKHR-04162
  The variable decorated with `BaryCoordNoPerspKHR` must be declared as a three-component vector of 32-bit floating-point values

`BaryCoordNoPerspCentroidAMD`

  The `BaryCoordNoPerspCentroidAMD` decoration can be used to decorate a fragment shader input variable. This variable will contain the (I,J) pair of the barycentric coordinates corresponding to the fragment evaluated using linear interpolation at the centroid. The K coordinate of the barycentric coordinates can be derived given the identity I + J + K = 1.0.

Valid Usage

- VUID-BaryCoordNoPerspCentroidAMD-BaryCoordNoPerspCentroidAMD-04163
  The `BaryCoordNoPerspCentroidAMD` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-BaryCoordNoPerspCentroidAMD-BaryCoordNoPerspCentroidAMD-04164
  The variable decorated with `BaryCoordNoPerspCentroidAMD` must be declared using the `Input` `Storage` `Class`

- VUID-BaryCoordNoPerspCentroidAMD-BaryCoordNoPerspCentroidAMD-04165
  The variable decorated with `BaryCoordNoPerspCentroidAMD` must be declared as a three-component vector of 32-bit floating-point values

`BaryCoordNoPerspSampleAMD`

  The `BaryCoordNoPerspSampleAMD` decoration can be used to decorate a fragment shader input variable. This variable will contain the (I,J) pair of the barycentric coordinates corresponding to the fragment evaluated using linear interpolation at each covered sample. The K coordinate of the barycentric coordinates can be derived given the identity I + J + K = 1.0.

Valid Usage

- VUID-BaryCoordNoPerspSampleAMD-BaryCoordNoPerspSampleAMD-04166
  The `BaryCoordNoPerspSampleAMD` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-BaryCoordNoPerspSampleAMD-BaryCoordNoPerspSampleAMD-04167
  The variable decorated with `BaryCoordNoPerspSampleAMD` must be declared using the `Input` `Storage` `Class`

- VUID-BaryCoordNoPerspSampleAMD-BaryCoordNoPerspSampleAMD-04168
  The variable decorated with `BaryCoordNoPerspSampleAMD` must be declared as a two-component vector of 32-bit floating-point values

`BaryCoordPullModelAMD`

  The `BaryCoordPullModelAMD` decoration can be used to decorate a fragment shader input variable. This variable will contain (1/W, 1/I, 1/J) evaluated at the fragment center and can be used to calculate gradients and then interpolate I, J, and W at any desired sample location.

Valid Usage

- VUID-BaryCoordPullModelAMD-BaryCoordPullModelAMD-04169
  The `BaryCoordPullModelAMD` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-BaryCoordPullModelAMD-BaryCoordPullModelAMD-04170
  The variable decorated with `BaryCoordPullModelAMD` must be declared using the `Input` `Storage` `Class`

- VUID-BaryCoordPullModelAMD-BaryCoordPullModelAMD-04171
  The variable decorated with `BaryCoordPullModelAMD` must be declared as a three-component vector of 32-bit floating-point values

`BaryCoordSmoothAMD`

  The `BaryCoordSmoothAMD` decoration can be used to decorate a fragment shader input variable. This variable will contain the (I,J) pair of the barycentric coordinates corresponding to the fragment evaluated using perspective interpolation at the fragment’s center. The K coordinate of the barycentric coordinates can be derived given the identity I + J + K = 1.0.

Valid Usage

- VUID-BaryCoordSmoothAMD-BaryCoordSmoothAMD-04172
  The `BaryCoordSmoothAMD` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-BaryCoordSmoothAMD-BaryCoordSmoothAMD-04173
  The variable decorated with `BaryCoordSmoothAMD` must be declared using the `Input` `Storage` `Class`

- VUID-BaryCoordSmoothAMD-BaryCoordSmoothAMD-04174
  The variable decorated with `BaryCoordSmoothAMD` must be declared as a two-component vector of 32-bit floating-point values

`BaryCoordSmoothCentroidAMD`

  The `BaryCoordSmoothCentroidAMD` decoration can be used to decorate a fragment shader input variable. This variable will contain the (I,J) pair of the barycentric coordinates corresponding to the fragment evaluated using perspective interpolation at the centroid. The K coordinate of the barycentric coordinates can be derived given the identity I + J + K = 1.0.

Valid Usage

- VUID-BaryCoordSmoothCentroidAMD-BaryCoordSmoothCentroidAMD-04175
  The `BaryCoordSmoothCentroidAMD` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-BaryCoordSmoothCentroidAMD-BaryCoordSmoothCentroidAMD-04176
  The variable decorated with `BaryCoordSmoothCentroidAMD` must be declared using the `Input` `Storage` `Class`

- VUID-BaryCoordSmoothCentroidAMD-BaryCoordSmoothCentroidAMD-04177
  The variable decorated with `BaryCoordSmoothCentroidAMD` must be declared as a two-component vector of 32-bit floating-point values

`BaryCoordSmoothSampleAMD`

  The `BaryCoordSmoothSampleAMD` decoration can be used to decorate a fragment shader input variable. This variable will contain the (I,J) pair of the barycentric coordinates corresponding to the fragment evaluated using perspective interpolation at each covered sample. The K coordinate of the barycentric coordinates can be derived given the identity I + J + K = 1.0.

Valid Usage

- VUID-BaryCoordSmoothSampleAMD-BaryCoordSmoothSampleAMD-04178
  The `BaryCoordSmoothSampleAMD` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-BaryCoordSmoothSampleAMD-BaryCoordSmoothSampleAMD-04179
  The variable decorated with `BaryCoordSmoothSampleAMD` must be declared using the `Input` `Storage` `Class`

- VUID-BaryCoordSmoothSampleAMD-BaryCoordSmoothSampleAMD-04180
  The variable decorated with `BaryCoordSmoothSampleAMD` must be declared as a two-component vector of 32-bit floating-point values

`BaseInstance`

  Decorating a variable with the `BaseInstance` built-in will make that variable contain the integer value corresponding to the first instance that was passed to the command that invoked the current vertex shader invocation. `BaseInstance` is the `firstInstance` parameter to a direct drawing command or the `firstInstance` member of a structure consumed by an indirect drawing command.

Valid Usage

- VUID-BaseInstance-BaseInstance-04181
  The `BaseInstance` decoration must be used only within the `Vertex` `Execution` `Model`

- VUID-BaseInstance-BaseInstance-04182
  The variable decorated with `BaseInstance` must be declared using the `Input` `Storage` `Class`

- VUID-BaseInstance-BaseInstance-04183
  The variable decorated with `BaseInstance` must be declared as a scalar 32-bit integer value

`BaseVertex`

  Decorating a variable with the `BaseVertex` built-in will make that variable contain the integer value corresponding to the first vertex or vertex offset that was passed to the command that invoked the current vertex shader invocation. For non-indexed drawing commands, this variable is the `firstVertex` parameter to a direct drawing command or the `firstVertex` member of the structure consumed by an indirect drawing command. For indexed drawing commands, this variable is the `vertexOffset` parameter to a direct drawing command or the `vertexOffset` member of the structure consumed by an indirect drawing command.

Valid Usage

- VUID-BaseVertex-BaseVertex-04184
  The `BaseVertex` decoration must be used only within the `Vertex` `Execution` `Model`

- VUID-BaseVertex-BaseVertex-04185
  The variable decorated with `BaseVertex` must be declared using the `Input` `Storage` `Class`

- VUID-BaseVertex-BaseVertex-04186
  The variable decorated with `BaseVertex` must be declared as a scalar 32-bit integer value

`ClipDistance`

  Decorating a variable with the `ClipDistance` built-in decoration will make that variable contain the mechanism for controlling user clipping. `ClipDistance` is an array such that the ith element of the array specifies the clip distance for plane i. A clip distance of 0 means the vertex is on the plane, a positive distance means the vertex is inside the clip half-space, and a negative distance means the vertex is outside the clip half-space.

Note | The array variable decorated with `ClipDistance` is explicitly sized by the shader.

Note | In the last pre-rasterization shader stage, these values will be linearly interpolated across the primitive and the portion of the primitive with interpolated distances less than 0 will be considered outside the clip volume. If `ClipDistance` is then used by a fragment shader, `ClipDistance` contains these linearly interpolated values.

Valid Usage

- VUID-ClipDistance-ClipDistance-04187
  The `ClipDistance` decoration must be used only within the `MeshEXT`, `MeshNV`, `Vertex`, `Fragment`, `TessellationControl`, `TessellationEvaluation`, or `Geometry` `Execution` `Model`

- VUID-ClipDistance-ClipDistance-04188
  The variable decorated with `ClipDistance` within the `MeshEXT`, `MeshNV`, or `Vertex` `Execution` `Model` must be declared using the `Output` `Storage` `Class`

- VUID-ClipDistance-ClipDistance-04189
  The variable decorated with `ClipDistance` within the `Fragment` `Execution` `Model` must be declared using the `Input` `Storage` `Class`

- VUID-ClipDistance-ClipDistance-04190
  The variable decorated with `ClipDistance` within the `TessellationControl`, `TessellationEvaluation`, or `Geometry` `Execution` `Model` must not be declared in a `Storage` `Class` other than `Input` or `Output`

- VUID-ClipDistance-ClipDistance-04191
  The variable decorated with `ClipDistance` must be declared as an array of 32-bit floating-point values

`ClipDistancePerViewNV`

  Decorating a variable with the `ClipDistancePerViewNV` built-in decoration will make that variable contain the per-view clip distances. The per-view clip distances have the same semantics as `ClipDistance`.

Valid Usage

- VUID-ClipDistancePerViewNV-ClipDistancePerViewNV-04192
  The `ClipDistancePerViewNV` decoration must be used only within the `MeshNV` `Execution` `Model`

- VUID-ClipDistancePerViewNV-ClipDistancePerViewNV-04193
  The variable decorated with `ClipDistancePerViewNV` must be declared using the `Output` `Storage` `Class`

- VUID-ClipDistancePerViewNV-ClipDistancePerViewNV-04194
  The variable decorated with `ClipDistancePerViewNV` must also be decorated with the `PerViewNV` decoration

- VUID-ClipDistancePerViewNV-ClipDistancePerViewNV-04195
  The variable decorated with `ClipDistancePerViewNV` must be declared as a two-dimensional array of 32-bit floating-point values

`ClusterIDHUAWEI`

  The `ClusterIDHUAWEI` decoration can be used to decorate a cluster culling shader output variable,this variable will contain an integer value that specifies the id of cluster being rendered by this drawing command. When Cluster Culling Shader enable, `ClusterIDHUAWEI` will replace gl_DrawID pass to vertex shader for cluster-related information fetching.

Valid Usage

- VUID-ClusterIDHUAWEI-ClusterIDHUAWEI-07797
  The `ClusterIDHUAWEI` decoration must be used only within the `ClusterCullingHUAWEI` `Execution` `Model`

- VUID-ClusterIDHUAWEI-ClusterIDHUAWEI-07798
  The variable decorated with `ClusterIDHUAWEI` must be declared as a scalar 32-bit integer value

`ClusterShadingRateHUAWEI`

  The `ClusterShadingRateHUAWEI` decoration can be used to decorate a cluster culling shader output variable. This variable will contain an integer value specifying the shading rate of a rendering cluster.

Valid Usage

- VUID-ClusterShadingRateHUAWEI-ClusterShadingRateHUAWEI-09448
  The `ClusterShadingRateHUAWEI` decoration must be used only within the `ClusterCullingHUAWEI` `Execution` `Model`

- VUID-ClusterShadingRateHUAWEI-ClusterShadingRateHUAWEI-09449
  The variable decorated with `ClusterShadingRateHUAWEI` must be declared as a scalar 32-bit integer value

`CullDistance`

  Decorating a variable with the `CullDistance` built-in decoration will make that variable contain the mechanism for controlling user culling. If any member of this array is assigned a negative value for all vertices belonging to a primitive, then the primitive is discarded before rasterization.

Note | In fragment shaders, the values of the `CullDistance` array are linearly interpolated across each primitive.

Note | If `CullDistance` decorates an input variable, that variable will contain the corresponding value from the `CullDistance` decorated output variable from the previous shader stage.

Valid Usage

- VUID-CullDistance-CullDistance-04196
  The `CullDistance` decoration must be used only within the `MeshEXT`, `MeshNV`, `Vertex`, `Fragment`, `TessellationControl`, `TessellationEvaluation`, or `Geometry` `Execution` `Model`

- VUID-CullDistance-CullDistance-04197
  The variable decorated with `CullDistance` within the `MeshEXT`, `MeshNV` or `Vertex` `Execution` `Model` must be declared using the `Output` `Storage` `Class`

- VUID-CullDistance-CullDistance-04198
  The variable decorated with `CullDistance` within the `Fragment` `Execution` `Model` must be declared using the `Input` `Storage` `Class`

- VUID-CullDistance-CullDistance-04199
  The variable decorated with `CullDistance` within the `TessellationControl`, `TessellationEvaluation`, or `Geometry` `Execution` `Model` must not be declared using a `Storage` `Class` other than `Input` or `Output`

- VUID-CullDistance-CullDistance-04200
  The variable decorated with `CullDistance` must be declared as an array of 32-bit floating-point values

`CullDistancePerViewNV`

  Decorating a variable with the `CullDistancePerViewNV` built-in decoration will make that variable contain the per-view cull distances. The per-view cull distances have the same semantics as `CullDistance`.

Valid Usage

- VUID-CullDistancePerViewNV-CullDistancePerViewNV-04201
  The `CullDistancePerViewNV` decoration must be used only within the `MeshNV` `Execution` `Model`

- VUID-CullDistancePerViewNV-CullDistancePerViewNV-04202
  The variable decorated with `CullDistancePerViewNV` must be declared using the `Output` `Storage` `Class`

- VUID-CullDistancePerViewNV-CullDistancePerViewNV-04203
  The variable decorated with `CullDistancePerViewNV` must also be decorated with the `PerViewNV` decoration

- VUID-CullDistancePerViewNV-CullDistancePerViewNV-04204
  The variable decorated with `CullDistancePerViewNV` must be declared as a two-dimensional array of 32-bit floating-point values

`CullPrimitiveEXT`

  Decorating a variable with the `CullPrimitiveEXT` built-in decoration will make that variable contain the culling state of output primitives. If the per-primitive boolean value is `true`, the primitive will be culled, if it is `false` it will not be culled.

Valid Usage

- VUID-CullPrimitiveEXT-CullPrimitiveEXT-07034
  The `CullPrimitiveEXT` decoration must be used only within the `MeshEXT` `Execution` `Model`

- VUID-CullPrimitiveEXT-CullPrimitiveEXT-07035
  The variable decorated with `CullPrimitiveEXT` must be declared using the `Output` `Storage` `Class`

- VUID-CullPrimitiveEXT-CullPrimitiveEXT-07036
  The variable decorated with `CullPrimitiveEXT` must be declared as an array of boolean values

- VUID-CullPrimitiveEXT-CullPrimitiveEXT-07037
  The size of the array decorated with `CullPrimitiveEXT` must match the value specified by `OutputPrimitivesEXT`

- VUID-CullPrimitiveEXT-CullPrimitiveEXT-07038
  The variable decorated with `CullPrimitiveEXT` within the `MeshEXT` `Execution` `Model` must also be decorated with the `PerPrimitiveEXT` decoration

`CullMaskKHR`

  A variable decorated with the `CullMaskKHR` decoration will specify the cull mask of the ray being processed. The value is given by the `Cull Mask` parameter passed into one of the `OpTrace*` instructions.

Valid Usage

- VUID-CullMaskKHR-CullMaskKHR-06735
  The `CullMaskKHR` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, `ClosestHitKHR`, or `MissKHR` `Execution` `Model`

- VUID-CullMaskKHR-CullMaskKHR-06736
  The variable decorated with `CullMaskKHR` must be declared using the `Input` `Storage` `Class`

- VUID-CullMaskKHR-CullMaskKHR-06737
  The variable decorated with `CullMaskKHR` must be declared as a scalar 32-bit integer value

`CurrentRayTimeNV`

  A variable decorated with the `CurrentRayTimeNV` decoration contains the time value passed in to `OpTraceRayMotionNV` which called this shader.

Valid Usage

- VUID-CurrentRayTimeNV-CurrentRayTimeNV-04942
  The `CurrentRayTimeNV` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, `ClosestHitKHR`, or `MissKHR` `Execution` `Model`

- VUID-CurrentRayTimeNV-CurrentRayTimeNV-04943
  The variable decorated with `CurrentRayTimeNV` must be declared using the `Input` `Storage` `Class`

- VUID-CurrentRayTimeNV-CurrentRayTimeNV-04944
  The variable decorated with `CurrentRayTimeNV` must be declared as a scalar 32-bit floating-point value

`DeviceIndex`

  The `DeviceIndex` decoration can be applied to a shader input which will be filled with the device index of the physical device that is executing the current shader invocation. This value will be in the range [0,ma x(1,p h ys i c a l De v i ce C o u n t)), where physicalDeviceCount is the `physicalDeviceCount` member of VkDeviceGroupDeviceCreateInfo.

Valid Usage

- VUID-DeviceIndex-DeviceIndex-04205
  The variable decorated with `DeviceIndex` must be declared using the `Input` `Storage` `Class`

- VUID-DeviceIndex-DeviceIndex-04206
  The variable decorated with `DeviceIndex` must be declared as a scalar 32-bit integer value

`DrawIndex`

  Decorating a variable with the `DrawIndex` built-in will make that variable contain the integer value corresponding to the zero-based index of the draw that invoked the current task, mesh, or vertex shader invocation. For indirect drawing commands, `DrawIndex` begins at zero and increments by one for each draw executed. The number of draws is given by the `drawCount` parameter. For direct drawing commands, if vkCmdDrawMultiEXT or vkCmdDrawMultiIndexedEXT is used, this variable contains the integer value corresponding to the zero-based index of the draw. Otherwise `DrawIndex` is always zero. `DrawIndex` is dynamically uniform.

When task or mesh shaders are used, only the first active stage will have proper access to the variable. The value read by other stages is undefined.

Valid Usage

- VUID-DrawIndex-DrawIndex-04207
  The `DrawIndex` decoration must be used only within the `Vertex`, `MeshEXT`, `TaskEXT`, `MeshNV`, or `TaskNV` `Execution` `Model`

- VUID-DrawIndex-DrawIndex-04208
  The variable decorated with `DrawIndex` must be declared using the `Input` `Storage` `Class`

- VUID-DrawIndex-DrawIndex-04209
  The variable decorated with `DrawIndex` must be declared as a scalar 32-bit integer value

`FirstIndexHUAWEI`

  The `FirstIndexHUAWEI` decoration can be used to decorate a cluster culling shader output variable,this indexed mode specific variable will contain an integer value that specifies the base index within the index buffer corresponding to a cluster.

Valid Usage

- VUID-FirstIndexHUAWEI-FirstIndexHUAWEI-07799
  The `FirstIndexHUAWEI` decoration must be used only within the `ClusterCullingHUAWEI` `Execution` `Model`

- VUID-FirstIndexHUAWEI-FirstIndexHUAWEI-07800
  The variable decorated with `FirstIndexHUAWEI` must be declared as a scalar 32-bit integer value

`FragCoord`

  Decorating a variable with the `FragCoord` built-in decoration will make that variable contain the coordinates (x,y,z,1/w) of the fragment being processed.

  The (x,y) values are the framebuffer coordinates (xf,yf) of the fragment.

  When Sample Shading is enabled, the x and y components of `FragCoord` reflect the location of one of the samples corresponding to the shader invocation.

  Otherwise, the x and y components of `FragCoord` reflect the location of the center of the fragment.

  The z component of `FragCoord` is the interpolated depth value of the primitive.

  The w component is the interpolated w 1​.

  The `Centroid` interpolation decoration is ignored, but allowed, on `FragCoord`.

Valid Usage

- VUID-FragCoord-FragCoord-04210
  The `FragCoord` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-FragCoord-FragCoord-04211
  The variable decorated with `FragCoord` must be declared using the `Input` `Storage` `Class`

- VUID-FragCoord-FragCoord-04212
  The variable decorated with `FragCoord` must be declared as a four-component vector of 32-bit floating-point values

`FragDepth`

  To have a shader supply a fragment-depth value, the shader must declare the `DepthReplacing` execution mode. Such a shader’s fragment-depth value will come from the variable decorated with the `FragDepth` built-in decoration.

  This value will be used for any subsequent depth testing performed by the implementation or writes to the depth attachment. See fragment shader depth replacement for details.

Valid Usage

- VUID-FragDepth-FragDepth-04213
  The `FragDepth` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-FragDepth-FragDepth-04214
  The variable decorated with `FragDepth` must be declared using the `Output` `Storage` `Class`

- VUID-FragDepth-FragDepth-04215
  The variable decorated with `FragDepth` must be declared as a scalar 32-bit floating-point value

- VUID-FragDepth-FragDepth-04216
  If the shader dynamically writes to the variable decorated with `FragDepth`, the `DepthReplacing` `Execution` `Mode` must be declared

`FirstInstanceHUAWEI`

  The `FirstInstanceHUAWEI` decoration can be used to decorate a cluster culling shader output variable,this variable will contain an integer value that specifies the instance ID of the first instance to draw.

Valid Usage

- VUID-FirstInstanceHUAWEI-FirstInstanceHUAWEI-07801
  The `FirstInstanceHUAWEI` decoration must be used only within the `ClusterCullingHUAWEI` `Execution` `Model`

- VUID-FirstInstanceHUAWEI-FirstInstanceHUAWEI-07802
  The variable decorated with `FirstInstanceHUAWEI` must be declared as a scalar 32-bit integer value

`FirstVertexHUAWEI`

  The `FirstVertexHUAWEI` decoration can be used to decorate a cluster culling shader output variable,this non-indexed mode specific variable will contain an integer value that specifies the index of the first vertex in a cluster to draw.

Valid Usage

- VUID-FirstVertexHUAWEI-FirstVertexHUAWEI-07803
  The `FirstVertexHUAWEI` decoration must be used only within the `FirstVertexHUAWEI` `Execution` `Model`

- VUID-FirstVertexHUAWEI-FirstVertexHUAWEI-07804
  The variable decorated with `FirstVertexHUAWEI` must be declared as a scalar 32-bit integer value

`FragInvocationCountEXT`

  Decorating a variable with the `FragInvocationCountEXT` built-in decoration will make that variable contain the maximum number of fragment shader invocations for the fragment, as determined by `minSampleShading`.

  If Sample Shading is not enabled, `FragInvocationCountEXT` will be filled with a value of 1.

Valid Usage

- VUID-FragInvocationCountEXT-FragInvocationCountEXT-04217
  The `FragInvocationCountEXT` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-FragInvocationCountEXT-FragInvocationCountEXT-04218
  The variable decorated with `FragInvocationCountEXT` must be declared using the `Input` `Storage` `Class`

- VUID-FragInvocationCountEXT-FragInvocationCountEXT-04219
  The variable decorated with `FragInvocationCountEXT` must be declared as a scalar 32-bit integer value

`FragSizeEXT`

  Decorating a variable with the `FragSizeEXT` built-in decoration will make that variable contain the dimensions in pixels of the area that the fragment covers for that invocation.

  If fragment density map is not enabled, `FragSizeEXT` will be filled with a value of (1,1).

Valid Usage

- VUID-FragSizeEXT-FragSizeEXT-04220
  The `FragSizeEXT` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-FragSizeEXT-FragSizeEXT-04221
  The variable decorated with `FragSizeEXT` must be declared using the `Input` `Storage` `Class`

- VUID-FragSizeEXT-FragSizeEXT-04222
  The variable decorated with `FragSizeEXT` must be declared as a two-component vector of 32-bit integer values

`FragStencilRefEXT`

  Decorating a variable with the `FragStencilRefEXT` built-in decoration will make that variable contain the new stencil reference value for all samples covered by the fragment. This value will be used as the stencil reference value used in stencil testing.

  To write to `FragStencilRefEXT`, a shader must declare the `StencilRefReplacingEXT` execution mode. If a shader declares the `StencilRefReplacingEXT` execution mode and there is an execution path through the shader that does not set `FragStencilRefEXT`, then the fragment’s stencil reference value is undefined for executions of the shader that take that path.

  Only the least significant s bits of the integer value of the variable decorated with `FragStencilRefEXT` are considered for stencil testing, where s is the number of bits in the stencil framebuffer attachment, and higher order bits are discarded.

  See fragment shader stencil reference replacement for more details.

Valid Usage

- VUID-FragStencilRefEXT-FragStencilRefEXT-04223
  The `FragStencilRefEXT` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-FragStencilRefEXT-FragStencilRefEXT-04224
  The variable decorated with `FragStencilRefEXT` must be declared using the `Output` `Storage` `Class`

- VUID-FragStencilRefEXT-FragStencilRefEXT-04225
  The variable decorated with `FragStencilRefEXT` must be declared as a scalar integer value

`FragmentSizeNV`

  Decorating a variable with the `FragmentSizeNV` built-in decoration will make that variable contain the width and height of the fragment.

Valid Usage

- VUID-FragmentSizeNV-FragmentSizeNV-04226
  The `FragmentSizeNV` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-FragmentSizeNV-FragmentSizeNV-04227
  The variable decorated with `FragmentSizeNV` must be declared using the `Input` `Storage` `Class`

- VUID-FragmentSizeNV-FragmentSizeNV-04228
  The variable decorated with `FragmentSizeNV` must be declared as a two-component vector of 32-bit integer values

`FrontFacing`

  Decorating a variable with the `FrontFacing` built-in decoration will make that variable contain whether the fragment is front or back facing. This variable is non-zero if the current fragment is considered to be part of a front-facing polygon primitive or of a non-polygon primitive and is zero if the fragment is considered to be part of a back-facing polygon primitive.

Valid Usage

- VUID-FrontFacing-FrontFacing-04229
  The `FrontFacing` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-FrontFacing-FrontFacing-04230
  The variable decorated with `FrontFacing` must be declared using the `Input` `Storage` `Class`

- VUID-FrontFacing-FrontFacing-04231
  The variable decorated with `FrontFacing` must be declared as a boolean value

`FullyCoveredEXT`

  Decorating a variable with the `FullyCoveredEXT` built-in decoration will make that variable indicate whether the fragment area is fully covered by the generating primitive. This variable is non-zero if conservative rasterization is enabled and the current fragment area is fully covered by the generating primitive, and is zero if the fragment is not covered or partially covered, or conservative rasterization is disabled.

Valid Usage

- VUID-FullyCoveredEXT-FullyCoveredEXT-04232
  The `FullyCoveredEXT` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-FullyCoveredEXT-FullyCoveredEXT-04233
  The variable decorated with `FullyCoveredEXT` must be declared using the `Input` `Storage` `Class`

- VUID-FullyCoveredEXT-FullyCoveredEXT-04234
  The variable decorated with `FullyCoveredEXT` must be declared as a boolean value

- VUID-FullyCoveredEXT-conservativeRasterizationPostDepthCoverage-04235
  If `VkPhysicalDeviceConservativeRasterizationPropertiesEXT`::`conservativeRasterizationPostDepthCoverage` is not supported the `PostDepthCoverage` `Execution` `Mode` must not be declared, when a variable with the `FullyCoveredEXT` decoration is declared

`GlobalInvocationId`

  Decorating a variable with the `GlobalInvocationId` built-in decoration will make that variable contain the location of the current invocation within the global workgroup. Each component is equal to the index of the local workgroup multiplied by the size of the local workgroup plus `LocalInvocationId`.

Valid Usage

- VUID-GlobalInvocationId-GlobalInvocationId-04236
  The `GlobalInvocationId` decoration must be used only within the `GLCompute`, `MeshEXT`, `TaskEXT`, `MeshNV`, or `TaskNV` `Execution` `Model`

- VUID-GlobalInvocationId-GlobalInvocationId-04237
  The variable decorated with `GlobalInvocationId` must be declared using the `Input` `Storage` `Class`

- VUID-GlobalInvocationId-GlobalInvocationId-04238
  The variable decorated with `GlobalInvocationId` must be declared as a three-component vector of 32-bit integer values

`HelperInvocation`

  Decorating a variable with the `HelperInvocation` built-in decoration will make that variable contain whether the current invocation is a helper invocation. This variable is non-zero if the current fragment being shaded is a helper invocation and zero otherwise. A helper invocation is an invocation of the shader that is produced to satisfy internal requirements such as the generation of derivatives.

Note | It is very likely that a helper invocation will have a value of `SampleMask` fragment shader input value that is zero.

Valid Usage

- VUID-HelperInvocation-HelperInvocation-04239
  The `HelperInvocation` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-HelperInvocation-HelperInvocation-04240
  The variable decorated with `HelperInvocation` must be declared using the `Input` `Storage` `Class`

- VUID-HelperInvocation-HelperInvocation-04241
  The variable decorated with `HelperInvocation` must be declared as a boolean value

`HitKindKHR`

  A variable decorated with the `HitKindKHR` decoration will describe the intersection that triggered the execution of the current shader. The values are determined by the intersection shader. For user-defined intersection shaders this is the value that was passed to the “Hit Kind” operand of `OpReportIntersectionKHR`. For triangle intersection candidates, this will be one of `HitKindFrontFacingTriangleKHR` or `HitKindBackFacingTriangleKHR`.

Valid Usage

- VUID-HitKindKHR-HitKindKHR-04242
  The `HitKindKHR` decoration must be used only within the `AnyHitKHR` or `ClosestHitKHR` `Execution` `Model`

- VUID-HitKindKHR-HitKindKHR-04243
  The variable decorated with `HitKindKHR` must be declared using the `Input` `Storage` `Class`

- VUID-HitKindKHR-HitKindKHR-04244
  The variable decorated with `HitKindKHR` must be declared as a scalar 32-bit integer value

`HitTNV`

  A variable decorated with the `HitTNV` decoration is equivalent to a variable decorated with the `RayTmaxKHR` decoration.

Valid Usage

- VUID-HitTNV-HitTNV-04245
  The `HitTNV` decoration must be used only within the `AnyHitNV` or `ClosestHitNV` `Execution` `Model`

- VUID-HitTNV-HitTNV-04246
  The variable decorated with `HitTNV` must be declared using the `Input` `Storage` `Class`

- VUID-HitTNV-HitTNV-04247
  The variable decorated with `HitTNV` must be declared as a scalar 32-bit floating-point value

`HitTriangleVertexPositionsKHR`

  A variable decorated with the `HitTriangleVertexPositionsKHR` decoration will specify the object space vertices of the triangle at the current intersection in application-provided order. The positions returned are transformed by the geometry transform, which is performed at standard floating-point precision, but without a specifically defined order of floating-point operations to perform the matrix multiplication.

Valid Usage

- VUID-HitTriangleVertexPositionsKHR-HitTriangleVertexPositionsKHR-08747
  The `HitTriangleVertexPositionsKHR` decoration must be used only within the `AnyHitKHR` or `ClosestHitKHR` `Execution` `Model`

- VUID-HitTriangleVertexPositionsKHR-HitTriangleVertexPositionsKHR-08748
  The variable decorated with `HitTriangleVertexPositionsKHR` must be declared using the `Input` `Storage` `Class`

- VUID-HitTriangleVertexPositionsKHR-HitTriangleVertexPositionsKHR-08749
  The variable decorated with `HitTriangleVertexPositionsKHR` must be declared as an array of three vectors of three 32-bit float values

- VUID-HitTriangleVertexPositionsKHR-HitTriangleVertexPositionsKHR-08750
  The variable decorated with `HitTriangleVertexPositionsKHR` must be used only if the value of `HitKindKHR` is `HitKindFrontFacingTriangleKHR` or `HitKindBackFacingTriangleKHR`

- VUID-HitTriangleVertexPositionsKHR-None-08751
  The acceleration structure corresponding to the current intersection must have been built with `VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DATA_ACCESS_KHR`

`IncomingRayFlagsKHR`

  A variable with the `IncomingRayFlagsKHR` decoration will contain the ray flags passed in to the trace call that invoked this particular shader. Setting pipeline flags on the ray tracing pipeline must not cause any corresponding flags to be set in variables with this decoration.

Valid Usage

- VUID-IncomingRayFlagsKHR-IncomingRayFlagsKHR-04248
  The `IncomingRayFlagsKHR` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, `ClosestHitKHR`, or `MissKHR` `Execution` `Model`

- VUID-IncomingRayFlagsKHR-IncomingRayFlagsKHR-04249
  The variable decorated with `IncomingRayFlagsKHR` must be declared using the `Input` `Storage` `Class`

- VUID-IncomingRayFlagsKHR-IncomingRayFlagsKHR-04250
  The variable decorated with `IncomingRayFlagsKHR` must be declared as a scalar 32-bit integer value

`IndexCountHUAWEI`

  The `IndexCountHUAWEI` decoration can be used to decorate a cluster culling shader output variable,this indexed mode specific variable will contain an integer value that specifies the number of indexed vertices in a cluster to draw.

Valid Usage

- VUID-IndexCountHUAWEI-IndexCountHUAWEI-07805
  The `IndexCountHUAWEI` decoration must be used only within the `ClusterCullingHUAWEI` `Execution` `Model`

- VUID-IndexCountHUAWEI-IndexCountHUAWEI-07806
  The variable decorated with `IndexCountHUAWEI` must be declared as a scalar 32-bit integer value

`InstanceCountHUAWEI`

  The `InstanceCountHUAWEI` decoration can be used to decorate a cluster culling shader output variable,this variable will contain an integer value that specifies the number of instance to draw in a cluster.

Valid Usage

- VUID-InstanceCountHUAWEI-InstanceCountHUAWEI-07807
  The `InstanceCountHUAWEI` decoration must be used only within the `ClusterCullingHUAWEI` `Execution` `Model`

- VUID-InstanceCountHUAWEI-InstanceCountHUAWEI-07808
  The variable decorated with `InstanceCountHUAWEI` must be declared as a scalar 32-bit integer value

`InstanceCustomIndexKHR`

  A variable decorated with the `InstanceCustomIndexKHR` decoration will contain the application-defined value of the instance that intersects the current ray. This variable contains the value that was specified in VkAccelerationStructureInstanceKHR::`instanceCustomIndex` for the current acceleration structure instance in the lower 24 bits and the upper 8 bits will be zero.

Valid Usage

- VUID-InstanceCustomIndexKHR-InstanceCustomIndexKHR-04251
  The `InstanceCustomIndexKHR` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, or `ClosestHitKHR` `Execution` `Model`

- VUID-InstanceCustomIndexKHR-InstanceCustomIndexKHR-04252
  The variable decorated with `InstanceCustomIndexKHR` must be declared using the `Input` `Storage` `Class`

- VUID-InstanceCustomIndexKHR-InstanceCustomIndexKHR-04253
  The variable decorated with `InstanceCustomIndexKHR` must be declared as a scalar 32-bit integer value

`InstanceId`

  Decorating a variable in an intersection, any-hit, or closest hit shader with the `InstanceId` decoration will make that variable contain the index of the instance that intersects the current ray.

Valid Usage

- VUID-InstanceId-InstanceId-04254
  The `InstanceId` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, or `ClosestHitKHR` `Execution` `Model`

- VUID-InstanceId-InstanceId-04255
  The variable decorated with `InstanceId` must be declared using the `Input` `Storage` `Class`

- VUID-InstanceId-InstanceId-04256
  The variable decorated with `InstanceId` must be declared as a scalar 32-bit integer value

`InvocationId`

  Decorating a variable with the `InvocationId` built-in decoration will make that variable contain the index of the current shader invocation in a geometry shader, or the index of the output patch vertex in a tessellation control shader.

  In a geometry shader, the index of the current shader invocation ranges from zero to the number of instances declared in the shader minus one. If the instance count of the geometry shader is one or is not specified, then `InvocationId` will be zero.

Valid Usage

- VUID-InvocationId-InvocationId-04257
  The `InvocationId` decoration must be used only within the `TessellationControl` or `Geometry` `Execution` `Model`

- VUID-InvocationId-InvocationId-04258
  The variable decorated with `InvocationId` must be declared using the `Input` `Storage` `Class`

- VUID-InvocationId-InvocationId-04259
  The variable decorated with `InvocationId` must be declared as a scalar 32-bit integer value

`InvocationsPerPixelNV`

  Decorating a variable with the `InvocationsPerPixelNV` built-in decoration will make that variable contain the maximum number of fragment shader invocations per pixel, as derived from the effective shading rate for the fragment. If a primitive does not fully cover a pixel, the number of fragment shader invocations for that pixel may be less than the value of `InvocationsPerPixelNV`. If the shading rate indicates a fragment covering multiple pixels, then `InvocationsPerPixelNV` will be one.

Valid Usage

- VUID-InvocationsPerPixelNV-InvocationsPerPixelNV-04260
  The `InvocationsPerPixelNV` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-InvocationsPerPixelNV-InvocationsPerPixelNV-04261
  The variable decorated with `InvocationsPerPixelNV` must be declared using the `Input` `Storage` `Class`

- VUID-InvocationsPerPixelNV-InvocationsPerPixelNV-04262
  The variable decorated with `InvocationsPerPixelNV` must be declared as a scalar 32-bit integer value

`InstanceIndex`

  Decorating a variable in a vertex shader with the `InstanceIndex` built-in decoration will make that variable contain the index of the instance that is being processed by the current vertex shader invocation. `InstanceIndex` begins at the `firstInstance` parameter to vkCmdDraw or vkCmdDrawIndexed or at the `firstInstance` member of a structure consumed by vkCmdDrawIndirect or vkCmdDrawIndexedIndirect.

Valid Usage

- VUID-InstanceIndex-InstanceIndex-04263
  The `InstanceIndex` decoration must be used only within the `Vertex` `Execution` `Model`

- VUID-InstanceIndex-InstanceIndex-04264
  The variable decorated with `InstanceIndex` must be declared using the `Input` `Storage` `Class`

- VUID-InstanceIndex-InstanceIndex-04265
  The variable decorated with `InstanceIndex` must be declared as a scalar 32-bit integer value

`LaunchIdKHR`

  A variable decorated with the `LaunchIdKHR` decoration will specify the index of the work item being processed. One work item is generated for each of the `width` × `height` × `depth` items dispatched by a vkCmdTraceRaysKHR or vkCmdTraceRaysNV command. All shader invocations inherit the same value for variables decorated with `LaunchIdKHR`.

Valid Usage

- VUID-LaunchIdKHR-LaunchIdKHR-04266
  The `LaunchIdKHR` decoration must be used only within the `RayGenerationKHR`, `IntersectionKHR`, `AnyHitKHR`, `ClosestHitKHR`, `MissKHR`, or `CallableKHR` `Execution` `Model`

- VUID-LaunchIdKHR-LaunchIdKHR-04267
  The variable decorated with `LaunchIdKHR` must be declared using the `Input` `Storage` `Class`

- VUID-LaunchIdKHR-LaunchIdKHR-04268
  The variable decorated with `LaunchIdKHR` must be declared as a three-component vector of 32-bit integer values

`LaunchSizeKHR`

  A variable decorated with the `LaunchSizeKHR` decoration will contain the `width`, `height`, and `depth` dimensions passed to the vkCmdTraceRaysKHR or vkCmdTraceRaysNV command that initiated this shader execution. The `width` is in the first component, the `height` is in the second component, and the `depth` is in the third component.

Valid Usage

- VUID-LaunchSizeKHR-LaunchSizeKHR-04269
  The `LaunchSizeKHR` decoration must be used only within the `RayGenerationKHR`, `IntersectionKHR`, `AnyHitKHR`, `ClosestHitKHR`, `MissKHR`, or `CallableKHR` `Execution` `Model`

- VUID-LaunchSizeKHR-LaunchSizeKHR-04270
  The variable decorated with `LaunchSizeKHR` must be declared using the `Input` `Storage` `Class`

- VUID-LaunchSizeKHR-LaunchSizeKHR-04271
  The variable decorated with `LaunchSizeKHR` must be declared as a three-component vector of 32-bit integer values

`Layer`

  Decorating a variable with the `Layer` built-in decoration will make that variable contain the select layer of a multi-layer framebuffer attachment.

  In a mesh, vertex, tessellation evaluation, or geometry shader, any variable decorated with `Layer` can be written with the framebuffer layer index to which the primitive produced by that shader will be directed.

  The last active pre-rasterization shader stage (in pipeline order) controls the `Layer` that is used. Outputs in previous shader stages are not used, even if the last stage fails to write the `Layer`.

  If the last active pre-rasterization shader stage shader entry point’s interface does not include a variable decorated with `Layer`, then the first layer is used. If a pre-rasterization shader stage shader entry point’s interface includes a variable decorated with `Layer`, it must write the same value to `Layer` for all output vertices of a given primitive. If the `Layer` value is less than 0 or greater than or equal to the number of layers in the framebuffer, then primitives may still be rasterized, fragment shaders may be executed, and the framebuffer values for all layers are undefined. In a mesh shader this also applies when the `Layer` value is greater than or equal to the `maxMeshOutputLayers` limit.

  If a variable with the `Layer` decoration is also decorated with `ViewportRelativeNV`, then the `ViewportIndex` is added to the layer that is used for rendering and that is made available in the fragment shader.

  If the shader writes to a variable decorated `ViewportMaskNV`, then the layer selected has a different value for each viewport a primitive is rendered to.

  In a fragment shader, a variable decorated with `Layer` contains the layer index of the primitive that the fragment invocation belongs to.

Valid Usage

- VUID-Layer-Layer-04272
  The `Layer` decoration must be used only within the `MeshEXT`, `MeshNV`, `Vertex`, `TessellationEvaluation`, `Geometry`, or `Fragment` `Execution` `Model`

- VUID-Layer-Layer-04273
  If the `shaderOutputLayer` feature is not enabled then the `Layer` decoration must be used only within the `Geometry` or `Fragment` `Execution` `Model`

- VUID-Layer-Layer-04274
  The variable decorated with `Layer` within the `MeshEXT`, `MeshNV`, `Vertex`, `TessellationEvaluation`, or `Geometry` `Execution` `Model` must be declared using the `Output` `Storage` `Class`

- VUID-Layer-Layer-04275
  The variable decorated with `Layer` within the `Fragment` `Execution` `Model` must be declared using the `Input` `Storage` `Class`

- VUID-Layer-Layer-04276
  The variable decorated with `Layer` must be declared as a scalar 32-bit integer value

- VUID-Layer-Layer-07039
  The variable decorated with `Layer` within the `MeshEXT` `Execution` `Model` must also be decorated with the `PerPrimitiveEXT` decoration

`LayerPerViewNV`

  Decorating a variable with the `LayerPerViewNV` built-in decoration will make that variable contain the per-view layer information. The per-view layer has the same semantics as `Layer`, for each view.

Valid Usage

- VUID-LayerPerViewNV-LayerPerViewNV-04277
  The `LayerPerViewNV` decoration must be used only within the `MeshNV` `Execution` `Model`

- VUID-LayerPerViewNV-LayerPerViewNV-04278
  The variable decorated with `LayerPerViewNV` must be declared using the `Output` `Storage` `Class`

- VUID-LayerPerViewNV-LayerPerViewNV-04279
  The variable decorated with `LayerPerViewNV` must also be decorated with the `PerViewNV` decoration

- VUID-LayerPerViewNV-LayerPerViewNV-04280
  The variable decorated with `LayerPerViewNV` must be declared as an array of scalar 32-bit integer values

`LocalInvocationId`

  Decorating a variable with the `LocalInvocationId` built-in decoration will make that variable contain the location of the current cluster culling, task, mesh, or compute shader invocation within the local workgroup. Each component ranges from zero through to the size of the workgroup in that dimension minus one.

Note | If the size of the workgroup in a particular dimension is one, then the `LocalInvocationId` in that dimension will be zero. If the workgroup is effectively two-dimensional, then `LocalInvocationId.z` will be zero. If the workgroup is effectively one-dimensional, then both `LocalInvocationId.y` and `LocalInvocationId.z` will be zero.

Valid Usage

- VUID-LocalInvocationId-LocalInvocationId-04281
  The `LocalInvocationId` decoration must be used only within the `GLCompute`, `MeshEXT`, `TaskEXT`, `MeshNV`, or `TaskNV` `Execution` `Model`

- VUID-LocalInvocationId-LocalInvocationId-04282
  The variable decorated with `LocalInvocationId` must be declared using the `Input` `Storage` `Class`

- VUID-LocalInvocationId-LocalInvocationId-04283
  The variable decorated with `LocalInvocationId` must be declared as a three-component vector of 32-bit integer values

`LocalInvocationIndex`

  Decorating a variable with the `LocalInvocationIndex` built-in decoration will make that variable contain a one-dimensional representation of `LocalInvocationId`. This is computed as:

      LocalInvocationIndex =
          LocalInvocationId.z * WorkgroupSize.x * WorkgroupSize.y +
          LocalInvocationId.y * WorkgroupSize.x +
          LocalInvocationId.x;

Valid Usage

- VUID-LocalInvocationIndex-LocalInvocationIndex-04284
  The `LocalInvocationIndex` decoration must be used only within the `GLCompute`, `MeshEXT`, `TaskEXT`, `MeshNV`, or `TaskNV` `Execution` `Model`

- VUID-LocalInvocationIndex-LocalInvocationIndex-04285
  The variable decorated with `LocalInvocationIndex` must be declared using the `Input` `Storage` `Class`

- VUID-LocalInvocationIndex-LocalInvocationIndex-04286
  The variable decorated with `LocalInvocationIndex` must be declared as a scalar 32-bit integer value

`MeshViewCountNV`

  Decorating a variable with the `MeshViewCountNV` built-in decoration will make that variable contain the number of views processed by the current mesh or task shader invocations.

Valid Usage

- VUID-MeshViewCountNV-MeshViewCountNV-04287
  The `MeshViewCountNV` decoration must be used only within the `MeshNV` or `TaskNV` `Execution` `Model`

- VUID-MeshViewCountNV-MeshViewCountNV-04288
  The variable decorated with `MeshViewCountNV` must be declared using the `Input` `Storage` `Class`

- VUID-MeshViewCountNV-MeshViewCountNV-04289
  The variable decorated with `MeshViewCountNV` must be declared as a scalar 32-bit integer value

`MeshViewIndicesNV`

  Decorating a variable with the `MeshViewIndicesNV` built-in decoration will make that variable contain the mesh view indices. The mesh view indices is an array of values where each element holds the view number of one of the views being processed by the current mesh or task shader invocations. The values of array elements with indices greater than or equal to `MeshViewCountNV` are undefined. If the value of `MeshViewIndicesNV`[i] is j, then any outputs decorated with `PerViewNV` will take on the value of array element i when processing primitives for view index j.

Valid Usage

- VUID-MeshViewIndicesNV-MeshViewIndicesNV-04290
  The `MeshViewIndicesNV` decoration must be used only within the `MeshNV` or `TaskNV` `Execution` `Model`

- VUID-MeshViewIndicesNV-MeshViewIndicesNV-04291
  The variable decorated with `MeshViewIndicesNV` must be declared using the `Input` `Storage` `Class`

- VUID-MeshViewIndicesNV-MeshViewIndicesNV-04292
  The variable decorated with `MeshViewIndicesNV` must be declared as an array of scalar 32-bit integer values

`NumSubgroups`

  Decorating a variable with the `NumSubgroups` built-in decoration will make that variable contain the number of subgroups in the local workgroup.

Valid Usage

- VUID-NumSubgroups-NumSubgroups-04293
  The `NumSubgroups` decoration must be used only within the `GLCompute`, `MeshEXT`, `TaskEXT`, `MeshNV`, or `TaskNV` `Execution` `Model`

- VUID-NumSubgroups-NumSubgroups-04294
  The variable decorated with `NumSubgroups` must be declared using the `Input` `Storage` `Class`

- VUID-NumSubgroups-NumSubgroups-04295
  The variable decorated with `NumSubgroups` must be declared as a scalar 32-bit integer value

`NumWorkgroups`

  Decorating a variable with the `NumWorkgroups` built-in decoration will make that variable contain the number of local workgroups that are part of the dispatch that the invocation belongs to. Each component is equal to the values of the workgroup count parameters passed into the dispatching commands.

Valid Usage

- VUID-NumWorkgroups-NumWorkgroups-04296
  The `NumWorkgroups` decoration must be used only within the `GLCompute`, `MeshEXT`, or `TaskEXT` `Execution` `Model`

- VUID-NumWorkgroups-NumWorkgroups-04297
  The variable decorated with `NumWorkgroups` must be declared using the `Input` `Storage` `Class`

- VUID-NumWorkgroups-NumWorkgroups-04298
  The variable decorated with `NumWorkgroups` must be declared as a three-component vector of 32-bit integer values

`ObjectRayDirectionKHR`

  A variable decorated with the `ObjectRayDirectionKHR` decoration will specify the direction of the ray being processed, in object space.

Valid Usage

- VUID-ObjectRayDirectionKHR-ObjectRayDirectionKHR-04299
  The `ObjectRayDirectionKHR` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, or `ClosestHitKHR` `Execution` `Model`

- VUID-ObjectRayDirectionKHR-ObjectRayDirectionKHR-04300
  The variable decorated with `ObjectRayDirectionKHR` must be declared using the `Input` `Storage` `Class`

- VUID-ObjectRayDirectionKHR-ObjectRayDirectionKHR-04301
  The variable decorated with `ObjectRayDirectionKHR` must be declared as a three-component vector of 32-bit floating-point values

`ObjectRayOriginKHR`

  A variable decorated with the `ObjectRayOriginKHR` decoration will specify the origin of the ray being processed, in object space.

Valid Usage

- VUID-ObjectRayOriginKHR-ObjectRayOriginKHR-04302
  The `ObjectRayOriginKHR` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, or `ClosestHitKHR` `Execution` `Model`

- VUID-ObjectRayOriginKHR-ObjectRayOriginKHR-04303
  The variable decorated with `ObjectRayOriginKHR` must be declared using the `Input` `Storage` `Class`

- VUID-ObjectRayOriginKHR-ObjectRayOriginKHR-04304
  The variable decorated with `ObjectRayOriginKHR` must be declared as a three-component vector of 32-bit floating-point values

`ObjectToWorldKHR`

  A variable decorated with the `ObjectToWorldKHR` decoration will contain the current object-to-world transformation matrix, which is determined by the instance of the current intersection.

Valid Usage

- VUID-ObjectToWorldKHR-ObjectToWorldKHR-04305
  The `ObjectToWorldKHR` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, or `ClosestHitKHR` `Execution` `Model`

- VUID-ObjectToWorldKHR-ObjectToWorldKHR-04306
  The variable decorated with `ObjectToWorldKHR` must be declared using the `Input` `Storage` `Class`

- VUID-ObjectToWorldKHR-ObjectToWorldKHR-04307
  The variable decorated with `ObjectToWorldKHR` must be declared as a matrix with four columns of three-component vectors of 32-bit floating-point values

`PatchVertices`

  Decorating a variable with the `PatchVertices` built-in decoration will make that variable contain the number of vertices in the input patch being processed by the shader. In a Tessellation Control Shader, this is the same as the name:patchControlPoints member of VkPipelineTessellationStateCreateInfo. In a Tessellation Evaluation Shader, `PatchVertices` is equal to the tessellation control output patch size. When the same shader is used in different pipelines where the patch sizes are configured differently, the value of the `PatchVertices` variable will also differ.

Valid Usage

- VUID-PatchVertices-PatchVertices-04308
  The `PatchVertices` decoration must be used only within the `TessellationControl` or `TessellationEvaluation` `Execution` `Model`

- VUID-PatchVertices-PatchVertices-04309
  The variable decorated with `PatchVertices` must be declared using the `Input` `Storage` `Class`

- VUID-PatchVertices-PatchVertices-04310
  The variable decorated with `PatchVertices` must be declared as a scalar 32-bit integer value

`PointCoord`

  Decorating a variable with the `PointCoord` built-in decoration will make that variable contain the coordinate of the current fragment within the point being rasterized, normalized to the size of the point with origin in the upper left corner of the point, as described in Basic Point Rasterization. If the primitive the fragment shader invocation belongs to is not a point, then the variable decorated with `PointCoord` contains an undefined value.

Note | Depending on how the point is rasterized, `PointCoord` may never reach (0,0) or (1,1).

Valid Usage

- VUID-PointCoord-PointCoord-04311
  The `PointCoord` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-PointCoord-PointCoord-04312
  The variable decorated with `PointCoord` must be declared using the `Input` `Storage` `Class`

- VUID-PointCoord-PointCoord-04313
  The variable decorated with `PointCoord` must be declared as a two-component vector of 32-bit floating-point values

`PointSize`

  Decorating a variable with the `PointSize` built-in decoration will make that variable contain the size of point primitives or the final rasterization of polygons if polygon mode is `VK_POLYGON_MODE_POINT` when `VkPhysicalDeviceMaintenance5Properties`::`polygonModePointSize` is set to `VK_TRUE` . The value written to the variable decorated with `PointSize` by the last pre-rasterization shader stage in the pipeline is used as the framebuffer-space size of points produced by rasterization. If the `maintenance5` feature is enabled and a value is not written to a variable decorated with `PointSize`, a value of 1.0 is used as the size of points.

Note | When `PointSize` decorates a variable in the `Input` `Storage` `Class`, it contains the data written to the output variable decorated with `PointSize` from the previous shader stage.

Valid Usage

- VUID-PointSize-PointSize-04314
  The `PointSize` decoration must be used only within the `MeshEXT`, `MeshNV`, `Vertex`, `TessellationControl`, `TessellationEvaluation`, or `Geometry` `Execution` `Model`

- VUID-PointSize-PointSize-04315
  The variable decorated with `PointSize` within the `MeshEXT`, `MeshNV`, or `Vertex` `Execution` `Model` must be declared using the `Output` `Storage` `Class`

- VUID-PointSize-PointSize-04316
  The variable decorated with `PointSize` within the `TessellationControl`, `TessellationEvaluation`, or `Geometry` `Execution` `Model` must not be declared using a `Storage` `Class` other than `Input` or `Output`

- VUID-PointSize-PointSize-04317
  The variable decorated with `PointSize` must be declared as a scalar 32-bit floating-point value

`Position`

  Decorating a variable with the `Position` built-in decoration will make that variable contain the position of the current vertex. In the last pre-rasterization shader stage, the value of the variable decorated with `Position` is used in subsequent primitive assembly, clipping, and rasterization operations.

Note | When `Position` decorates a variable in the `Input` `Storage` `Class`, it contains the data written to the output variable decorated with `Position` from the previous shader stage.

Valid Usage

- VUID-Position-Position-04318
  The `Position` decoration must be used only within the `MeshEXT`, `MeshNV`, `Vertex`, `TessellationControl`, `TessellationEvaluation`, or `Geometry` `Execution` `Model`

- VUID-Position-Position-04319
  The variable decorated with `Position` within the `MeshEXT`, `MeshNV`, or `Vertex` `Execution` `Model` must be declared using the `Output` `Storage` `Class`

- VUID-Position-Position-04320
  The variable decorated with `Position` within the `TessellationControl`, `TessellationEvaluation`, or `Geometry` `Execution` `Model` must not be declared using a `Storage` `Class` other than `Input` or `Output`

- VUID-Position-Position-04321
  The variable decorated with `Position` must be declared as a four-component vector of 32-bit floating-point values

`PositionPerViewNV`

  Decorating a variable with the `PositionPerViewNV` built-in decoration will make that variable contain the position of the current vertex, for each view.

  Elements of the array correspond to views in a multiview subpass, and those elements corresponding to views in the view mask of the subpass the shader is compiled against will be used as the position value for those views. For the final pre-rasterization shader stage in the pipeline, values written to an output variable decorated with `PositionPerViewNV` are used in subsequent primitive assembly, clipping, and rasterization operations, as with `Position`. `PositionPerViewNV` output in an earlier pre-rasterization shader stage is available as an input in the subsequent pre-rasterization shader stage.

  If a shader is compiled against a subpass that has the `VK_SUBPASS_DESCRIPTION_PER_VIEW_POSITION_X_ONLY_BIT_NVX` bit set, then the position values for each view must not differ in any component other than the X component. If the values do differ, one will be chosen in an implementation-dependent manner.

Valid Usage

- VUID-PositionPerViewNV-PositionPerViewNV-04322
  The `PositionPerViewNV` decoration must be used only within the `MeshNV`, `Vertex`, `TessellationControl`, `TessellationEvaluation`, or `Geometry` `Execution` `Model`

- VUID-PositionPerViewNV-PositionPerViewNV-04323
  The variable decorated with `PositionPerViewNV` within the `Vertex`, or `MeshNV` `Execution` `Model` must be declared using the `Output` `Storage` `Class`

- VUID-PositionPerViewNV-PositionPerViewNV-04324
  The variable decorated with `PositionPerViewNV` within the `TessellationControl`, `TessellationEvaluation`, or `Geometry` `Execution` `Model` must not be declared using a `Storage` `Class` other than `Input` or `Output`

- VUID-PositionPerViewNV-PositionPerViewNV-04325
  The variable decorated with `PositionPerViewNV` must be declared as an array of four-component vector of 32-bit floating-point values with at least as many elements as the maximum view in the subpass’s view mask plus one

- VUID-PositionPerViewNV-PositionPerViewNV-04326
  The array variable decorated with `PositionPerViewNV` must only be indexed by a constant or specialization constant

`PrimitiveCountNV`

  Decorating a variable with the `PrimitiveCountNV` decoration will make that variable contain the primitive count. The primitive count specifies the number of primitives in the output mesh produced by the mesh shader that will be processed by subsequent pipeline stages.

Valid Usage

- VUID-PrimitiveCountNV-PrimitiveCountNV-04327
  The `PrimitiveCountNV` decoration must be used only within the `MeshNV` `Execution` `Model`

- VUID-PrimitiveCountNV-PrimitiveCountNV-04328
  The variable decorated with `PrimitiveCountNV` must be declared using the `Output` `Storage` `Class`

- VUID-PrimitiveCountNV-PrimitiveCountNV-04329
  The variable decorated with `PrimitiveCountNV` must be declared as a scalar 32-bit integer value

`PrimitiveId`

  Decorating a variable with the `PrimitiveId` built-in decoration will make that variable contain the index of the current primitive.

  The index of the first primitive generated by a drawing command is zero, and the index is incremented after every individual point, line, or triangle primitive is processed.

  For triangles drawn as points or line segments (see Polygon Mode), the primitive index is incremented only once, even if multiple points or lines are eventually drawn.

  Variables decorated with `PrimitiveId` are reset to zero between each instance drawn.

  Restarting a primitive topology using primitive restart has no effect on the value of variables decorated with `PrimitiveId`.

  In tessellation control and tessellation evaluation shaders, it will contain the index of the patch within the current set of rendering primitives that corresponds to the shader invocation.

  In a geometry shader, it will contain the number of primitives presented as input to the shader since the current set of rendering primitives was started.

  In a fragment shader, it will contain the primitive index written by the mesh shader if a mesh shader is present, or the primitive index written by the geometry shader if a geometry shader is present, or with the value that would have been presented as input to the geometry shader had it been present.

  In an intersection, any-hit, or closest hit shader, it will contain the index within the geometry of the triangle or bounding box being processed.

Note | When the `PrimitiveId` decoration is applied to an output variable in the mesh shader or geometry shader, the resulting value is seen through the `PrimitiveId` decorated input variable in the fragment shader. The fragment shader using `PrimitiveId` will need to declare either the `MeshShadingNV`, `MeshShadingEXT`, `Geometry` or `Tessellation` capability to satisfy the requirement SPIR-V has to use `PrimitiveId`.

Valid Usage

- VUID-PrimitiveId-PrimitiveId-04330
  The `PrimitiveId` decoration must be used only within the `MeshEXT`, `MeshNV`, `IntersectionKHR`, `AnyHitKHR`, `ClosestHitKHR`, `TessellationControl`, `TessellationEvaluation`, `Geometry`, or `Fragment` `Execution` `Model`

- VUID-PrimitiveId-Fragment-04331
  If pipeline contains both the `Fragment` and `Geometry` `Execution` `Model` and a variable decorated with `PrimitiveId` is read from `Fragment` shader, then the `Geometry` shader must write to the output variables decorated with `PrimitiveId` in all execution paths

- VUID-PrimitiveId-Fragment-04332
  If pipeline contains both the `Fragment` and `MeshEXT` or `MeshNV` `Execution` `Model` and a variable decorated with `PrimitiveId` is read from `Fragment` shader, then the `MeshEXT` or `MeshNV` shader must write to the output variables decorated with `PrimitiveId` in all execution paths

- VUID-PrimitiveId-Fragment-04333
  If `Fragment` `Execution` `Model` contains a variable decorated with `PrimitiveId`, then either the `MeshShadingEXT`, `MeshShadingNV`, `Geometry` or `Tessellation` capability must also be declared

- VUID-PrimitiveId-PrimitiveId-04334
  The variable decorated with `PrimitiveId` within the `TessellationControl`, `TessellationEvaluation`, `Fragment`, `IntersectionKHR`, `AnyHitKHR`, or `ClosestHitKHR` `Execution` `Model` must be declared using the `Input` `Storage` `Class`

- VUID-PrimitiveId-PrimitiveId-04335
  The variable decorated with `PrimitiveId` within the `Geometry` `Execution` `Model` must be declared using the `Input` or `Output` `Storage` `Class`

- VUID-PrimitiveId-PrimitiveId-04336
  The variable decorated with `PrimitiveId` within the `MeshEXT` or `MeshNV` `Execution` `Model` must be declared using the `Output` `Storage` `Class`

- VUID-PrimitiveId-PrimitiveId-04337
  The variable decorated with `PrimitiveId` must be declared as a scalar 32-bit integer value

- VUID-PrimitiveId-PrimitiveId-07040
  The variable decorated with `PrimitiveId` within the `MeshEXT` `Execution` `Model` must also be decorated with the `PerPrimitiveEXT` decoration

`PrimitiveIndicesNV`

  Decorating a variable with the `PrimitiveIndicesNV` decoration will make that variable contain the output array of vertex index values. Depending on the output primitive type declared using the execution mode, the indices are split into groups of one (`OutputPoints`), two (`OutputLinesNV`), or three (`OutputTrianglesNV`) indices and each group generates a primitive.

Valid Usage

- VUID-PrimitiveIndicesNV-PrimitiveIndicesNV-04338
  The `PrimitiveIndicesNV` decoration must be used only within the `MeshNV` `Execution` `Model`

- VUID-PrimitiveIndicesNV-PrimitiveIndicesNV-04339
  The variable decorated with `PrimitiveIndicesNV` must be declared using the `Output` `Storage` `Class`

- VUID-PrimitiveIndicesNV-PrimitiveIndicesNV-04340
  The variable decorated with `PrimitiveIndicesNV` must be declared as an array of scalar 32-bit integer values

- VUID-PrimitiveIndicesNV-PrimitiveIndicesNV-04341
  All index values of the array decorated with `PrimitiveIndicesNV` must be in the range [0, N-1], where N is the value specified by the `OutputVertices` `Execution` `Mode`

- VUID-PrimitiveIndicesNV-OutputPoints-04342
  If the `Execution` `Mode` is `OutputPoints`, then the array decorated with `PrimitiveIndicesNV` must be the size of the value specified by `OutputPrimitivesNV`

- VUID-PrimitiveIndicesNV-OutputLinesNV-04343
  If the `Execution` `Mode` is `OutputLinesNV`, then the array decorated with `PrimitiveIndicesNV` must be the size of two times the value specified by `OutputPrimitivesNV`

- VUID-PrimitiveIndicesNV-OutputTrianglesNV-04344
  If the `Execution` `Mode` is `OutputTrianglesNV`, then the array decorated with `PrimitiveIndicesNV` must be the size of three times the value specified by `OutputPrimitivesNV`

`PrimitivePointIndicesEXT`

  Decorating a variable with the `PrimitivePointIndicesEXT` decoration will make that variable contain the output array of vertex index values for point primitives.

Valid Usage

- VUID-PrimitivePointIndicesEXT-PrimitivePointIndicesEXT-07041
  The `PrimitivePointIndicesEXT` decoration must be used only within the `MeshEXT` `Execution` `Model`

- VUID-PrimitivePointIndicesEXT-PrimitivePointIndicesEXT-07042
  The `PrimitivePointIndicesEXT` decoration must be used with the `OutputPoints` `Execution` `Mode`

- VUID-PrimitivePointIndicesEXT-PrimitivePointIndicesEXT-07043
  The variable decorated with `PrimitivePointIndicesEXT` must be declared using the `Output` `Storage` `Class`

- VUID-PrimitivePointIndicesEXT-PrimitivePointIndicesEXT-07044
  The variable decorated with `PrimitivePointIndicesEXT` must be declared as an array of scalar 32-bit integer values

- VUID-PrimitivePointIndicesEXT-PrimitivePointIndicesEXT-07045
  All index values of the array decorated with `PrimitivePointIndicesEXT` must be in the range [0, N-1], where N is the value specified by the `OutputVertices` `Execution` `Mode`

- VUID-PrimitivePointIndicesEXT-PrimitivePointIndicesEXT-07046
  The size of the array decorated with `PrimitivePointIndicesEXT` must match the value specified by `OutputPrimitivesEXT`

`PrimitiveLineIndicesEXT`

  Decorating a variable with the `PrimitiveLineIndicesEXT` decoration will make that variable contain the output array of vertex index values for line primitives.

Valid Usage

- VUID-PrimitiveLineIndicesEXT-PrimitiveLineIndicesEXT-07047
  The `PrimitiveLineIndicesEXT` decoration must be used only within the `MeshEXT` `Execution` `Model`

- VUID-PrimitiveLineIndicesEXT-PrimitiveLineIndicesEXT-07048
  The `PrimitiveLineIndicesEXT` decoration must be used with the `OutputLinesEXT` `Execution` `Mode`

- VUID-PrimitiveLineIndicesEXT-PrimitiveLineIndicesEXT-07049
  The variable decorated with `PrimitiveLineIndicesEXT` must be declared using the `Output` `Storage` `Class`

- VUID-PrimitiveLineIndicesEXT-PrimitiveLineIndicesEXT-07050
  The variable decorated with `PrimitiveLineIndicesEXT` must be declared as an array of two component vector 32-bit integer values

- VUID-PrimitiveLineIndicesEXT-PrimitiveLineIndicesEXT-07051
  All index values of the array decorated with `PrimitiveLineIndicesEXT` must be in the range [0, N-1], where N is the value specified by the `OutputVertices` `Execution` `Mode`

- VUID-PrimitiveLineIndicesEXT-PrimitiveLineIndicesEXT-07052
  The size of the array decorated with `PrimitiveLineIndicesEXT` must match the value specified by `OutputPrimitivesEXT`

`PrimitiveTriangleIndicesEXT`

  Decorating a variable with the `PrimitiveTriangleIndicesEXT` decoration will make that variable contain the output array of vertex index values for triangle primitives.

Valid Usage

- VUID-PrimitiveTriangleIndicesEXT-PrimitiveTriangleIndicesEXT-07053
  The `PrimitiveTriangleIndicesEXT` decoration must be used only within the `MeshEXT` `Execution` `Model`

- VUID-PrimitiveTriangleIndicesEXT-PrimitiveTriangleIndicesEXT-07054
  The `PrimitiveTriangleIndicesEXT` decoration must be used with the `OutputTrianglesEXT` `Execution` `Mode`

- VUID-PrimitiveTriangleIndicesEXT-PrimitiveTriangleIndicesEXT-07055
  The variable decorated with `PrimitiveTriangleIndicesEXT` must be declared using the `Output` `Storage` `Class`

- VUID-PrimitiveTriangleIndicesEXT-PrimitiveTriangleIndicesEXT-07056
  The variable decorated with `PrimitiveTriangleIndicesEXT` must be declared as an array of three component vector 32-bit integer values

- VUID-PrimitiveTriangleIndicesEXT-PrimitiveTriangleIndicesEXT-07057
  All index values of the array decorated with `PrimitiveTriangleIndicesEXT` must be in the range [0, N-1], where N is the value specified by the `OutputVertices` `Execution` `Mode`

- VUID-PrimitiveTriangleIndicesEXT-PrimitiveTriangleIndicesEXT-07058
  The size of the array decorated with `PrimitiveTriangleIndicesEXT` must match the value specified by `OutputPrimitivesEXT`

`PrimitiveShadingRateKHR`

  Decorating a variable with the `PrimitiveShadingRateKHR` built-in decoration will make that variable contain the primitive fragment shading rate.

  The value written to the variable decorated with `PrimitiveShadingRateKHR` by the last pre-rasterization shader stage in the pipeline is used as the primitive fragment shading rate. Outputs in previous shader stages are ignored.

  If the last active pre-rasterization shader stage shader entry point’s interface does not include a variable decorated with `PrimitiveShadingRateKHR`, then it is as if the shader specified a fragment shading rate value of 0, indicating a horizontal and vertical rate of 1 pixel.

  If a shader has `PrimitiveShadingRateKHR` in the output interface and there is an execution path through the shader that does not write to it, its value is undefined for executions of the shader that take that path.

Valid Usage

- VUID-PrimitiveShadingRateKHR-PrimitiveShadingRateKHR-04484
  The `PrimitiveShadingRateKHR` decoration must be used only within the `MeshEXT`, `MeshNV`, `Vertex`, or `Geometry` `Execution` `Model`

- VUID-PrimitiveShadingRateKHR-PrimitiveShadingRateKHR-04485
  The variable decorated with `PrimitiveShadingRateKHR` must be declared using the `Output` `Storage` `Class`

- VUID-PrimitiveShadingRateKHR-PrimitiveShadingRateKHR-04486
  The variable decorated with `PrimitiveShadingRateKHR` must be declared as a scalar 32-bit integer value

- VUID-PrimitiveShadingRateKHR-PrimitiveShadingRateKHR-04487
  The value written to `PrimitiveShadingRateKHR` must include no more than one of `Vertical2Pixels` and `Vertical4Pixels`

- VUID-PrimitiveShadingRateKHR-PrimitiveShadingRateKHR-04488
  The value written to `PrimitiveShadingRateKHR` must include no more than one of `Horizontal2Pixels` and `Horizontal4Pixels`

- VUID-PrimitiveShadingRateKHR-PrimitiveShadingRateKHR-04489
  The value written to `PrimitiveShadingRateKHR` must not have any bits set other than those defined by Fragment Shading Rate Flags enumerants in the SPIR-V specification

- VUID-PrimitiveShadingRateKHR-PrimitiveShadingRateKHR-07059
  The variable decorated with `PrimitiveShadingRateKHR` within the `MeshEXT` `Execution` `Model` must also be decorated with the `PerPrimitiveEXT` decoration

`RayGeometryIndexKHR`

  A variable decorated with the `RayGeometryIndexKHR` decoration will contain the geometry index for the acceleration structure geometry currently being shaded.

Valid Usage

- VUID-RayGeometryIndexKHR-RayGeometryIndexKHR-04345
  The `RayGeometryIndexKHR` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, or `ClosestHitKHR` `Execution` `Model`

- VUID-RayGeometryIndexKHR-RayGeometryIndexKHR-04346
  The variable decorated with `RayGeometryIndexKHR` must be declared using the `Input` `Storage` `Class`

- VUID-RayGeometryIndexKHR-RayGeometryIndexKHR-04347
  The variable decorated with `RayGeometryIndexKHR` must be declared as a scalar 32-bit integer value

`RayTmaxKHR`

  A variable decorated with the `RayTmaxKHR` decoration will contain the parametric tmax value of the ray being processed. The value is independent of the space in which the ray origin and direction exist. The value is initialized to the parameter passed into the pipeline trace ray instruction.

  The tmax value changes throughout the lifetime of the ray that produced the intersection. In the closest hit shader, the value reflects the closest distance to the intersected primitive. In the any-hit shader, it reflects the distance to the primitive currently being intersected. In the intersection shader, it reflects the distance to the closest primitive intersected so far or the initial value. The value can change in the intersection shader after calling `OpReportIntersectionKHR` if the corresponding any-hit shader does not ignore the intersection. In a miss shader, the value is identical to the parameter passed into the pipeline trace ray instruction.

Valid Usage

- VUID-RayTmaxKHR-RayTmaxKHR-04348
  The `RayTmaxKHR` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, `ClosestHitKHR`, or `MissKHR` `Execution` `Model`

- VUID-RayTmaxKHR-RayTmaxKHR-04349
  The variable decorated with `RayTmaxKHR` must be declared using the `Input` `Storage` `Class`

- VUID-RayTmaxKHR-RayTmaxKHR-04350
  The variable decorated with `RayTmaxKHR` must be declared as a scalar 32-bit floating-point value

`RayTminKHR`

  A variable decorated with the `RayTminKHR` decoration will contain the parametric tmin value of the ray being processed. The value is independent of the space in which the ray origin and direction exist. The value is the parameter passed into the pipeline trace ray instruction.

  The tmin value remains constant for the duration of the ray query.

Valid Usage

- VUID-RayTminKHR-RayTminKHR-04351
  The `RayTminKHR` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, `ClosestHitKHR`, or `MissKHR` `Execution` `Model`

- VUID-RayTminKHR-RayTminKHR-04352
  The variable decorated with `RayTminKHR` must be declared using the `Input` `Storage` `Class`

- VUID-RayTminKHR-RayTminKHR-04353
  The variable decorated with `RayTminKHR` must be declared as a scalar 32-bit floating-point value

`SampleId`

  Decorating a variable with the `SampleId` built-in decoration will make that variable contain the coverage index for the current fragment shader invocation. `SampleId` ranges from zero to the number of samples in the framebuffer minus one. If a fragment shader entry point’s interface includes an input variable decorated with `SampleId`, Sample Shading is considered enabled with a `minSampleShading` value of 1.0.

Valid Usage

- VUID-SampleId-SampleId-04354
  The `SampleId` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-SampleId-SampleId-04355
  The variable decorated with `SampleId` must be declared using the `Input` `Storage` `Class`

- VUID-SampleId-SampleId-04356
  The variable decorated with `SampleId` must be declared as a scalar 32-bit integer value

`SampleMask`

  Decorating a variable with the `SampleMask` built-in decoration will make any variable contain the sample mask for the current fragment shader invocation.

  A variable in the `Input` storage class decorated with `SampleMask` will contain a bitmask of the set of samples covered by the primitive generating the fragment during rasterization. It has a sample bit set if and only if the sample is considered covered for this fragment shader invocation. `SampleMask`[] is an array of integers. Bits are mapped to samples in a manner where bit B of mask M (`SampleMask[M]`) corresponds to sample 32 × M + B.

  A variable in the `Output` storage class decorated with `SampleMask` is an array of integers forming a bit array in a manner similar to an input variable decorated with `SampleMask`, but where each bit represents coverage as computed by the shader. This computed `SampleMask` is combined with the generated coverage mask in the multisample coverage operation.

  Variables decorated with `SampleMask` must be either an unsized array, or explicitly sized to be no larger than the implementation-dependent maximum sample-mask (as an array of 32-bit elements), determined by the maximum number of samples.

  If a fragment shader entry point’s interface includes an output variable decorated with `SampleMask`, the sample mask will be undefined for any array elements of any fragment shader invocations that fail to assign a value. If a fragment shader entry point’s interface does not include an output variable decorated with `SampleMask`, the sample mask has no effect on the processing of a fragment.

Valid Usage

- VUID-SampleMask-SampleMask-04357
  The `SampleMask` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-SampleMask-SampleMask-04358
  The variable decorated with `SampleMask` must be declared using the `Input` or `Output` `Storage` `Class`

- VUID-SampleMask-SampleMask-04359
  The variable decorated with `SampleMask` must be declared as an array of 32-bit integer values

`SamplePosition`

  Decorating a variable with the `SamplePosition` built-in decoration will make that variable contain the sub-pixel position of the sample being shaded. The top left of the pixel is considered to be at coordinate (0,0) and the bottom right of the pixel is considered to be at coordinate (1,1).

  If the render pass has a fragment density map attachment, the variable will instead contain the sub-fragment position of the sample being shaded. The top left of the fragment is considered to be at coordinate (0,0) and the bottom right of the fragment is considered to be at coordinate (1,1) for any fragment area.

  If a fragment shader entry point’s interface includes an input variable decorated with `SamplePosition`, Sample Shading is considered enabled with a `minSampleShading` value of 1.0.

  If the current pipeline uses custom sample locations the value of any variable decorated with the `SamplePosition` built-in decoration is undefined.

Valid Usage

- VUID-SamplePosition-SamplePosition-04360
  The `SamplePosition` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-SamplePosition-SamplePosition-04361
  The variable decorated with `SamplePosition` must be declared using the `Input` `Storage` `Class`

- VUID-SamplePosition-SamplePosition-04362
  The variable decorated with `SamplePosition` must be declared as a two-component vector of 32-bit floating-point values

`ShadingRateKHR`

  Decorating a variable with the `ShadingRateKHR` built-in decoration will make that variable contain the fragment shading rate for the current fragment invocation.

Valid Usage

- VUID-ShadingRateKHR-ShadingRateKHR-04490
  The `ShadingRateKHR` decoration must be used only within the `Fragment` `Execution` `Model`

- VUID-ShadingRateKHR-ShadingRateKHR-04491
  The variable decorated with `ShadingRateKHR` must be declared using the `Input` `Storage` `Class`

- VUID-ShadingRateKHR-ShadingRateKHR-04492
  The variable decorated with `ShadingRateKHR` must be declared as a scalar 32-bit integer value

`SMCountNV`

  Decorating a variable with the `SMCountNV` built-in decoration will make that variable contain the number of SMs on the device.

Valid Usage

- VUID-SMCountNV-SMCountNV-04363
  The variable decorated with `SMCountNV` must be declared using the `Input` `Storage` `Class`

- VUID-SMCountNV-SMCountNV-04364
  The variable decorated with `SMCountNV` must be declared as a scalar 32-bit integer value

`SMIDNV`

  Decorating a variable with the `SMIDNV` built-in decoration will make that variable contain the ID of the SM on which the current shader invocation is running. This variable is in the range [0, `SMCountNV`-1].

Valid Usage

- VUID-SMIDNV-SMIDNV-04365
  The variable decorated with `SMIDNV` must be declared using the `Input` `Storage` `Class`

- VUID-SMIDNV-SMIDNV-04366
  The variable decorated with `SMIDNV` must be declared as a scalar 32-bit integer value

`SubgroupId`

  Decorating a variable with the `SubgroupId` built-in decoration will make that variable contain the index of the subgroup within the local workgroup. This variable is in range [0, `NumSubgroups`-1].

Valid Usage

- VUID-SubgroupId-SubgroupId-04367
  The `SubgroupId` decoration must be used only within the `GLCompute`, `MeshEXT`, `TaskEXT`, `MeshNV`, or `TaskNV` `Execution` `Model`

- VUID-SubgroupId-SubgroupId-04368
  The variable decorated with `SubgroupId` must be declared using the `Input` `Storage` `Class`

- VUID-SubgroupId-SubgroupId-04369
  The variable decorated with `SubgroupId` must be declared as a scalar 32-bit integer value

`SubgroupEqMask`

  Decorating a variable with the `SubgroupEqMask` builtin decoration will make that variable contain the subgroup mask of the current subgroup invocation. The bit corresponding to the `SubgroupLocalInvocationId` is set in the variable decorated with `SubgroupEqMask`. All other bits are set to zero.

  `SubgroupEqMaskKHR` is an alias of `SubgroupEqMask`.

Valid Usage

- VUID-SubgroupEqMask-SubgroupEqMask-04370
  The variable decorated with `SubgroupEqMask` must be declared using the `Input` `Storage` `Class`

- VUID-SubgroupEqMask-SubgroupEqMask-04371
  The variable decorated with `SubgroupEqMask` must be declared as a four-component vector of 32-bit integer values

`SubgroupGeMask`

  Decorating a variable with the `SubgroupGeMask` builtin decoration will make that variable contain the subgroup mask of the current subgroup invocation. The bits corresponding to the invocations greater than or equal to `SubgroupLocalInvocationId` through `SubgroupSize`-1 are set in the variable decorated with `SubgroupGeMask`. All other bits are set to zero.

  `SubgroupGeMaskKHR` is an alias of `SubgroupGeMask`.

Valid Usage

- VUID-SubgroupGeMask-SubgroupGeMask-04372
  The variable decorated with `SubgroupGeMask` must be declared using the `Input` `Storage` `Class`

- VUID-SubgroupGeMask-SubgroupGeMask-04373
  The variable decorated with `SubgroupGeMask` must be declared as a four-component vector of 32-bit integer values

`SubgroupGtMask`

  Decorating a variable with the `SubgroupGtMask` builtin decoration will make that variable contain the subgroup mask of the current subgroup invocation. The bits corresponding to the invocations greater than `SubgroupLocalInvocationId` through `SubgroupSize`-1 are set in the variable decorated with `SubgroupGtMask`. All other bits are set to zero.

  `SubgroupGtMaskKHR` is an alias of `SubgroupGtMask`.

Valid Usage

- VUID-SubgroupGtMask-SubgroupGtMask-04374
  The variable decorated with `SubgroupGtMask` must be declared using the `Input` `Storage` `Class`

- VUID-SubgroupGtMask-SubgroupGtMask-04375
  The variable decorated with `SubgroupGtMask` must be declared as a four-component vector of 32-bit integer values

`SubgroupLeMask`

  Decorating a variable with the `SubgroupLeMask` builtin decoration will make that variable contain the subgroup mask of the current subgroup invocation. The bits corresponding to the invocations less than or equal to `SubgroupLocalInvocationId` are set in the variable decorated with `SubgroupLeMask`. All other bits are set to zero.

  `SubgroupLeMaskKHR` is an alias of `SubgroupLeMask`.

Valid Usage

- VUID-SubgroupLeMask-SubgroupLeMask-04376
  The variable decorated with `SubgroupLeMask` must be declared using the `Input` `Storage` `Class`

- VUID-SubgroupLeMask-SubgroupLeMask-04377
  The variable decorated with `SubgroupLeMask` must be declared as a four-component vector of 32-bit integer values

`SubgroupLtMask`

  Decorating a variable with the `SubgroupLtMask` builtin decoration will make that variable contain the subgroup mask of the current subgroup invocation. The bits corresponding to the invocations less than `SubgroupLocalInvocationId` are set in the variable decorated with `SubgroupLtMask`. All other bits are set to zero.

  `SubgroupLtMaskKHR` is an alias of `SubgroupLtMask`.

Valid Usage

- VUID-SubgroupLtMask-SubgroupLtMask-04378
  The variable decorated with `SubgroupLtMask` must be declared using the `Input` `Storage` `Class`

- VUID-SubgroupLtMask-SubgroupLtMask-04379
  The variable decorated with `SubgroupLtMask` must be declared as a four-component vector of 32-bit integer values

`SubgroupLocalInvocationId`

  Decorating a variable with the `SubgroupLocalInvocationId` builtin decoration will make that variable contain the index of the invocation within the subgroup. This variable is in range [0,`SubgroupSize`-1].

  If `VK_PIPELINE_SHADER_STAGE_CREATE_REQUIRE_FULL_SUBGROUPS_BIT` is specified, or if `module` declares SPIR-V version 1.6 or higher, and the local workgroup size in the X dimension of the `stage` is a multiple of `SubgroupSize`, full subgroups are enabled for that pipeline stage. When full subgroups are enabled, subgroups must be launched with all invocations active, i.e., there is an active invocation with `SubgroupLocalInvocationId` for each value in range [0,`SubgroupSize`-1].

Note | There is no direct relationship between `SubgroupLocalInvocationId` and `LocalInvocationId` or `LocalInvocationIndex`. If the pipeline or shader object was created with full subgroups applications can compute their own local invocation index to serve the same purpose: index = `SubgroupLocalInvocationId` + `SubgroupId` × `SubgroupSize` If full subgroups are not enabled, some subgroups may be dispatched with inactive invocations that do not correspond to a local workgroup invocation, making the value of index unreliable.

Note | `VK_PIPELINE_SHADER_STAGE_CREATE_REQUIRE_FULL_SUBGROUPS_BIT` and `VK_SHADER_CREATE_REQUIRE_FULL_SUBGROUPS_BIT_EXT` are effectively deprecated when compiling SPIR-V 1.6 shaders, as this behavior is the default for Vulkan with SPIR-V 1.6. This is more aligned with developer expectations, and avoids applications unexpectedly breaking in the future.

Valid Usage

- VUID-SubgroupLocalInvocationId-SubgroupLocalInvocationId-04380
  The variable decorated with `SubgroupLocalInvocationId` must be declared using the `Input` `Storage` `Class`

- VUID-SubgroupLocalInvocationId-SubgroupLocalInvocationId-04381
  The variable decorated with `SubgroupLocalInvocationId` must be declared as a scalar 32-bit integer value

`SubgroupSize`

  Decorating a variable with the `SubgroupSize` builtin decoration will make that variable contain the implementation-dependent number of invocations in a subgroup. This value must be a power-of-two integer.

  If the pipeline was created with the `VK_PIPELINE_SHADER_STAGE_CREATE_ALLOW_VARYING_SUBGROUP_SIZE_BIT` flag set, or the shader object was created with the `VK_SHADER_CREATE_ALLOW_VARYING_SUBGROUP_SIZE_BIT_EXT` flag set, or the SPIR-V `module` is at least version 1.6, the `SubgroupSize` decorated variable will contain the subgroup size for each subgroup that gets dispatched. This value must be between `minSubgroupSize` and `maxSubgroupSize` and must be uniform with subgroup scope. The value may vary across a single draw call, and for fragment shaders may vary across a single primitive. In compute dispatches, `SubgroupSize` must be uniform with command scope.

  If the pipeline was created with a chained VkPipelineShaderStageRequiredSubgroupSizeCreateInfo structure, or the shader object was created with a chained VkShaderRequiredSubgroupSizeCreateInfoEXT structure, the `SubgroupSize` decorated variable will match `requiredSubgroupSize`.

  If SPIR-V `module` is less than version 1.6 and the pipeline was not created with the `VK_PIPELINE_SHADER_STAGE_CREATE_ALLOW_VARYING_SUBGROUP_SIZE_BIT` flag set and no VkPipelineShaderStageRequiredSubgroupSizeCreateInfo structure was chained, and the shader was not created with the `VK_SHADER_CREATE_ALLOW_VARYING_SUBGROUP_SIZE_BIT_EXT` flag set and no VkShaderRequiredSubgroupSizeCreateInfoEXT structure was chained, the variable decorated with `SubgroupSize` will match `subgroupSize`.

  The maximum number of invocations that an implementation can support per subgroup is 128.

Note | The old behavior for `SubgroupSize` is considered deprecated as certain compute algorithms cannot be easily implemented without the guarantees of `VK_PIPELINE_SHADER_STAGE_CREATE_ALLOW_VARYING_SUBGROUP_SIZE_BIT` and `VK_PIPELINE_SHADER_STAGE_CREATE_REQUIRE_FULL_SUBGROUPS_BIT`.

Valid Usage

- VUID-SubgroupSize-SubgroupSize-04382
  The variable decorated with `SubgroupSize` must be declared using the `Input` `Storage` `Class`

- VUID-SubgroupSize-SubgroupSize-04383
  The variable decorated with `SubgroupSize` must be declared as a scalar 32-bit integer value

`TaskCountNV`

  Decorating a variable with the `TaskCountNV` decoration will make that variable contain the task count. The task count specifies the number of subsequent mesh shader workgroups that get generated upon completion of the task shader.

Valid Usage

- VUID-TaskCountNV-TaskCountNV-04384
  The `TaskCountNV` decoration must be used only within the `TaskNV` `Execution` `Model`

- VUID-TaskCountNV-TaskCountNV-04385
  The variable decorated with `TaskCountNV` must be declared using the `Output` `Storage` `Class`

- VUID-TaskCountNV-TaskCountNV-04386
  The variable decorated with `TaskCountNV` must be declared as a scalar 32-bit integer value

`TessCoord`

  Decorating a variable with the `TessCoord` built-in decoration will make that variable contain the three-dimensional (u,v,w) barycentric coordinate of the tessellated vertex within the patch. u, v, and w are in the range [0,1] and vary linearly across the primitive being subdivided. For the tessellation modes of `Quads` or `IsoLines`, the third component is always zero.

Valid Usage

- VUID-TessCoord-TessCoord-04387
  The `TessCoord` decoration must be used only within the `TessellationEvaluation` `Execution` `Model`

- VUID-TessCoord-TessCoord-04388
  The variable decorated with `TessCoord` must be declared using the `Input` `Storage` `Class`

- VUID-TessCoord-TessCoord-04389
  The variable decorated with `TessCoord` must be declared as a three-component vector of 32-bit floating-point values

`TessLevelOuter`

  Decorating a variable with the `TessLevelOuter` built-in decoration will make that variable contain the outer tessellation levels for the current patch.

  In tessellation control shaders, the variable decorated with `TessLevelOuter` can be written to, controlling the tessellation factors for the resulting patch. These values are used by the tessellator to control primitive tessellation and can be read by tessellation evaluation shaders.

  In tessellation evaluation shaders, the variable decorated with `TessLevelOuter` can read the values written by the tessellation control shader.

Valid Usage

- VUID-TessLevelOuter-TessLevelOuter-04390
  The `TessLevelOuter` decoration must be used only within the `TessellationControl` or `TessellationEvaluation` `Execution` `Model`

- VUID-TessLevelOuter-TessLevelOuter-04391
  The variable decorated with `TessLevelOuter` within the `TessellationControl` `Execution` `Model` must be declared using the `Output` `Storage` `Class`

- VUID-TessLevelOuter-TessLevelOuter-04392
  The variable decorated with `TessLevelOuter` within the `TessellationEvaluation` `Execution` `Model` must be declared using the `Input` `Storage` `Class`

- VUID-TessLevelOuter-TessLevelOuter-04393
  The variable decorated with `TessLevelOuter` must be declared as an array of size four, containing 32-bit floating-point values

`TessLevelInner`

  Decorating a variable with the `TessLevelInner` built-in decoration will make that variable contain the inner tessellation levels for the current patch.

  In tessellation control shaders, the variable decorated with `TessLevelInner` can be written to, controlling the tessellation factors for the resulting patch. These values are used by the tessellator to control primitive tessellation and can be read by tessellation evaluation shaders.

  In tessellation evaluation shaders, the variable decorated with `TessLevelInner` can read the values written by the tessellation control shader.

Valid Usage

- VUID-TessLevelInner-TessLevelInner-04394
  The `TessLevelInner` decoration must be used only within the `TessellationControl` or `TessellationEvaluation` `Execution` `Model`

- VUID-TessLevelInner-TessLevelInner-04395
  The variable decorated with `TessLevelInner` within the `TessellationControl` `Execution` `Model` must be declared using the `Output` `Storage` `Class`

- VUID-TessLevelInner-TessLevelInner-04396
  The variable decorated with `TessLevelInner` within the `TessellationEvaluation` `Execution` `Model` must be declared using the `Input` `Storage` `Class`

- VUID-TessLevelInner-TessLevelInner-04397
  The variable decorated with `TessLevelInner` must be declared as an array of size two, containing 32-bit floating-point values

`VertexCountHUAWEI`

  The `VertexCountHUAWEI` decoration can be used to decorate a cluster culling shader output variable,this non-indexed mode specific variable will contain an integer value that specifies the number of vertices in a cluster to draw.

Valid Usage

- VUID-VertexCountHUAWEI-VertexCountHUAWEI-07809
  The `VertexCountHUAWEI` decoration must be used only within the `ClusterCullingHUAWEI` `Execution` `Model`

- VUID-VertexCountHUAWEI-VertexCountHUAWEI-07810
  The variable decorated with `VertexCountHUAWEI` must be declared as a scalar 32-bit integer value

`VertexIndex`

  Decorating a variable with the `VertexIndex` built-in decoration will make that variable contain the index of the vertex that is being processed by the current vertex shader invocation. For non-indexed draws, this variable begins at the `firstVertex` parameter to vkCmdDraw or the `firstVertex` member of a structure consumed by vkCmdDrawIndirect and increments by one for each vertex in the draw. For indexed draws, its value is the content of the index buffer for the vertex plus the `vertexOffset` parameter to vkCmdDrawIndexed or the `vertexOffset` member of the structure consumed by vkCmdDrawIndexedIndirect.

Note | `VertexIndex` starts at the same starting value for each instance.

Valid Usage

- VUID-VertexIndex-VertexIndex-04398
  The `VertexIndex` decoration must be used only within the `Vertex` `Execution` `Model`

- VUID-VertexIndex-VertexIndex-04399
  The variable decorated with `VertexIndex` must be declared using the `Input` `Storage` `Class`

- VUID-VertexIndex-VertexIndex-04400
  The variable decorated with `VertexIndex` must be declared as a scalar 32-bit integer value

`VertexOffsetHUAWEI`

  The `VertexOffsetHUAWEI` decoration can be used to decorate a cluster culling shader output variable,this indexed mode specific variable will contain an integer value that specifies an offset value added to the vertex index of a cluster before indexing into the vertex buffer.

Valid Usage

- VUID-VertexOffsetHUAWEI-VertexOffsetHUAWEI-07811
  The `VertexOffsetHUAWEI` decoration must be used only within the `ClusterCullingHUAWEI` `Execution` `Model`

- VUID-VertexOffsetHUAWEI-VertexOffsetHUAWEI-07812
  The variable decorated with `VertexOffsetHUAWEI` must be declared as a scalar 32-bit integer value

`ViewIndex`

  The `ViewIndex` decoration can be applied to a shader input which will be filled with the index of the view that is being processed by the current shader invocation.

  If multiview is enabled in the render pass, this value will be the index of one of the bits set in the view mask of the subpass the pipeline is compiled against. If multiview is not enabled in the render pass, this value will be zero.

Valid Usage

- VUID-ViewIndex-ViewIndex-04401
  The `ViewIndex` decoration must be used only within the `MeshEXT`, `Vertex`, `Geometry`, `TessellationControl`, `TessellationEvaluation` or `Fragment` `Execution` `Model`

- VUID-ViewIndex-ViewIndex-04402
  The variable decorated with `ViewIndex` must be declared using the `Input` `Storage` `Class`

- VUID-ViewIndex-ViewIndex-04403
  The variable decorated with `ViewIndex` must be declared as a scalar 32-bit integer value

`ViewportIndex`

  Decorating a variable with the `ViewportIndex` built-in decoration will make that variable contain the index of the viewport.

  In a mesh, vertex, tessellation evaluation, or geometry shader, the variable decorated with `ViewportIndex` can be written to with the viewport index to which the primitive produced by that shader will be directed.

  The selected viewport index is used to select the viewport transform, scissor rectangle, and exclusive scissor rectangle.

  The last active pre-rasterization shader stage (in pipeline order) controls the `ViewportIndex` that is used. Outputs in previous shader stages are not used, even if the last stage fails to write the `ViewportIndex`.

  If the last active pre-rasterization shader stage shader entry point’s interface does not include a variable decorated with `ViewportIndex` , and if the multiviewPerViewViewports feature is not enabled, then the first viewport is used. If a pre-rasterization shader stage shader entry point’s interface includes a variable decorated with `ViewportIndex`, it must write the same value to `ViewportIndex` for all output vertices of a given primitive.

  In a fragment shader, the variable decorated with `ViewportIndex` contains the viewport index of the primitive that the fragment invocation belongs to.

  If the `multiviewPerViewViewports` feature is enabled, and if the last active pre-rasterization shader stage shader entry point’s interface does not include a variable decorated with `ViewportIndex`, then the value of `ViewIndex` is used as an index to select the viewport transform and scissor rectangle, and the value of `ViewportIndex` in the fragment shader is undefined:.

Valid Usage

- VUID-ViewportIndex-ViewportIndex-04404
  The `ViewportIndex` decoration must be used only within the `MeshEXT`, `MeshNV`, `Vertex`, `TessellationEvaluation`, `Geometry`, or `Fragment` `Execution` `Model`

- VUID-ViewportIndex-ViewportIndex-04405
  If the `shaderOutputViewportIndex` feature is not enabled then the `ViewportIndex` decoration must be used only within the `Geometry` or `Fragment` `Execution` `Model`

- VUID-ViewportIndex-ViewportIndex-04406
  The variable decorated with `ViewportIndex` within the `MeshEXT`, `MeshNV`, `Vertex`, `TessellationEvaluation`, or `Geometry` `Execution` `Model` must be declared using the `Output` `Storage` `Class`

- VUID-ViewportIndex-ViewportIndex-04407
  The variable decorated with `ViewportIndex` within the `Fragment` `Execution` `Model` must be declared using the `Input` `Storage` `Class`

- VUID-ViewportIndex-ViewportIndex-04408
  The variable decorated with `ViewportIndex` must be declared as a scalar 32-bit integer value

- VUID-ViewportIndex-ViewportIndex-07060
  The variable decorated with `ViewportIndex` within the `MeshEXT` `Execution` `Model` must also be decorated with the `PerPrimitiveEXT` decoration

`ViewportMaskNV`

  Decorating a variable with the `ViewportMaskNV` built-in decoration will make that variable contain the viewport mask.

  In a mesh, vertex, tessellation evaluation, or geometry shader, the variable decorated with `ViewportMaskNV` can be written to with the mask of which viewports the primitive produced by that shader will directed.

  The `ViewportMaskNV` variable must be an array that has ⌈(`VkPhysicalDeviceLimits`::`maxViewports` / 32)⌉ elements. When a shader writes to this variable, bit B of element M controls whether a primitive is emitted to viewport 32 × M + B. The viewports indicated by the mask are used to select the viewport transform, scissor rectangle, and exclusive scissor rectangle that a primitive will be transformed by.

  The last active pre-rasterization shader stage (in pipeline order) controls the `ViewportMaskNV` that is used. Outputs in previous shader stages are not used, even if the last stage fails to write the `ViewportMaskNV`. When `ViewportMaskNV` is written by the final pre-rasterization shader stage, any variable decorated with `ViewportIndex` in the fragment shader will have the index of the viewport that was used in generating that fragment.

  If a pre-rasterization shader stage shader entry point’s interface includes a variable decorated with `ViewportMaskNV`, it must write the same value to `ViewportMaskNV` for all output vertices of a given primitive.

Valid Usage

- VUID-ViewportMaskNV-ViewportMaskNV-04409
  The `ViewportMaskNV` decoration must be used only within the `Vertex`, `MeshNV`, `TessellationEvaluation`, or `Geometry` `Execution` `Model`

- VUID-ViewportMaskNV-ViewportMaskNV-04410
  The variable decorated with `ViewportMaskNV` must be declared using the `Output` `Storage` `Class`

- VUID-ViewportMaskNV-ViewportMaskNV-04411
  The variable decorated with `ViewportMaskNV` must be declared as an array of 32-bit integer values

`ViewportMaskPerViewNV`

  Decorating a variable with the `ViewportMaskPerViewNV` built-in decoration will make that variable contain the mask of viewports primitives are broadcast to, for each view.

  The value written to an element of `ViewportMaskPerViewNV` in the last pre-rasterization shader stage is a bitmask indicating which viewports the primitive will be directed to. The primitive will be broadcast to the viewport corresponding to each non-zero bit of the bitmask, and that viewport index is used to select the viewport transform, scissor rectangle, and exclusive scissor rectangle, for each view. The same values must be written to all vertices in a given primitive, or else the set of viewports used for that primitive is undefined.

  Elements of the array correspond to views in a multiview subpass, and those elements corresponding to views in the view mask of the subpass the shader is compiled against will be used as the viewport mask value for those views. `ViewportMaskPerViewNV` output in an earlier pre-rasterization shader stage is not available as an input in the subsequent pre-rasterization shader stage.

  Although `ViewportMaskNV` is an array, `ViewportMaskPerViewNV` is not a two-dimensional array. Instead, `ViewportMaskPerViewNV` is limited to 32 viewports.

Valid Usage

- VUID-ViewportMaskPerViewNV-ViewportMaskPerViewNV-04412
  The `ViewportMaskPerViewNV` decoration must be used only within the `Vertex`, `MeshNV`, `TessellationControl`, `TessellationEvaluation`, or `Geometry` `Execution` `Model`

- VUID-ViewportMaskPerViewNV-ViewportMaskPerViewNV-04413
  The variable decorated with `ViewportMaskPerViewNV` must be declared using the `Output` `Storage` `Class`

- VUID-ViewportMaskPerViewNV-ViewportMaskPerViewNV-04414
  The variable decorated with `ViewportMaskPerViewNV` must be declared as an array of 32-bit integer values

- VUID-ViewportMaskPerViewNV-ViewportMaskPerViewNV-04415
  The array decorated with `ViewportMaskPerViewNV` must be a size less than or equal to 32

- VUID-ViewportMaskPerViewNV-ViewportMaskPerViewNV-04416
  The array decorated with `ViewportMaskPerViewNV` must be a size greater than the maximum view in the subpass’s view mask

- VUID-ViewportMaskPerViewNV-ViewportMaskPerViewNV-04417
  The array variable decorated with `ViewportMaskPerViewNV` must only be indexed by a constant or specialization constant

`WarpsPerSMNV`

  Decorating a variable with the `WarpsPerSMNV` built-in decoration will make that variable contain the maximum number of warps executing on a SM.

Valid Usage

- VUID-WarpsPerSMNV-WarpsPerSMNV-04418
  The variable decorated with `WarpsPerSMNV` must be declared using the `Input` `Storage` `Class`

- VUID-WarpsPerSMNV-WarpsPerSMNV-04419
  The variable decorated with `WarpsPerSMNV` must be declared as a scalar 32-bit integer value

`WarpIDNV`

  Decorating a variable with the `WarpIDNV` built-in decoration will make that variable contain the ID of the warp on a SM on which the current shader invocation is running. This variable is in the range [0, `WarpsPerSMNV`-1].

Valid Usage

- VUID-WarpIDNV-WarpIDNV-04420
  The variable decorated with `WarpIDNV` must be declared using the `Input` `Storage` `Class`

- VUID-WarpIDNV-WarpIDNV-04421
  The variable decorated with `WarpIDNV` must be declared as a scalar 32-bit integer value

`WorkgroupId`

  Decorating a variable with the `WorkgroupId` built-in decoration will make that variable contain the global workgroup that the current invocation is a member of. Each component ranges from a base value to a base + count value, based on the parameters passed into the dispatching commands.

Valid Usage

- VUID-WorkgroupId-WorkgroupId-04422
  The `WorkgroupId` decoration must be used only within the `GLCompute`, `MeshEXT`, `TaskEXT`, `MeshNV`, or `TaskNV` `Execution` `Model`

- VUID-WorkgroupId-WorkgroupId-04423
  The variable decorated with `WorkgroupId` must be declared using the `Input` `Storage` `Class`

- VUID-WorkgroupId-WorkgroupId-04424
  The variable decorated with `WorkgroupId` must be declared as a three-component vector of 32-bit integer values

`WorkgroupSize`

Note | SPIR-V 1.6 deprecated `WorkgroupSize` in favor of using the `LocalSizeId` Execution Mode instead. Support for `LocalSizeId` was added with `VK_KHR_maintenance4` and promoted to core in Version 1.3.

Decorating an object with the `WorkgroupSize` built-in decoration will make that object contain the dimensions of a local workgroup. If an object is decorated with the `WorkgroupSize` decoration, this takes precedence over any `LocalSize` or `LocalSizeId` execution mode.

Valid Usage

- VUID-WorkgroupSize-WorkgroupSize-04425
  The `WorkgroupSize` decoration must be used only within the `GLCompute`, `MeshEXT`, `TaskEXT`, `MeshNV`, or `TaskNV` `Execution` `Model`

- VUID-WorkgroupSize-WorkgroupSize-04426
  The variable decorated with `WorkgroupSize` must be a specialization constant or a constant

- VUID-WorkgroupSize-WorkgroupSize-04427
  The variable decorated with `WorkgroupSize` must be declared as a three-component vector of 32-bit integer values

`WorldRayDirectionKHR`

  A variable decorated with the `WorldRayDirectionKHR` decoration will specify the direction of the ray being processed, in world space. The value is the parameter passed into the pipeline trace ray instruction.

Valid Usage

- VUID-WorldRayDirectionKHR-WorldRayDirectionKHR-04428
  The `WorldRayDirectionKHR` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, `ClosestHitKHR`, or `MissKHR` `Execution` `Model`

- VUID-WorldRayDirectionKHR-WorldRayDirectionKHR-04429
  The variable decorated with `WorldRayDirectionKHR` must be declared using the `Input` `Storage` `Class`

- VUID-WorldRayDirectionKHR-WorldRayDirectionKHR-04430
  The variable decorated with `WorldRayDirectionKHR` must be declared as a three-component vector of 32-bit floating-point values

`WorldRayOriginKHR`

  A variable decorated with the `WorldRayOriginKHR` decoration will specify the origin of the ray being processed, in world space. The value is the parameter passed into the pipeline trace ray instruction.

Valid Usage

- VUID-WorldRayOriginKHR-WorldRayOriginKHR-04431
  The `WorldRayOriginKHR` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, `ClosestHitKHR`, or `MissKHR` `Execution` `Model`

- VUID-WorldRayOriginKHR-WorldRayOriginKHR-04432
  The variable decorated with `WorldRayOriginKHR` must be declared using the `Input` `Storage` `Class`

- VUID-WorldRayOriginKHR-WorldRayOriginKHR-04433
  The variable decorated with `WorldRayOriginKHR` must be declared as a three-component vector of 32-bit floating-point values

`WorldToObjectKHR`

  A variable decorated with the `WorldToObjectKHR` decoration will contain the current world-to-object transformation matrix, which is determined by the instance of the current intersection.

Valid Usage

- VUID-WorldToObjectKHR-WorldToObjectKHR-04434
  The `WorldToObjectKHR` decoration must be used only within the `IntersectionKHR`, `AnyHitKHR`, or `ClosestHitKHR` `Execution` `Model`

- VUID-WorldToObjectKHR-WorldToObjectKHR-04435
  The variable decorated with `WorldToObjectKHR` must be declared using the `Input` `Storage` `Class`

- VUID-WorldToObjectKHR-WorldToObjectKHR-04436
  The variable decorated with `WorldToObjectKHR` must be declared as a matrix with four columns of three-component vectors of 32-bit floating-point values

`CoreCountARM`

  Decorating a variable with the `CoreCountARM` built-in decoration will make that variable contain the number of cores on the device.

Valid Usage

- VUID-CoreCountARM-CoreCountARM-07595
  The variable decorated with `CoreCountARM` must be declared using the `Input` `Storage` `Class`

- VUID-CoreCountARM-CoreCountARM-07596
  The variable decorated with `CoreCountARM` must be declared as a scalar 32-bit integer value

`CoreMaxIDARM`

  Decorating a variable with the `CoreMaxIDARM` built-in decoration will make that variable contain the max ID of any shader core on the device on which the current shader invocation is running.

Valid Usage

- VUID-CoreMaxIDARM-CoreMaxIDARM-07597
  The variable decorated with `CoreMaxIDARM` must be declared using the `Input` `Storage` `Class`

- VUID-CoreMaxIDARM-CoreMaxIDARM-07598
  The variable decorated with `CoreMaxIDARM` must be declared as a scalar 32-bit integer value

`CoreIDARM`

  Decorating a variable with the `CoreIDARM` built-in decoration will make that variable contain the ID of the core on which the current shader invocation is running. This variable is in the range [0, `CoreMaxIDARM`].

Valid Usage

- VUID-CoreIDARM-CoreIDARM-07599
  The variable decorated with `CoreIDARM` must be declared using the `Input` `Storage` `Class`

- VUID-CoreIDARM-CoreIDARM-07600
  The variable decorated with `CoreIDARM` must be declared as a scalar 32-bit integer value

`WarpMaxIDARM`

  Decorating a variable with the `WarpMaxIDARM` built-in decoration will make that variable contain the maximum warp ID for the core on which the current invocation is running.

Valid Usage

- VUID-WarpMaxIDARM-WarpMaxIDARM-07601
  The variable decorated with `WarpMaxIDARM` must be declared using the `Input` `Storage` `Class`

- VUID-WarpMaxIDARM-WarpMaxIDARM-07602
  The variable decorated with `WarpMaxIDARM` must be declared as a scalar 32-bit integer value

`WarpIDARM`

  Decorating a variable with the `WarpIDARM` built-in decoration will make that variable contain the ID of the warp on a core on which the current shader invocation is running. This variable is in the range [0, `WarpMaxIDARM`].

Valid Usage

- VUID-WarpIDARM-WarpIDARM-07603
  The variable decorated with `WarpIDARM` must be declared using the `Input` `Storage` `Class`

- VUID-WarpIDARM-WarpIDARM-07604
  The variable decorated with `WarpIDARM` must be declared as a scalar 32-bit integer value

`CoalescedInputCountAMDX`

  Decorating a variable with the `CoalescedInputCountAMDX` built-in decoration will make that variable contain the number of node dispatches that the implementation coalesced into the input for the current shader. This variable will take a value in the range [1, arraySize), where arraySize is the maximum size of the input payload array for the shader.

Valid Usage

- VUID-CoalescedInputCountAMDX-CoalescedInputCountAMDX-09172
  The variable decorated with `CoalescedInputCountAMDX` must be declared using the `Input` `Storage` `Class`

- VUID-CoalescedInputCountAMDX-CoalescedInputCountAMDX-09173
  If a variable is decorated with `CoalescedInputCountAMDX`, the `CoalescingAMDX` execution mode must be declared

- VUID-CoalescedInputCountAMDX-CoalescedInputCountAMDX-09174
  The variable decorated with `CoalescedInputCountAMDX` must be declared as a scalar 32-bit integer value

`ShaderIndexAMDX`

  Decorating a variable with the `ShaderIndexAMDX` built-in decoration will make that variable contain the index of the shader specified when it was compiled, either via VkPipelineShaderStageNodeCreateInfoAMDX::`index` or by the `ShaderIndexAMDX` execution mode.

Valid Usage

- VUID-ShaderIndexAMDX-ShaderIndexAMDX-09175
  The variable decorated with `ShaderIndexAMDX` must be declared using the `Input` `Storage` `Class`

- VUID-ShaderIndexAMDX-ShaderIndexAMDX-09176
  The variable decorated with `ShaderIndexAMDX` must be declared as a scalar 32-bit integer value