| SPIR-V | |
|---|---|
 | |
| Developer | Khronos Group |
| Initial release | 2015 |
| Stable release | SPIR-V 1.6 / December 16, 2021; 4 years ago (2021-12-16) |
| Operating system | Cross-platform |
| Platform | Cross-platform |
| Type | Intermediate language |
| Website | www |
Standard Portable Intermediate Representation (SPIR) is anintermediate language forparallel computing and graphics byKhronos Group. It is used in multiple execution environments, including theVulkangraphics API and theOpenCL compute API, to represent ashader orkernel. It is also used as an interchange language for cross compilation.[1][2]
SPIR-V is a new version of SPIR which was introduced in 2015 by theKhronos Group, and has since replaced the original SPIR, which was introduced in 2012.
On September 19th 2024, Microsoft has announced plans to adopt SPIR-V as theDirect3D Interchange format in place of DXIL, beginning support from Shader Model 7 on.[3]
The purposes of SPIR-V are to natively represent the primitives needed by compute and graphics; to separate high-level language from the interface to compute and graphics drivers; to be the distribution form, or distribute fully compiled binaries; to be a fully self-contained specification; and to support multiple APIs. It is also used as an intermediate target for cross-compilation tools.
For example, SPIR-V allows theVulkan API to use anyshading language, includingGLSL andHLSL.[4][5] SPIR-V can bedecompiled into several shading languages (GLSL,GLSL ES,MSL,HLSL) using SPIRV-Cross, so that these languages can be interconverted.[6] It also has paths to and/or fromWebGPU,OpenCL,SYCL,C++, andRust.
In target platforms, ingesting SPIR-V removes the need to build a high-level language source compiler into device drivers, which reduces driver complexity.[2]
SPIR was originally introduced in 2011 and SPIR-V was introduced in 2015.
| SPIR 1.2 | SPIR 2.0 | SPIR-V 1.X | |
|---|---|---|---|
| LLVM Interaction | LLVM IR version 3.2 | LLVM IR version 3.4 |
|
| Compute Constructs | Metadata/Intrinsics | Metadata/Intrinsics | Native |
| Graphics Constructs | No | No | Native |
| Supported Language & Feature Supported | OpenCL C 1.2 |
|
|
| OpenCL Ingestion | OpenCL 1.2 Extension | OpenCL 2.0 Extension | OpenCL 2.1/2.2 Core |
| Graphics API Ingestion | N/a | N/a |
|
SPIR prior to the 2015 SPIR-V release was based on theLLVM Intermediate Representation. A provisional specification for SPIR 1.0 was announced in 2012.[7] On July 22, 2013, a provisional specification SPIR 1.2 was announced atSIGGRAPH 2013.[8] The final SPIR 1.2 specification was released at HiPEAC 2014 on January 21, 2014.[9] On August 11, 2014, a provisional specification for SPIR 2.0 was released atSIGGRAPH 2014.[10] SPIR-V does not use LLVM.[2]
SPIR-V 1.0 is a new version of SPIR announced in March 2015,[11] and released on November 16, 2015.[12] The SPIR family now includes a true cross-API standard that is fully defined by Khronos with native support for shader and kernel features.
A separate program by the Khronos Group allows for interconversion with LLVM IR.[13]
Support for ingestion of SPIR-V is incorporated in the core specification of OpenCL 2.1, theVulkan API, andOpenGL version 4.6.
| Date | Version | Notes |
|---|---|---|
| April 18, 2016 | 1.1 | Released atIWOCL 2016 along with Provisional OpenCL 2.2. SPIR-V 1.1 added support for OpenCL C++, initializer/finalizer function execution modes, named barriers, subgroup execution, program scope pipes and pipe storage.[14] |
| May 16, 2017 | 1.2 | Released atIWOCL 2017 along with OpenCL 2.2. SPIR-V 1.2 added support for runtime specialization of key tuning parameters in OpenCL 2.2.[15] |
| March 7, 2018 | 1.3 | Released along withVulkan 1.1. SPIR-V 1.3 Added support for subgroup operations and enables enhanced compiler optimizations.[16] |
| May 7, 2019 | 1.4[1] | |
| September 13, 2020 | 1.5[1] | |
| December 16, 2021 | 1.6[1] |
SPIR-V is a high-level intermediate language, exchanged in binary form. Functions are represented by acontrol-flow graph of basic blocks, usingstatic single assignment (SSA) form. Data structures retain high-level hierarchical representation. It is not lossy like previous byte-code or virtual machine-like intermediate representations used for graphical shaders. This allows closer to optimum performance on the target devices.[17]
SPIR-V can be extended by writing extensions to add semantics, or reserving ranges of the token values for the party's use. Vendors can independently add desired semantics to SPIR-V.[18] Additional sets of extended instruction sets can be provided in separate specifications. Multiple sets can be imported without issue, as extended instructions are used by specifying the ID of the set and of the instruction within the set.[18]
Debuggers includeRenderDoc, SwiftShader, and Amber.[19]
Graphical shaders use structured control flow in SPIR-V to state how control flow nests. This helps in defining divergence and reconvergence of control flow on parallel execution environments.[20] Specialization reduces the number of variants of a shader that need to be distributed.[21]
The SPIR-V specification states the rules that must be followed to have a valid SPIR-V module. This allows for offline validation. Drivers are not obligated to handle invalid SPIR-V modules. In testing, conformance testing verifies that drivers behave correctly when consuming valid SPIR-V, while validators verify that front-ends properly generate SPIR-V.[22]
SPIR-V can express calls to functions in a different compilation unit. The standard version of SPIR-V uses this feature for OpenCL compute kernels, but not for shader stages, which the graphical APIs want fully linked into a single SPIR-V module.[23] There are extensions available to allow tools to temporarily use partially linked shaders and also kernels.[24]
A SPIR-V module is used by a client API to support that module's features, which are classified through capabilities, and declared early in the module. A validator can confirm that the module uses only its declared capabilities, and a client API can reject modules that declare unsupported capabilities.[25]
SPIR-V has been used to help deal with multiple versions of source-level languages. For example, the multiple versions of OpenGL Shading Language (GLSL) require distribution of multiple versions of shaders, due to implementations that are pegged to a specific older version of GLSL, such as forWebGL 1.0 and Apple's OpenGL implementation. One of the notable use cases of SPIR-V is its ability to be used as an interchange format between GLSL versions, using tools maintained by theKhronos Group for compiling GLSL to SPIR-VglslangValidator,[26] optimizing SPIR-Vspirv-opt,[22] and cross-compiling to SPIR-V to different GLSL targetsspirv-cross.[27]
As a format, however, SPIR-V has some limitations for cross-compilation, including the requirement that every SPIR-V module have at least one entry-point symbol. This prevents the format from being easily used for separate compilation, where complex shaders could be assembled by a series of partial compile steps followed by a linking step. This runs counter to the stated goals of some SPIR-V tools such asspirv-link,[22] which aims to provide full linking functionality for SPIR-V binary code.