A Khronos Group márciusban bejelentett Vulkan API-jának fejlesztése gyakorlatilag véget ért, de az utolsó simítások miatt még várat magára a tényleges megjelenés. Ettől függetlenül az API-ról már sok dolog kiderült a SIGGRAPH Asia 2015-ön, de a legújabb adatok szerint a kiterjesztésekre vonatkozó koncepciójával már most kapott egy enyhe léket.
Az NVIDIA nemrég bejelentette, hogy már a startra készítenek egy olyan kiterjesztést, amellyel a fejlesztők direkten szállíthatják az alkalmazásban a GLSL shadereiket a Vulkan API-hoz is. Ezt az OpenGL meghajtóban dolgozó Cg fordító lefordítja SPIR-V-re és ez a kód fog eljutni a grafikus vezérlőhöz a további fordítás során. A bejelentés hatására rögtön elkezdett szólni a vészharang, hogy ezt egyáltalán meg lehet-e tenni a Vulkan API-ban. Kiderült azonban, hogy a specifikáció csak a SPIR-V kódot követeli meg, de a kódgenerálás formáját már a fejlesztőkre bízza.
Ezzel kapcsolatban érdeklődtünk a konzorciumnál, hogy a generálásra akkor milyen lehetőségek is vannak. Megtudtuk, hogy a Vulkan SDK alapból tartalmaz egy olyan nyílt forráskódú fordítót, amely a szabványos GLSL kódokat SPIR-V-re fordítja, de a fejlesztők akár saját fordítót is írhatnak, amely persze más shader nyelvről is biztosíthatja a szükséges kódot. Ez eddig gyakorlatilag ismert volt, de érdekes fejlemény, hogy az API ugyan állandóan megköveteli a SPIR-V kódot, viszont arra is megadja az engedélyt, hogy egy specifikus kiterjesztéssel ez a kód valós időben legyen fordítható, vagyis akár a magas szintű shader nyelv is szállítható az adott alkalmazással.
Ez egyértelműen léket jelent a rendszerben, amire Matías N. Goldberg, az Ogre3D motorprogramozója szinte azonnal felhívta a figyelmet. Valószínűleg a Khronos Group úgy ítélte meg, hogy a kötelező SPIR-V kód miatt mindenki ilyen formában szállítja az alkalmazásába a szükséges shader programokat, és a gyártók számára is ez a legjobb opció, hiszen így a fejlesztőknek elég egyszer megírni a shadert és azt például az Vulkan SDK-ban szereplő fordítóval le lehet fordítani. Miért is választana bárki olyan irányt, amely rontja a portolhatóságot az egyes gyártók hardverei között?
A fejlesztők szempontjából a helyzet érthető, mivel a Vulkan API számukra egy tiszta lapot jelent. Elhagyva az OpenGL töredezettségét, minden problémáját, ezzel elölről kezdve mindent, amely feltehetően egy olyan rendszerhez vezet, ahol tényleg minden gyártón futni fog a szabványos kód. Emiatt nem csoda, hogy nem fogadja mindenki kitörő örömmel, hogy az NVIDIA az OpenGL problémáinak egy részét tovább akarja vinni a Vulkan API-ba.
Valójában azonban egy picit bonyolultabb az ügy. Az NVIDIA számára is káros az OpenGL helyzete, mivel például a legújabb 360-as sorozatú béta meghajtójuk számos OpenGL-es játékot elindíthatatlanná tett. A probléma ráadásul nem az eszközillesztőben van, hanem abban, hogy a fejlesztők az érintett játékokban szabálytalan rendszerhívással élnek, amelyet a korábbi meghajtók toleráltak, míg az új már ezt nem teszi meg. A Vulkan API tiszta lapja ezektől mentesítené a piacot, hiszen rengeteg OpenGL-es program futtathatóságát a PC-n csak a szerencse biztosítja, illetve az, hogy a gyártók meghajtói elfogadják a hibás kódokat. Innentől viszont árnyalódik az, hogy a mi a szabványos és mi a hibás, legalábbis a fejlesztők számára mindenképpen, ami egyértelműen nem jó.
Hasonló cipőben jár a GLSL is. Rengeteg olyan shader van a fejlesztőknél, amelyek a szó legszorosabb értelmében nem szabványosak és csak azért futnak, mert az NVIDIA Cg fordítója nem tagadja meg a programfordítást. Emiatt a nem szabványos GLSL kódokhoz igazodnia kell az AMD-nek és az Intelnek is, hiszen másképp nem fog elindulni az alkalmazás, és ezzel bekerülünk egy ördögi körbe, ami átláthatatlansághoz vezet. A Vulkan SDK esetében azonban a SPIR-V-re történő fordítás csak szabványos GLSL kódokból történhet meg, amelyből kis túlzással kevés van a fejlesztőknél.
Feltételezhetően az NVIDIA emiatt döntött úgy, hogy készítenek egy olyan kiterjesztést, amely ezeket a nem szabványos GLSL kódokat is megeszi a Vulkan API alatt. Ez abból a szempontból jó, hogy a fejlesztőknek nem kell úgymond szabványosítani több tízezer sorból álló GLSL kódbázist. Ugyanakkor rossz is, mert meglékeli a Vulkan által biztosított tiszta lapot, vagyis az OpenGL egyik legnagyobb problémáját áthozzuk az új API-ba. Ez megint erősen a DirectX, ezen belül is a 12-es verzió felé terelheti a fejlesztőket, ahol a Microsoft vasszigorral követeli meg a saját fordítójának a használatát és lehetőséget sem ad a gyártóknak ennek a megkerülésére.
