A Khronos Group márciusban bejelentett Vulkan API-jának fejlesztése a végéhez közelít, és a konzorcium az aktuális adatok alapján úgy gondolja, hogy képesek tartani az év végére előirányzott elérhetőséget. A jelenleg is zajló SIGGRAPH szokás szerint az a rendezvény, ahol a Khronos Group évente beszámol az elért eredményekről és most a főszerepet a Vulkan kapta, amelynek a specifikáció majdnem véglegesek, és a hitelesítési teszt kidolgozása is megkezdődött már.
A Khronos Group az ilyenkor szokásos technikai előadásai előtt mindig tart egy összefoglalót, hogy mi várható a napokban és itt már fontos részletek derültek ki. Egyrészt a Vulkan API kap egy belső kiterjesztésrendszert, amelyet a Khronos Group feature set néven említ. Ezek írják le, hogy az API mely részeit kötelező támogatni, és melyek azok a képességek, amelyek opcionálisak, hiszen nem mindenki képes ezeket megfelelően kezelni. Ez igazából nem meglepő, az elmúlt években ezek a kiterjesztések minden grafikus API részeivé váltak, és a Vulkan is ezt a gyakorlatot oldja meg a maga módján. Változás azonban, hogy eddig a kiterjesztésrendszer alapvetően a hardvergyártóknak szólt, mivel az platformkészítők esetében az adott API funkcionálisan teljesen érinthetetlen volt, így a kiterjesztések támogatása csak attól függőt, hogy az adott hardver és a hozzá tartozó gyártói implementáció képességei mit engedtek.
A Vulkan API során a Khronos Group tesz egy lépést előre, mivel nagyon sok platform esetében egyre nagyobb gondot jelent a töredezettség, amelyek a hardverek eltérő képességeire vezethetők vissza. Nyilván az adott gyártó ezeket szeretné kihasználni, aminek a felhasználók örülnek is, de valójában ezek károsak az egész platformra nézve. A Vulkan éppen ezért megengedi, hogy az implementációkra vonatkozó feature set specifikációkat az adott platform kiadója alakítsa ki.
A specifikációk szempontjából vannak olyan elemek, amelyeket a Khronos Group határoz majd meg. Ezek annyira az API részei, hogy az egyes elemek letiltása sok kárt okozna, így ezekre szükségszerűen mindenkinek kötelező implementációt tervezni. Ilyen például a bekötési modell, amely szintekre van osztva, de az egyes Vulkan implementációk a legmagasabb szintet kell, hogy támogassák. Az már nem számít, hogy esetleg ezt a hardver nem támogatja, a hiányzó képességek emulálhatók szoftveresen is. Ugyanez igaz a parancslisták kezelésére, és az azokon beérkező feladatok párhuzamos végrehajtására. Az adott implementációnak ezt támogatni kell szoftveresen, és ha a hardver esetleg nem képes párhuzamosan futtatni bizonyos feladatokat, akkor ezeket sorban is lehet futtatni, hiszen a szinkronizáció alapján meghatározható a megfelelő sorrend. Ezekben nincs semmi meglepő és a DirectX 12 ebből a szempontból pont ugyanígy működik, mert ez biztosítja az eltérő hardverekkel való legjobb kompatibilitást úgy, hogy a fejlesztő a lehető legkevesebbet dolgozzon.
Vannak azonban olyan elemei a Vulkan API-nak, amelyre szoftveresen sem szükséges implementáció. Szimplán meghajtó visszatérhet azzal, hogy az adott funkciót nem támogatja. Ilyen lesz például az MSAA fedettségmintákra vonatkozó kiterjesztése, vagy a parancspufferek fejlett folyamvezérlése. Ezeket a dolgokat a Khronos Group ugyan mindenkinek ajánlja, de az adott platform kiadója esetleg mondhatja valamelyikre, vagy akár mindegyikre, hogy nem kéri. Ilyenkor a Vulkan API-nak ezek az extra képességei a szóban forgó platformon kihasználhatatlanok lesznek még akkor is, ha az adott hardver elméletben támogatná.
A Khronos Group célja ezzel a lehetőséggel az, hogy a platform kiadója kezelhesse a töredezettséget a probléma csírájában történő elfojtásával. Például a Google hivatalosan is elismerte, hogy támogatni fogják a Vulkan API-t, de saját feature set specifikációt állítanak fel. Valószínűleg számos előre beépített, opcionális kiterjesztést nem lehet majd használni, és ezáltal csökken a platform töredezettsége, mert nem számít, hogy ki milyen tudású rendszerchipet kínál, azt a tudást, amit a Google nem specifikál, nem lehet majd kihasználni. Ezzel kapcsolatban még fontos kiemelni, hogy a Khronos Group arra is gondolt, ha a platform kiadója nem kíván foglalkozni ezzel a szabadabb specifikációt lehetővé tevő rendszerrel. Ilyenkor sincs gond, mivel ebben az esetben továbbra is a Khronos Group felel a specifikálásért. Arról még nincs információ, hogy többi hivatalosan elismert, Vulkan API-t támogató, Windows, SteamOS, Tizen, Ubuntu és Red Hat platformok esetében ki dönt majd a feature set specifikációkról.
A Khronos Group szerint a Vulkan API az év végén lesz kiadható állapotban, továbbá számos kérésre reagálva nyílt forráskódúvá teszik a hitelesítési tesztet is.
