GitNote

Table of Contents

Shader Features

permalink:/Notes/004-3d-rendering/vulkan/chapters/extensions/shader_features.html layout: default ---

Shader Features

There are various reasons why every part of SPIR-V was not exposed to Vulkan 1.0. Over time the Vulkan Working Group has identified use cases where it makes sense to expose a new SPIR-V feature.

Some of the following extensions were added alongside a SPIR-V extension. For example, the VK_KHR_8bit_storage extension was created in parallel with SPV_KHR_8bit_storage. The Vulkan extension only purpose is to allow an application to query for SPIR-V support in the implementation. The SPIR-V extension is there to define the changes made to the SPIR-V intermediate representation.

For details how to use SPIR-V extension please read the dedicated Vulkan Guide chapter.

1. VK_KHR_spirv_1_4

Note	Promoted to core in Vulkan 1.2

This extension is designed for a Vulkan 1.1 implementations to expose the SPIR-V 1.4 feature set. Vulkan 1.1 only requires SPIR-V 1.3 and some use cases were found where an implementation might not upgrade to Vulkan 1.2, but still want to offer SPIR-V 1.4 features.

2. VK_KHR_8bit_storage and VK_KHR_16bit_storage

Note	SPV_KHR_8bit_storage SPV_KHR_16bit_storage GLSL - GL_EXT_shader_16bit_storage defines both

Both VK_KHR_8bit_storage (promoted in Vulkan 1.2) and VK_KHR_16bit_storage (promoted in Vulkan 1.1) were added to allow the ability to use small values as input or output to a SPIR-V storage object. Prior to these extensions, all UBO, SSBO, and push constants needed to consume at least 4 bytes. With this, an application can now use 8-bit or 16-bit values directly from a buffer. It is also commonly paired with the use of VK_KHR_shader_float16_int8 as this extension only deals with the storage interfaces.

The following is an example of using SPV_KHR_8bit_storage with the GLSL extension:

#version 450

// Without 8-bit storage each block variable has to be 32-byte wide
layout (set = 0, binding = 0) readonly buffer StorageBuffer {
    uint data; // 0x0000AABB
} ssbo;

void main() {
    uint a = ssbo.data & 0x0000FF00;
    uint b = ssbo.data & 0x000000FF;
}

With the extension

#version 450
#extension GL_EXT_shader_8bit_storage : enable

layout (set = 0, binding = 0) readonly buffer StorageBuffer {
    uint8_t dataA; // 0xAA
    uint8_t dataB; // 0xBB
} ssbo;

void main() {
    uint a = uint(ssbo.dataA);
    uint b = uint(ssbo.dataB);
}

3. VK_KHR_shader_float16_int8

Note	Promoted to core in Vulkan 1.2 GLSL - GL_EXT_shader_explicit_arithmetic_types

This extension allows the use of 8-bit integer types or 16-bit floating-point types for arithmetic operations. This does not allow for 8-bit integer types or 16-bit floating-point types in any shader input and output interfaces and therefore is commonly paired with the use of VK_KHR_8bit_storage and VK_KHR_16bit_storage.

4. VK_KHR_shader_float_controls

Note	Promoted to core in Vulkan 1.2 SPV_KHR_float_controls

This extension allows the ability to set how rounding of floats are handled. The VkPhysicalDeviceFloatControlsProperties shows the full list of features that can be queried. This is useful when converting OpenCL kernels to Vulkan.

5. VK_KHR_storage_buffer_storage_class

Note	Promoted to core in Vulkan 1.1 SPV_KHR_storage_buffer_storage_class

Originally SPIR-V combined both UBO and SSBO into the 'Uniform' storage classes and differentiated them only through extra decorations. Because some hardware treats UBO an SSBO as two different storage objects, the SPIR-V wanted to reflect that. This extension serves the purpose of extending SPIR-V to have a new StorageBuffer class.

An example of this can be seen if you take the following GLSL shader snippet:

layout(set = 0, binding = 0) buffer ssbo {
    int x;
};

If you target Vulkan 1.0 (which requires SPIR-V 1.0), using glslang --target-env vulkan1.0, you will get something like:

    Decorate 7(ssbo) BufferBlock
8:  TypePointer Uniform 7(ssbo)
9:  8(ptr) Variable Uniform
12: TypePointer Uniform 6(int)

Since SPV_KHR_storage_buffer_storage_class was added to SPIR-V 1.3, if you target Vulkan 1.1 (which requires SPIR-V 1.3) ,using glslang --target-env vulkan1.1, it will make use of the new StorageBuffer class.

    Decorate 7(ssbo) Block
8:  TypePointer StorageBuffer 7(ssbo)
9:  8(ptr) Variable StorageBuffer
12: TypePointer StorageBuffer 6(int)

6. VK_KHR_variable_pointers

Note	Promoted to core in Vulkan 1.1 SPV_KHR_variable_pointers

A Variable pointer is defined in SPIR-V as

Note	A pointer of logical pointer type that results from one of the following instructions: `OpSelect`, `OpPhi`, `OpFunctionCall`, `OpPtrAccessChain`, `OpLoad`, or `OpConstantNull`

When this extension is enabled, invocation-private pointers can be dynamic and non-uniform. Without this extension a variable pointer must be selected from pointers pointing into the same structure or be OpConstantNull.

This extension has two levels to it. The first is the variablePointersStorageBuffer feature bit which allows implementations to support the use of variable pointers into a SSBO only. The variablePointers feature bit allows the use of variable pointers outside the SSBO as well.

7. VK_KHR_vulkan_memory_model

Note	Promoted to core in Vulkan 1.2 Comparing the Vulkan SPIR-V memory model to C’s

The Vulkan Memory Model formally defines how to synchronize memory accesses to the same memory locations performed by multiple shader invocations and this extension exposes a boolean to let implementations to indicate support for it. This is important because with many things targeting Vulkan/SPIR-V it is important that any memory transfer operations an application might attempt to optimize doesn’t break across implementations.

8. VK_EXT_shader_viewport_index_layer

Note	Promoted to core in Vulkan 1.2 SPV_EXT_shader_viewport_index_layer GLSL - GL_ARB_shader_viewport_layer_array

This extension adds the ViewportIndex, Layer built-in for exporting from vertex or tessellation shaders.

In GLSL these are represented by gl_ViewportIndex and gl_Layer built-ins.

9. VK_KHR_shader_draw_parameters

Note	Promoted to core in Vulkan 1.1 SPV_KHR_shader_draw_parameters GLSL - GL_ARB_shader_draw_parameters

This extension adds the BaseInstance, BaseVertex, and DrawIndex built-in for vertex shaders. This was added as there are legitimate use cases for both inclusion and exclusion of the BaseVertex or BaseInstance parameters in VertexId and InstanceId, respectively.

In GLSL these are represented by gl_BaseInstanceARB, gl_BaseVertexARB and gl_BaseInstanceARB built-ins.

10. VK_EXT_shader_stencil_export

Note	SPV_EXT_shader_stencil_export GLSL - GL_ARB_shader_stencil_export

This extension allows a shader to generate the stencil reference value per invocation. When stencil testing is enabled, this allows the test to be performed against the value generated in the shader.

In GLSL this is represented by a out int gl_FragStencilRefARB built-in.

11. VK_EXT_shader_demote_to_helper_invocation

Note	Promoted to core in Vulkan 1.3 SPV_EXT_demote_to_helper_invocation GLSL - GL_EXT_demote_to_helper_invocation

This extension was created to help with matching the HLSL discard instruction in SPIR-V by adding a demote keyword. When using demote in a fragment shader invocation it becomes a helper invocation. Any stores to memory after this instruction are suppressed and the fragment does not write outputs to the framebuffer.

12. VK_KHR_shader_clock

Note	SPV_KHR_shader_clock GLSL - GL_EXT_shader_realtime_clock

This extension allows the shader to read the value of a monotonically incrementing counter provided by the implementation. This can be used as one possible method for debugging by tracking the order of when an invocation executes the instruction. It is worth noting that the addition of the OpReadClockKHR alters the shader one might want to debug. This means there is a certain level of accuracy representing the order as if the instructions did not exists.

13. VK_KHR_shader_non_semantic_info

Note	Promoted to core in Vulkan 1.3 SPV_KHR_non_semantic_info

This extension exposes SPV_KHR_non_semantic_info which adds the ability to declare extended instruction sets that have no semantic impact and can be safely removed from a module.

14. VK_KHR_shader_terminate_invocation

Note	Promoted to core in Vulkan 1.3 SPV_KHR_terminate_invocation

This extension adds the new instruction OpTerminateInvocation to provide a disambiguated functionality compared to the OpKill instruction.

15. VK_KHR_workgroup_memory_explicit_layout

Note	SPV_KHR_workgroup_memory_explicit_layout GLSL - GL_EXT_shared_memory_block

This extension provides a way for the shader to define the layout of Workgroup Storage Class memory. Workgroup variables can be declared in blocks, and then use the same explicit layout decorations (e.g. Offset, ArrayStride) as other storage classes.

One use case is to do large vector copies (e.g. uvec4 at at a time) from buffer memory into shared memory, even if the shared memory is really a different type (e.g. scalar fp16).

Another use case is a developers could potentially use this to reuse shared memory and reduce the total shared memory consumption using something such as the following:

pass1 - write shmem using type A
barrier()
pass2 - read shmem using type A
barrier()
pass3 - write shmem using type B
barrier()
pass4 - read shmem using type B

The explicit layout support and some form of aliasing is also required for layering OpenCL on top of Vulkan.

16. VK_KHR_zero_initialize_workgroup_memory

Note	Promoted to core in Vulkan 1.3

This extension allows OpVariable with a Workgroup Storage Class to use the Initializer operand.

For security reasons, applications running untrusted content (e.g. web browsers) need to be able to zero-initialize workgroup memory at the start of workgroup execution. Adding instructions to set all workgroup variables to zero would be less efficient than what some hardware is capable of, due to poor access patterns.