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

Interface definitions make use of the following SPIR-V decorations:

• DescriptorSet and Binding

• Location, Component, and Index

• Flat, NoPerspective, Centroid, and Sample

• Block and BufferBlock

• InputAttachmentIndex

• Offset, ArrayStride, and MatrixStride

• BuiltIn

This specification describes valid uses for Vulkan of these decorations. Any other use of one of these decorations is invalid.

### 14.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.

#### 14.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.

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

#### 14.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 SPIR-V numerical types or, recursively, composite types of such types. By default, the components of such types have a width of 32 or 64 bits. If an implementation supports storageInputOutput16, components can also have a width of 16 bits. These variables must be identified with a Location decoration and can also be identified with a Component decoration.

#### 14.1.3. Interface Matching

Interface matching rules only apply to built-ins when they are declared as members of the built-in interface block.

Tessellation control shader per-vertex output variables and blocks, and tessellation control, tessellation evaluation, and geometry shader per-vertex input variables and blocks are required to be declared as arrays, with each element representing input or output values for a single vertex of a multi-vertex primitive. For the purposes of interface matching, the outermost array dimension of such variables and blocks is ignored.

A user-defined output variable is considered to match an input variable in the subsequent stage if the two variables are declared with the same Location and Component decoration and match in type and decoration, except that interpolation decorations are not required to match. For the purposes of interface matching, variables declared without a Component decoration are considered to have a Component decoration of zero.

Variables or block members declared as structures are considered to match in type if and only if the structure members match in type, decoration, number, and declaration order. Variables or block members declared as arrays are considered to match in type only if both declarations specify the same element type and size.

At an interface between two non-fragment shader stages, the built-in interface block must match exactly, as described above. At an interface involving the fragment shader inputs, the presence or absence of any built-in output does not affect the interface matching.

At an interface between two shader stages, the user-defined variable interface must match exactly, as described above.

Any input value to a shader stage is well-defined as long as the preceding stages writes to a matching output, as described above.

Additionally, scalar and vector inputs are well-defined if there is a corresponding output satisfying all of the following conditions:

• the input and output match exactly in decoration,

• the output is a vector with the same basic type and has at least as many components as the input, and

• the common component type of the input and output is 16-bit integer or floating-point, or 32-bit integer or floating-point (64-bit component types are excluded).

In this case, the components of the input will be taken from the first components of the output, and any extra components of the output will be ignored.

#### 14.1.4. Location Assignment

This section describes location assignments for user-defined variables and how many locations 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 locations the type consumes.

The Location value specifies an interface slot comprised of a 32-bit four-component vector conveyed between stages. The Component specifies components within these vector locations. 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 locations.

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

If the declared input or output is an n × m 16-, 32- or 64-bit matrix, it will be assigned multiple locations starting with the location specified. The number of locations 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 locations 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 locations 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, either explicitly or implicitly. Any two outputs listed as operands on the same OpEntryPoint must not be assigned the same location, either explicitly or implicitly.

The number of input and output locations available for a shader input or output interface are 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 locations available for the given interface, as specified in the "Locations Available" column in Shader Input and Output Locations.

Table 15. Shader Input and Output Locations

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

#### 14.1.5. Component Assignment

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

### 14.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 locations is given by the maxVertexInputAttributes member of the VkPhysicalDeviceLimits structure.

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

### 14.3. Fragment Output Interface

When the fragment stage is present in a pipeline, the fragment shader outputs form an interface with the output attachments of the current subpass. The fragment shader output variables are matched by the Location and Component decorations to the color attachments specified in the pColorAttachments array of the VkSubpassDescription structure describing the subpass that the fragment shader is executed in.

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 directed to the color attachment indicated by pColorAttachments[i], 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 locations is given by the maxFragmentOutputAttachments member of the VkPhysicalDeviceLimits structure.

Components of the output variables are assigned as described in Component Assignment. Output components 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). The input values to blending or color attachment writes are undefined for components which do not correspond to a fragment shader output.

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.

No component aliasing of output variables is allowed, that is there must not be two output variables which have the same location, component, and index, 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.

### 14.4. 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, and a Sampled operand of 2.

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. The number of available input attachment indices is given by the maxPerStageDescriptorInputAttachments member of the VkPhysicalDeviceLimits structure.

Variables identified with the InputAttachmentIndex must only be used by a fragment stage. The basic data type (floating-point, integer, unsigned integer) of the subpass input must match the basic format of the corresponding input attachment, or the values of subpass loads from these variables are undefined.

See Input Attachment for more details.

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 resources that form the shader resource interface for a stage are the variables statically used by OpEntryPoint with the storage class of Uniform, UniformConstant, 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.

#### 14.5.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.

#### 14.5.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 shaderStorageImageWriteWithoutFormat feature is enabled and the shader module declares the StorageImageWriteWithoutFormat capability.

• For OpImageRead or OpImageSparseRead, if the shaderStorageImageReadWithoutFormat feature is enabled 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 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.

Arrays of any of these types can be indexed with constant integral expressions. The following features must be enabled and capabilities must be declared in order to index such arrays with dynamically uniform or non-uniform indices:

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

• Dynamically uniform: shaderStorageImageArrayDynamicIndexing and StorageImageArrayDynamicIndexing

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

• Dynamically uniform: shaderSampledImageArrayDynamicIndexing and SampledImageArrayDynamicIndexing

• Uniform buffers:

• Dynamically uniform: shaderUniformBufferArrayDynamicIndexing and UniformBufferArrayDynamicIndexing

• Storage buffers:

• Dynamically uniform: shaderStorageBufferArrayDynamicIndexing and StorageBufferArrayDynamicIndexing

• Acceleration structures:

If an instruction loads from or stores to a resource (including atomics and image instructions) and the resource descriptor being accessed is not uniform, then the corresponding dynamic indexing feature must be enabled and the capability must be declared.

If the combined image sampler enables sampler Y′CBCR conversion, it must be indexed only by constant integral expressions when aggregated into arrays in shader code, irrespective of the shaderSampledImageArrayDynamicIndexing feature.

Table 16. 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

acceleration structure

VK_DESCRIPTOR_TYPE_ACCELERATION_STRUCTURE_KHR

Table 17. Shader Resource and Storage Class Correspondence
Resource type Storage Class Type Decoration(s)1

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

acceleration structure

UniformConstant

OpTypeAccelerationStructureKHR

1

in addition to DescriptorSet and Binding

#### 14.5.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. The array must not be runtime-sized. 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 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, some could be OpTypeSampler (Sampled=1), and some could be OpTypeSampledImage.
Resources per Stage Resource Types

maxPerStageDescriptorSamplers

sampler

combined image sampler

maxPerStageDescriptorSampledImages

sampled image

combined image sampler

uniform texel buffer

maxPerStageDescriptorStorageImages

storage image

storage texel buffer

maxPerStageDescriptorUniformBuffers

uniform buffer

uniform buffer dynamic

maxPerStageDescriptorStorageBuffers

storage buffer

storage buffer dynamic

maxPerStageDescriptorInputAttachments

input attachment1

maxDescriptorSetAccelerationStructures

acceleration structure

1

Input attachments can only be used in the fragment shader stage

#### 14.5.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 on the device.

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 or matrix 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.

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.

• A row-major matrix of C columns has a base alignment equal to the base alignment of a vector of C matrix components.

• A column-major matrix has a base alignment equal to the base alignment of the matrix column type.

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

• A scalar, vector or matrix 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 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. All vectors must be aligned according to their scalar alignment.

2. If the uniformBufferStandardLayout feature is not enabled on the device, 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.

3. Every other member must be aligned according to its 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.

• Vectors must not improperly straddle, as defined above.

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

 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.

### 14.6. 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.

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.

The BaseInstance decoration must be used only within vertex shaders.

The variable decorated with BaseInstance must be declared using the input storage class.

The variable decorated with BaseInstance must be declared as a scalar 32-bit integer.

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.

The BaseVertex decoration must be used only within vertex shaders.

The variable decorated with BaseVertex must be declared using the input storage class.

The variable decorated with BaseVertex must be declared as a scalar 32-bit integer.

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 point is outside the clip half-space.

The ClipDistance decoration must be used only within vertex, fragment, tessellation control, tessellation evaluation, and geometry shaders.

In vertex shaders, any variable decorated with ClipDistance must be declared using the Output storage class.

In fragment shaders, any variable decorated with ClipDistance must be declared using the Input storage class.

In tessellation control, tessellation evaluation, or geometry shaders, any variable decorated with ClipDistance must not be in a storage class other than Input or Output.

Any variable decorated with ClipDistance must be declared as an array of 32-bit floating-point values.

 Note The array variable decorated with ClipDistance is explicitly sized by the shader.
 Note In the last vertex processing 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.
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.

The CullDistance decoration must be used only within vertex, fragment, tessellation control, tessellation evaluation, and geometry shaders.

In vertex shaders, any variable decorated with CullDistance must be declared using the Output storage class.

In fragment shaders, any variable decorated with CullDistance must be declared using the Input storage class.

In tessellation control, tessellation evaluation, or geometry shaders, any variable decorated with CullDistance must not be declared in a storage class other than input or output.

Any variable decorated with CullDistance must be declared as an array of 32-bit floating-point values.

 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.
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 , where physicalDeviceCount is the physicalDeviceCount member of VkDeviceGroupDeviceCreateInfo.

The DeviceIndex decoration can be used in any shader.

The variable decorated with DeviceIndex must be declared using the Input storage class.

The variable decorated with DeviceIndex must be declared as a scalar 32-bit integer.

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 drawing command that invoked the current vertex shader invocation. For indirect drawing commands, DrawIndex begins at zero and increments by one for each draw command executed. The number of draw commands is given by the drawCount parameter. For direct drawing commands, DrawIndex is always zero. DrawIndex is dynamically uniform.

The DrawIndex decoration must be used only within vertex shaders.

The variable decorated with DrawIndex must be declared using the input storage class.

The variable decorated with DrawIndex must be declared as a scalar 32-bit integer.

FragCoord

Decorating a variable with the FragCoord built-in decoration will make that variable contain the framebuffer coordinate of the fragment being processed. The (x,y) coordinate (0,0) is the upper left corner of the upper left pixel in the framebuffer.

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 .

The FragCoord decoration must be used only within fragment shaders.

The variable decorated with FragCoord must be declared using the Input storage class.

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

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.

The FragDepth decoration must be used only within fragment shaders.

The variable decorated with FragDepth must be declared using the Output storage class.

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

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.

The FrontFacing decoration must be used only within fragment shaders.

The variable decorated with FrontFacing must be declared using the Input storage class.

The variable decorated with FrontFacing must be declared as a boolean.

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.

The GlobalInvocationId decoration must be used only within compute shaders.

The variable decorated with GlobalInvocationId must be declared using the Input storage class.

The variable decorated with GlobalInvocationId must be declared as a three-component vector of 32-bit integers.

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.

The HelperInvocation decoration must be used only within fragment shaders.

The variable decorated with HelperInvocation must be declared using the Input storage class.

The variable decorated with HelperInvocation must be declared as a boolean.

 Note It is very likely that a helper invocation will have a value of SampleMask fragment shader input value that is zero.
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.

The HitKindKHR decoration must only be used in any-hit and closest hit shaders.

Any variable decorated with HitKindKHR must be declared using the Input storage class.

Any variable decorated with HitKindKHR must be declared as a scalar 32-bit integer.

IncomingRayFlagsKHR

A variable with the IncomingRayFlagsKHR decoration will contain the ray flags passed in to the trace call that invoked this particular shader.

The IncomingRayFlagsKHR decoration must only be used in the intersection, any-hit, closest hit, and miss shaders.

Any variable decorated with IncomingRayFlagsKHR must be declared using the Input storage class.

Any variable decorated with IncomingRayFlagsKHR must be declared as a scalar 32-bit integer.

InstanceCustomIndexKHR

A variable decorated with the InstanceCustomIndexKHR decoration will contain the application-defined value of the instance that intersects the current ray. Only the lower 24 bits are valid, the upper 8 bits will be ignored.

The InstanceCustomIndexKHR decoration must only be used in the intersection, any-hit, and closest hit shaders.

Any variable decorated with InstanceCustomIndexKHR must be declared using the Input storage class.

Any variable decorated with InstanceCustomIndexKHR must be declared as a scalar 32-bit integer.

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.

The InstanceId decoration must be used only within intersection, any-hit, or closest hit shaders.

The variable decorated with InstanceId must be declared using the Input storage class.

The variable decorated with InstanceId must be declared as a scalar 32-bit integer.

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.

The InvocationId decoration must be used only within tessellation control and geometry shaders.

The variable decorated with InvocationId must be declared using the Input storage class.

The variable decorated with InvocationId must be declared as a scalar 32-bit integer.

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.

The InstanceIndex decoration must be used only within vertex shaders.

The variable decorated with InstanceIndex must be declared using the Input storage class.

The variable decorated with InstanceIndex must be declared as a scalar 32-bit integer.

LaunchIDKHR

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

The LaunchIDKHR decoration must only be used within the ray generation, intersection, any-hit, closest hit, and miss shaders.

Any variable decorated with LaunchIDKHR must be declared using the Input storage class.

Any 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 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.

The LaunchSizeKHR decoration must only be used within ray generation, intersection, any-hit, closest hit, and miss shaders.

Any variable decorated with LaunchSizeKHR must be declared using the Input storage class.

Any 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 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.

If the last active vertex processing stage shader entry point’s interface does not include a variable decorated with Layer, then the first layer is used. If a vertex processing 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.

The Layer decoration must be used only within geometry, and fragment shaders.

In a geometry shader, any variable decorated with Layer must be declared using the Output storage class.

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

In a fragment shader, any variable decorated with Layer must be declared using the Input storage class.

Any variable decorated with Layer must be declared as a scalar 32-bit integer.

LocalInvocationId

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

The LocalInvocationId decoration must be used only within compute shaders.

The variable decorated with LocalInvocationId must be declared using the Input storage class.

The variable decorated with LocalInvocationId must be declared as a three-component vector of 32-bit integers.

 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.
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;

The LocalInvocationIndex decoration must be used only within compute shaders.

The variable decorated with LocalInvocationIndex must be declared using the Input storage class.

The variable decorated with LocalInvocationIndex must be declared as a scalar 32-bit integer.

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 dispatch commands.

The NumWorkgroups decoration must be used only within compute shaders.

The variable decorated with NumWorkgroups must be declared using the Input storage class.

The variable decorated with NumWorkgroups must be declared as a three-component vector of 32-bit integers.

ObjectRayDirectionKHR

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

The ObjectRayDirectionKHR decoration must only be used within intersection, any-hit, and closest hit shaders.

Any variable decorated with ObjectRayDirectionKHR must be declared using the Input storage class.

Any 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.

The ObjectRayOriginKHR decoration must only be used within intersection, any-hit, and closest hit shaders.

Any variable decorated with ObjectRayOriginKHR must be declared using the Input storage class.

Any 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.

The ObjectToWorldKHR decoration must only be used within intersection, any-hit, and closest hit shaders.

Any variable decorated with ObjectToWorldKHR must be declared using the Input storage class.

Any 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. A single tessellation control or tessellation evaluation shader can read patches of differing sizes, so the value of the PatchVertices variable may differ between patches.

The PatchVertices decoration must be used only within tessellation control and tessellation evaluation shaders.

The variable decorated with PatchVertices must be declared using the Input storage class.

The variable decorated with PatchVertices must be declared as a scalar 32-bit integer.

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.

The PointCoord decoration must be used only within fragment shaders.

The variable decorated with PointCoord must be declared using the Input storage class.

The variable decorated with PointCoord must be declared as two-component vector of 32-bit floating-point values.

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

Decorating a variable with the PointSize built-in decoration will make that variable contain the size of point primitives. The value written to the variable decorated with PointSize by the last vertex processing stage in the pipeline is used as the framebuffer-space size of points produced by rasterization.

The PointSize decoration must be used only within vertex, tessellation control, tessellation evaluation, and geometry shaders.

In a vertex shader, any variable decorated with PointSize must be declared using the Output storage class.

In a tessellation control, tessellation evaluation, or geometry shader, any variable decorated with PointSize must be declared using either the Input or Output storage class.

Any variable decorated with PointSize must be declared as a scalar 32-bit floating-point value.

 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.
Position

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

The Position decoration must be used only within vertex, tessellation control, tessellation evaluation, and geometry shaders.

In a vertex shader, any variable decorated with Position must be declared using the Output storage class.

In a tessellation control, tessellation evaluation, or geometry shader, any variable decorated with Position must not be declared in a storage class other than Input or Output.

Any variable decorated with Position must be declared as a four-component vector of 32-bit floating-point values.

 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.
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 correspond 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 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.

If a geometry shader is present and the fragment shader reads from an input variable decorated with PrimitiveId, then the geometry shader must write to an output variable decorated with PrimitiveId in all execution paths.

The PrimitiveId decoration must be used only within intersection, any-hit, closest hit, fragment, tessellation control, tessellation evaluation, and geometry shaders.

In an intersection, any-hit, closest hit, a tessellation control, or tessellation evaluation shader, any variable decorated with PrimitiveId must be declared using the Input storage class.

In a geometry shader, any variable decorated with PrimitiveId must be declared using either the Input or Output storage class.

In a fragment shader, any variable decorated with PrimitiveId must be declared using the Input storage class, and either the Geometry or Tessellation capability must also be declared.

Any variable decorated with PrimitiveId must be declared as a scalar 32-bit integer.

 Note When the PrimitiveId decoration is applied to an output variable in the geometry shader, the resulting value is seen through the PrimitiveId decorated input variable in the fragment shader.
RayGeometryIndexKHR

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

The RayGeometryIndexKHR decoration must only be used within intersection, any-hit, and closest hit shaders.

Any variable decorated with RayGeometryIndexKHR must be declared using the Input storage class.

Any 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 values of the ray being processed. The values are independent of the space in which the ray and origin exist.

The tmax value changes throughout the lifetime of the ray query 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. 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 OpTraceRayKHR.

The RayTmaxKHR decoration must only be used with the intersection, any-hit, closest hit, and miss shaders.

Any variable decorated with RayTmaxKHR must be declared with the Input storage class.

Any 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 values of the ray being processed. The values are independent of the space in which the ray and origin exist.

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

The RayTminKHR decoration must only be used with the intersection, any-hit, closest hit, and miss shaders.

Any variable decorated with RayTminKHR must be declared with the Input storage class.

Any 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.

The SampleId decoration must be used only within fragment shaders.

The variable decorated with SampleId must be declared using the Input storage class.

The variable decorated with SampleId must be declared as a scalar 32-bit integer.

SampleMask

Decorating a variable with the SampleMask built-in decoration will make any variable contain the coverage 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.

When state specifies multiple fragment shader invocations for a given fragment, the sample mask for any single fragment shader invocation specifies the subset of the covered samples for the fragment that correspond to the invocation. In this case, the bit corresponding to each covered sample will be set in exactly one fragment shader invocation.

A variable in the Output storage class decorated with SampleMask is an array of integers forming a bit array in a manner similar an input variable decorated with SampleMask, but where each bit represents coverage as computed by the shader. Modifying the sample mask by writing zero to a bit of SampleMask causes the sample to be considered uncovered. However, setting sample mask bits to one will never enable samples not covered by the original primitive. If the fragment shader is being evaluated at any frequency other than per-fragment, bits of the sample mask not corresponding to the current fragment shader invocation are ignored. This array must be sized in the fragment shader either implicitly or explicitly, 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.

The SampleMask decoration must be used only within fragment shaders.

Any variable decorated with SampleMask must be declared using either the Input or Output storage class.

Any variable decorated with SampleMask must be declared as an array of 32-bit integers.

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 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.

+ The SamplePosition decoration must be used only within fragment shaders.

+ The variable decorated with SamplePosition must be declared using the Input storage class.

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

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.

The TessCoord decoration must be used only within tessellation evaluation shaders.

The variable decorated with TessCoord must be declared using the Input storage class.

The variable decorated with TessCoord must be declared as 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, which controls 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.

The TessLevelOuter decoration must be used only within tessellation control and tessellation evaluation shaders.

In a tessellation control shader, any variable decorated with TessLevelOuter must be declared using the Output storage class.

In a tessellation evaluation shader, any variable decorated with TessLevelOuter must be declared using the Input storage class.

Any 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, which controls 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.

The TessLevelInner decoration must be used only within tessellation control and tessellation evaluation shaders.

In a tessellation control shader, any variable decorated with TessLevelInner must be declared using the Output storage class.

In a tessellation evaluation shader, any variable decorated with TessLevelInner must be declared using the Input storage class.

Any variable decorated with TessLevelInner must be declared as an array of size two, containing 32-bit floating-point values.

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.

The VertexIndex decoration must be used only within vertex shaders.

The variable decorated with VertexIndex must be declared using the Input storage class.

The variable decorated with VertexIndex must be declared as a scalar 32-bit integer.

 Note VertexIndex starts at the same starting value for each instance.
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 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.

The ViewIndex decoration must not be used within compute shaders.

The variable decorated with ViewIndex must be declared using the Input storage class.

The variable decorated with ViewIndex must be declared as a scalar 32-bit integer.

ViewportIndex

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

In a 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 and scissor rectangle.

If the last active vertex processing stage shader entry point’s interface does not include a variable decorated with ViewportIndex, then the first viewport is used. If a vertex processing 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.

The ViewportIndex decoration must be used only within geometry, and fragment shaders.

In a geometry shader, any variable decorated with ViewportIndex must be declared using the Output storage class.

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

In a fragment shader, any variable decorated with ViewportIndex must be declared using the Input storage class.

Any variable decorated with ViewportIndex must be declared as a scalar 32-bit integer.

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 dispatch commands.

The WorkgroupId decoration must be used only within compute shaders.

The variable decorated with WorkgroupId must be declared using the Input storage class.

The variable decorated with WorkgroupId must be declared as a three-component vector of 32-bit integers.

WorkgroupSize

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 must take precedence over any execution mode set for LocalSize.

The WorkgroupSize decoration must be used only within compute shaders.

The object decorated with WorkgroupSize must be a specialization constant or a constant.

The object decorated with WorkgroupSize must be declared as a three-component vector of 32-bit integers.

WorldRayDirectionKHR

A variable decorated with the WorldRayDirectionKHR decoration will specify the direction of the ray being processed, in world space.

The WorldRayDirectionKHR decoration must only be used within intersection, any-hit, closest hit, and miss shaders.

Any variable decorated with WorldRayDirectionKHR must be declared using the Input storage class.

Any 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 WorldRayOriginKHR decoration must only be used within intersection, any-hit, closest hit, and miss shaders.

Any variable decorated with WorldRayOriginKHR must be declared using the Input storage class.

Any 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.

The WorldToObjectKHR decoration must only be used within intersection, any-hit, and closest hit shaders.

Any variable decorated with WorldToObjectKHR must be declared using the Input storage class.

Any variable decorated with WorldToObjectKHR must be declared as a matrix with four columns of three-component vectors of 32-bit floating-point values.