SPIR-V won GPU portability by splitting the compiler in two

GPU APIs had a compiler problem hiding inside portability. If every driver had to parse high-level source, driver complexity rose and each language needed a path into each runtime. That made new front ends hard to justify.

Khronos's 2015 move was to standardize the middle. SPIR-V 1.0 defined a compact binary intermediate language for graphical shaders and compute kernels. OpenCL 2.1 guaranteed consumption of it, and Vulkan adopted it as its shader input.

The clever part was the split: front ends produce SPIR-V, drivers consume SPIR-V. Khronos said this reduced built-in high-level compiler complexity, encouraged language diversity, improved portability and allowed parts of compilation and reflection to happen offline.

Make the driver consume IR, not source

The binary IR was fully specified by Khronos, so vendors could optimize back ends without owning the source language.

Using the same IR across Vulkan and OpenCL gave tool builders one target for graphics and compute.

Offline compilation reduced runtime shader work and made validation, reflection and tooling easier.

Open-source translators, assemblers and disassemblers helped seed the ecosystem at launch.

A standard intermediate form can turn an N-by-M compiler problem into two smaller markets: many front ends and many optimized back ends.

SPIR-V became a core part of the Vulkan and OpenCL toolchains. Its unified specification now covers all versions since 1.0, and Khronos continues to maintain it as the portable binary layer beneath multiple graphics and compute APIs.