A Khronos Group által fejlesztett SPIR-V, a korábban már specifikált SPIR (Standard Portable Intermediate Representation) modernizált verziója. A koncepció az új szabvány esetében pontosan ugyanaz volt, vagyis egy olyan közbülső fordítási egység létrehozása, ami reprezentálja a programot a forráskód és a lefordított bináris között. Ez azért fontos, mert lefordított állapotban vagy a magas szintű forrással szállítani egy alkalmazást több különböző és folyamatosan fejlődő utasításarchitektúrára nem ideális.
Mivel eredeti SPIR elsődlegesen az OpenCL-hez készült, és az LLVM-re (Low Level Virtual Machine) alapozott, nem volt megfelelő az időközben bejelentett Vulkan API-hoz. A konzorcium viszont az új grafikus API esetében is szeretett volna egy egységes reprezentációs szintet, hiszen számos gyártó hardverét ki kell szolgálni, ami a fejlesztők számára csak megfelelő szabványosítás mellett lehetséges. Emellett ha már változásra adták a fejüket, akkor az előddel kapcsolatos, bár nem túl jelentős, de azért meglévő problémákat is korrigálták. Ezek három kategóriába sorolhatók:
1. Az LLVM-től való függés megszüntetése
Az újragondolt, immáron SPIR-V nevű reprezentációs felület alapvető előnye a korábbi SPIR verziókhoz képest, hogy nem az LLVM-re épít. Bár az LLVM gyakorlatilag a teljes iparág szerint egy rendkívül hasznos fordítóprogram-infrastruktúra, de nem szabványosított, és az egyes verziók nem kompatibilisek egymással, valamint nem minden gyártó szeretne LLVM-et használni a meghajtókhoz. A problémák a SPIR 1.2-re és 2.0-ra is vonatkoznak, mivel előbbi az LLVM 3.2-re, míg utóbbi az LLVM 3.4-re épít. Ennek következtében a SPIR 1.2 és 2.0 támogatásához szükséges lett volna az LLVM 3.2 és 3.4 beépítésére a meghajtókba, és ez így lett volna minden új SPIR verzióval, mivel az LLVM fejlesztésekor a kompatibilitásra koncepciós okok miatt nem figyel oda a közösség.
A SPIR-V alapja tehát már nem az LLVM-re épít, hanem egy Khronos Group által kidolgozott és szabványosított interakciós felületre, amely később nyílt forráskódú lesz. Utóbbinak hála egy olyan egységes reprezentáció jött létre, amely natívan támogatja a compute és a grafikai konstrukciókat. Például a SPIR 1.2 és 2.0 utóbbira nem volt képes, előbbi esetben pedig nem volt natív a hozzáférés.
2. Más platformokkal való kompatibilitás lehetősége
A SPIR-V hatalmas előnye a SPIR-hez képest, hogy teljes egészében a Khronos Group fejlesztése, vagyis nem függ semmilyen külsőleg fejlesztett koncepciótól, így például az LLVM IR mellett támogatja a HSAIL-t is. Az LLVM-től való függőség ugyan megszűnt, de ez nem jelenti az LLVM IR megvetését, amely mostantól kiegészítő szerephez jut, mivel a közösség később kapni fog egy SPIR-V <-> LLVM konverziós eszközt. A HSAIL egy másik fontos út, mivel a széleskörű iparági támogatás következtében eleve hatalmas figyelmet kap a fejlesztőktől, így alapvető szempont volt, hogy a SPIR-V bájtkódból fordítható legyen HSAIL kód.
A SPIR-V akármilyen virtuális utasításarchitektúrát képes támogatni, így a jövőben az LLVM IR és a HSAIL mellé több opció is felkerülhet. Ehhez csupán az kell, hogy az adott virtuális utasításarchitektúrát az adott cég publikusan specifikálja, illetve tegye ingyenesen hozzáférhetővé mindenki számára, és a Khronos Group gyári támogatást épít majd ki rá a SPIR-V-n keresztül.
3. A nyelvekhez való kötöttség megszüntetése
A SPIR-V utolsó, de egyben rendkívüli előnye, hogy nincs hozzákötve egyetlen nyelvhez sem. A GLSL, az OpenCL C és OpenCL C++ támogatásáról a Khronos Group gondoskodik, ahogy a később érkező nyelveikről is, de a hosszabb távú cél, hogy a piac meglássa a lehetőségeket, és más nyelvekből is lehessen SPIR-V bájtkódot fordítani. Akár lehet saját nyelvet is fejleszteni, és abból is fordítható SPIR-V bájtkód. A lehetőségek igazából határtalanok, és ez egy rendkívül jó alapot ad a jövőben érkező fejlesztésekhez.
A SPIR-V mellett a SPIR ugyan nem tűnik el, de a Khronos Group a modernizált verziót favorizálja, és a jövőben az ipar is így fog tenni. A SPIR-V teljes kihasználásához a Vulkan és az OpenCL 2.1-es API támogatása szükséges.
