SPIR-V

SPIR-V (Standard Portable Intermediate Representation) is a binary intermediate language defined by the Khronos Group for representing GPU shaders and compute kernels. Rather than being written by hand, SPIR-V is the compiled form that high-level shading languages target: a compact, portable binary module that graphics drivers consume directly. Introduced in 2015, it sits at the center of the modern GPU programming stack, acting as the common currency between languages like GLSL and HLSL and APIs like Vulkan, OpenCL, and OpenGL.

History & Origins

SPIR-V is the successor to the original SPIR, which Khronos introduced in 2012 as an intermediate representation for OpenCL. That first SPIR was built on top of LLVM Intermediate Representation, which tied it to the details of an external, independently evolving IR format — a coupling that proved awkward as LLVM’s IR changed over time.

When Khronos set out to design the shader model for its next-generation graphics API, it took a different approach. A provisional SPIR-V specification was revealed at the Game Developers Conference in March 2015, and SPIR-V 1.0 was formally released on November 16, 2015, alongside OpenCL 2.1. The specification was edited by John Kessenich (Google), long associated with the GLSL reference compiler, and Boaz Ouriel (Intel).

The crucial design decision was that SPIR-V is not based on LLVM IR. It is a fully self-contained, Khronos-defined format with native constructs for both graphics and compute, giving it a stable, precisely specified representation that GPU vendors can implement without inheriting an external compiler’s internals.

Design Philosophy

SPIR-V’s purpose is to decouple shading languages from graphics drivers. Before it, an API like OpenGL required every driver to embed a full high-level language compiler (for GLSL) and parse shader source at runtime — a source of inconsistency, bugs, and slow load times across vendors. SPIR-V changes the contract:

• Compile ahead of time. Developers compile their shaders to SPIR-V using their own tooling, then ship the binary. Drivers only need to consume a well-defined, low-level format.
• Language independence. Because the driver no longer parses a specific source language, any front end that can emit SPIR-V works. This is why Vulkan can be programmed with GLSL, HLSL, or other languages interchangeably.
• Precise, verifiable structure. SPIR-V is expressed using a control-flow graph and static single assignment (SSA) form, and it is designed to be validated, so malformed or unsafe modules can be rejected before they reach hardware.

Key Features

• Binary word-stream format. A SPIR-V module is a sequence of 32-bit words: a fixed header followed by a stream of instructions, each identifying an operation (an Op... code) and its operands.
• Typed, SSA-based instructions. Every result is given a unique id and an explicit type. Types, constants, and variables are all declared through instructions rather than a separate syntax.
• Capabilities and extensions. A module declares the capabilities it relies on (for example, Shader for graphics or Kernel for compute), letting the same format scale from mobile GPUs to compute clusters while allowing consumers to reject features they do not support.
• Multiple execution models. SPIR-V represents vertex, fragment, compute, geometry, tessellation, and (via extensions) ray-tracing and mesh shader stages, as well as OpenCL kernels.
• A human-readable disassembly. While SPIR-V is fundamentally binary, its tooling can print an assembly-like textual form for inspection and debugging.

A short excerpt of that disassembled textual form for a trivial fragment shader looks like this:

; SPIR-V
; Version: 1.0
               OpCapability Shader
          %1 = OpExtInstImport "GLSL.std.450"
               OpMemoryModel Logical GLSL450
               OpEntryPoint Fragment %main "main" %color
               OpExecutionMode %main OriginUpperLeft
       %void = OpTypeVoid
          %3 = OpTypeFunction %void
      %float = OpTypeFloat 32
    %v4float = OpTypeVector %float 4
%_ptr_Output = OpTypePointer Output %v4float
      %color = OpVariable %_ptr_Output Output

In practice, developers rarely read or write this directly; it is produced and consumed by compilers and tools.

Tooling

A substantial open-source ecosystem surrounds SPIR-V, much of it maintained by Khronos:

• glslang — the reference GLSL/HLSL front end, whose glslangValidator compiles source shaders to SPIR-V.
• SPIRV-Tools — a suite for assembling, disassembling, validating, and optimizing SPIR-V modules.
• SPIRV-Cross — translates SPIR-V back into GLSL, HLSL, and Metal Shading Language, so engines can target platforms that do not natively consume SPIR-V.
• SPIRV-LLVM-Translator — provides bidirectional translation between SPIR-V and LLVM IR, connecting SPIR-V to LLVM-based compiler pipelines.

Evolution

Since SPIR-V 1.0 in 2015, the specification has advanced in step with the APIs that consume it:

Each Vulkan release maps to a maximum supported SPIR-V version, and features that begin life as extensions are periodically promoted into the core specification. As of 2026, 1.6 remains the latest major version.

Current Relevance

SPIR-V is a foundational, if largely invisible, part of contemporary GPU programming. Every Vulkan application in existence ships its shaders as SPIR-V, and the format is used across the OpenCL compute ecosystem and by OpenGL 4.6. Open-source graphics stacks such as Mesa 3D consume it, and newer frameworks — including the Rust WebGPU implementation wgpu with its naga translation library, and the rust-gpu project that compiles Rust to shaders — build on it.

The most significant recent development came in September 2024, when Microsoft announced that Direct3D would adopt SPIR-V as its shader interchange format, replacing the proprietary DXIL, starting with Shader Model 7. Microsoft committed to building SPIR-V↔DXIL translation tools and to working with Khronos and the LLVM project — a notable convergence that would make SPIR-V the common shader representation across the two dominant desktop graphics APIs.

Why It Matters

SPIR-V solved a long-standing problem in graphics programming: the tight, fragile coupling between shading languages and the drivers that had to compile them at runtime. By defining a stable, portable, validated binary format, it let developers choose their own source language and toolchain, moved compilation out of the driver, and gave GPU vendors a precise target to implement. In doing so it became the connective tissue between multiple Khronos APIs — and, with Direct3D’s planned adoption, potentially the industry-wide standard for how compiled shaders are delivered to the GPU.