SPIR-Vはコンパイラを二分割することでGPUのポータビリティを実現した

GPU APIにはポータビリティの中に隠れたコンパイラ問題があった。すべてのドライバが高水準ソースを解析しなければならないとすれば、ドライバの複雑さが増し、各言語が各ランタイムへの経路を必要とした。そのため新しいフロントエンドの正当化は難しくなった。

Khronosの2015年の動きは、中間部分を標準化することだった。SPIR-V 1.0は、グラフィカルシェーダーとコンピュートカーネル向けのコンパクトなバイナリ中間言語を定義した。OpenCL 2.1はその消費を保証し、Vulkanはそれをシェーダー入力として採用した。

巧妙な点は分割にあった。フロントエンドがSPIR-Vを生成し、ドライバがSPIR-Vを消費する。Khronosはこれにより、組み込みの高水準コンパイラの複雑さが軽減され、言語の多様性が促され、ポータビリティが向上し、コンパイルとリフレクションの一部をオフラインで行えるようになったと述べた。

ドライバにソースではなくIRを消費させる

バイナリIRはKhronosによって完全に仕様化されていたため、ベンダーはソース言語を所有することなくバックエンドを最適化できた。

VulkanとOpenCLで同じIRを使うことで、ツール開発者にはグラフィックスとコンピュートのための単一のターゲットが与えられた。

オフラインコンパイルにより実行時のシェーダー処理が減り、検証、リフレクション、ツール作成が容易になった。

オープンソースのトランスレータ、アセンブラ、ディスアセンブラが、ローンチ時のエコシステムの立ち上げを助けた。

標準的な中間形式は、N対Mのコンパイラ問題を、多数のフロントエンドと多数の最適化されたバックエンドという二つのより小さな市場に変えることができる。

SPIR-VはVulkanとOpenCLのツールチェーンの中核部分となった。その統合仕様は現在、1.0以降のすべてのバージョンを対象としており、Khronosは複数のグラフィックスAPIとコンピュートAPIの下にあるポータブルなバイナリ層として、それを維持し続けている。