SPIR Overview


The Industry Open Standard Intermediate Language for Parallel Compute and Graphics

SPIR-V 1.3 has been released on March 7th, 2018 to accompany the launch of Vulkan 1.1

SPIR-V 1.3 expands the capabilities of the Vulkan shader intermediate representation to support subgroup operations and enable enhanced compiler optimizations.

“We are excited to see the progress developers have made with the SPIR-V standardized IR. Developers are using the shader language of their choice and a variety of open source compilers to ship their games and applications. The Vulkan tools and ecosystem is evolving rapidly.” said David Neto, Shader compiler team lead at Google.

Learn more in the Vulkan 1.1 Press Release

The SPIR-V Open Source Ecosystem

SPIR–V 1.3 Resources

SPIR–V 1.2 Resources

SPIR–V 1.1 Resources

SPIR–V 1.0 Resources

SPIR 1.2/2.0 Resources

SPIR 2.0 is a mapping from the OpenCL C programming language into LLVM IR. This version of the SPIR is based on LLVM 3.2 and OpenCL C as defined in the OpenCL 2.0 specification. SPIR 2.0 supports all core features and KHR extensions for version 2.0 of OpenCL C

About SPIR and SPIR-V

SPIR (Standard Portable Intermediate Representation) was initially developed for use by OpenCL and SPIR versions 1.2 and 2.0 were based on LLVM. SPIR has now evolved into a cross-API intermediate language that is fully defined by Khronos with native support for shader and kernel features used by APIs such as Vulkan – called SPIR-V.

SPIR 1.2 SPIR 2.0 SPIR-V 1.X
LLVM Interaction Uses LLVM 3.2 Uses LLVM 3.4 100% Khronos defined
Round-trip lossless conversion
Compute Constructs Metadata/Intrinsics Metadata/Intrinsics Native
Graphics Constructs No No Native
Supported Language Feature Supported OpenCL C 1.2 OpenCL C 1.2 OpenCL C 2.0 OpenCL C 1.2 / 2.X
OpenCL C++
OpenCL Ingestion OpenCL 1.2 Extension OpenCL 2.0 Extension OpenCL 2.1/2.2 Core
Graphics API Ingestion -- -- Vulkan 1.X and OpenGL 4.6 Core

SPIR-V is the first open standard, cross-API intermediate language for natively representing parallel compute and graphics and is part of the core specifications of OpenCL 2.1, OpenCL 2.2, and the Vulkan GPU API. SPIR-V is also supported in an OpenGL 4.6 extension. SPIR–V does not use LLVM, and so is isolated from LLVM roadmap changes. Khronos has open sourced SPIR-V/LLVM conversion tools to enable construction of flexible toolchains that use both intermediate languages.

SPIR-V exposes the machine model for OpenCL 1.2, 2.0, 2.1, 2.2 and Vulkan - including full flow control, and graphics and parallel constructs not supported in LLVM. SPIR-V also supports OpenCL C and OpenCL C++ kernel languages as well as the GLSL shader language for Vulkan and OpenGL.

SPIR-V 1.1, launched in parallel with OpenCL 2.1, supported the kernel language features of OpenCL C++ in OpenCL 2.1, including initializer and finalizer function execution modes to support constructors and destructors. SPIR-V 1.1 also enhances the expressiveness of kernel programs by supporting named barriers, subgroup execution, and program scope pipes.

SPIR-V 1.2 launched in parallel with OpenCL 2.2 and fully supports the final OpenCL C++ kernel language and adds support for runtime specialization of key tuning parameters in OpenCL 2.2 such as workgroup size.

SPIR-V 1.3, launched in parallel with Vulkan 1.1, expands the capabilities of the Vulkan shader intermediate representation to support subgroup operations and enables enhanced compiler optimizations.

SPIR-V is catalyzing a revolution in the language compiler ecosystem - it can split the compiler chain across multiple vendors’ products, enabling high-level language front-ends to emit programs in a standardized intermediate form to be ingested by Vulkan, OpenGL or OpenCL drivers.   For hardware vendors, ingesting SPIR-V eliminate the need to build a high-level language source compiler into device drivers, significantly reducing driver complexity, and will enable a broad range of language and framework front-ends to run on diverse hardware architectures.

For developers, using SPIR-V means that kernel source code no longer has to be directly exposed, kernel load times can be accelerated, and developers can choose the use of a common language front-end compiler, improving kernel reliability and portability across multiple hardware implementations.