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 之下的可攜二進位層。