A Khronos Group március elején jelentette be a SPIR-V-t még a Vulkan API-val párhuzamosan, így az egységes reprezentációt biztosító fejlesztés érkezéséről mindenki tud, de annak születéséről már nem. A konzorcium az idei EuroLLVM rendezvényen több információt is elárult a SPIR-V megszületéséről, illetve a későbbi tervekről, amelyek szó se róla rendkívül biztatóak.
A Khronos Group az előadásában ecsetelte a SPIR alapvető célját, vagyis az egységes bájtkód biztosítását, annak érdekében, hogy a fejlesztők olyan formában is szállíthassák a programjaikat, amelyek biztosan futnak az adott SPIR verziót támogató hardvereken. A SPIR azonban elsődlegesen az OpenCL-hez készült, és az LLVM-re (Low Level Virtual Machine) alapozott, vagyis nem volt ideális a 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.
A Vulkan API-t fejlesztő csoport a SPIR-t és az LLVM-et is elvetette, így a John Kessenich által felvetett irányba fordultak, amely egy teljesen új reprezentációs felületre vonatkozott. Ez eredetileg csak a Vulkan API-hoz készült volna, de a Khronos Group felvetette, hogy nagyszerű lenne létrehozni egy olyan egységes reprezentációs szintet, amely egyszerre támogathatná a grafikus és a compute API-kat. Ezután az OpenCL fejlesztéséért felelős csoport is felszállt erre a vonatra, és ebből megszületett az OpenCL és a Vulkan API által is támogatott SPIR-V.
A SPIR-V legnagyobb előnye a korábbi SPIR verziókhoz képest, hogy nem az LLVM-re épít. Bár a Khronos Group szerint az LLVM 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óból nem figyel oda a közösség.
A SPIR-V a fentieken annyiban változtat, hogy maga az alap nem az LLVM-re épít. A Khronos Group célkitűzése egy olyan egységes reprezentáció volt, 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. A LLVM azonban továbbra is fontos szerepet tölt be a SPIR-V esetében ugyanis a Khronos Group definiált egy saját interakciós felületet, amelyet egyébként nyílt forráskódúvá is tesznek, így a közösség később kapni fog egy SPIR-V <-> LLVM konverziós eszközt.
A SPIR-V másik hatalmas előnye, 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, amely a konzorcium szerint a széleskörű iparági támogatás következtében 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 ráadásul más virtuális utasításarchitektúrákat is 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. Utóbbinak komoly előnye van, ugyanis a gyári támogatással a fejlesztők a SPIR-V kódból konvertálhatnak például direkt HSAIL kódot is, aminek nem kell áthaladnia az OpenCL futtatási környezeten, illetve az arra épített zárt gyártói implementációkon és fordítókon, vagyis a végfelhasználó kevesebb hibával rendelkező, stabilabban futó programokat kaphat.
A SPIR-V harmadik és egyben rendkívüli előnye, hogy igazából nincs hozzákötve egyetlen nyelvhez sem. A GLSL, az OpenCL C és OpenCL C++ támogatásáról a Khronos Group természetesen gondoskodik, ahogy a később érkező nyelveikről is, de a konzorcium szerint 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. Ez lehet az Apple MSL (Metal Shading Language), a Microsoft HLSL (High-Level Shading Language), a Sony PlayStation 4 PSSL (PlayStation Shading Language), illetve a GCC (GNU Compiler Collection) már be is jelentette, hogy a C-re és a C++-ra terveznek olyan fordítót, amely SPIR-V bájtkódot generál. 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 egyébként a 0.99-es verziónál jár éppen, és a tervek szerint a Vulkan és az OpenCL 2.1-es API megjelenésével párhuzamosan elérhető lesz.
