Sokan azt várták, hogy a Khronos Group márciusban bemutatott Vulkan API-ja a SIGGRAPH Asia 2015-ön fog hivatalosan is megjelenni, ám nem ez történt. A konzorcium továbbra is csak beharangozót tartott, bár kétségtelen, hogy egyre több információ érhető el a rendszerről, de ami a legfontosabb, hogy továbbra is az idei elérhetőség a terv. Sajnos azonban pontos dátum még mindig nincs, viszont túl sok hét már nincs hátra az évből. A SIGGRAPH Asia rendezvényen viszont előkerült pár dolog a Vulkan API-ról, amelyek eddig csak részben voltak ismertek. Többek között a rendszert úgynevezett feature set specifikációit továbbra is meghatározhatja az adott platform szállítója, de kiderült, hogy az API strukturális felépítése milyen elvek alapján született meg.
Egyrészt lesznek az API-ban kötelezően támogatandó funkciók. Ezek jelentik az alapot ahhoz, hogy a fejlesztők megfelelő programokat írhassanak, és a kötelező funkciókat minden gyártónak és platformot szállító cégnek támogatnia kell. A következő szintet az opcionális funkciók jelentik. Ezeket Khronos Group dolgozta ki, de az eltérő igények miatt nem teszik kötelezővé a támogatást, mivel az API által megcélzott széles területen igen eltérő tudású hardverek vannak. Erre vonatkozónak majd a feature set specifikációk is, és a platformot szállító cégek is az opcionális funkciók megnyirbálásával alakíthatnak ki saját feature set specifikációkat. Az opcionális funkciókat egyenként, egymástól függetlenül lehet majd bekapcsolni. Ha erre vonatkozóan az erőforrás kreálásakor a programkód nem tartalmaz semmilyen utasítást, akkor a funkciók inaktívak maradnak. Végül ott lesznek a kiterjesztések is, amelyeket teljes egészében az adott hardvergyártó szállíthat az API-ba, vagy akár gyártói kooperációban is megszülethetnek. Ezeket is külön kell aktiválni az erőforrás kreálásakor. Később a kiterjesztések esetleg szabványos formában bekerülhetnek az API-ba opcionális funkcióként, majd később kötelezővé is lehet őket tenni.
A Vulkan API a platformba való integrálás szempontjából jól áll. A Khronos Group szerint első körben a Windows operációs rendszerek, illetve a Linux disztribúciók lesznek támogatva, de később elérhető lesz Android és Tizen operációs rendszereken is.
A Windows esetében a WDDM valamelyik verziója alapkövetelmény lesz, tehát Windows XP-re már nem lesz elérhető az API. Ezen belül is a WDDM 2.0-t használó Windows 10 operációs rendszeren lehet majd elérni a legjobb eredményeket, mivel az új felület működése sokkal jobban illik az explicit, vagy alacsony szintű hardverelérést lehetővé tevő API-khoz, mint a korábbi WDDM-ek. Ettől függetlenül a korábbi verziók is kompatibilisek, de helyenként lassabb lehet a feldolgozás.
A Linux esetében a Vulkan támogatja a Waylandet és a Mirt, illetve az X felületet is a DRI3-on keresztül. Ezzel kapcsolatban megtudtuk, hogy a gyakorlati működés szempontjából a legjobb eredményeket a Wayland és a Mir adja, míg az X felület helyenként lényegesen lassabb. Utóbbi nem tűnik akkora problémának, mint amilyennek elsőre látszik, mivel több Linux disztribúció esetében is alapértelmezetté válhat a Waylandet a következő év során.
A fentiek mellett a Vulkan API egyik legjobb pontja a fejlesztők nézőpontjából, hogy konzisztensnek tekinthető. Az egész API platformtól függetlenül ugyanazokat a kötelező, mondhatni fő funkciókat biztosítja, ugyanazokkal a könyvtárakkal, ugyanazokkal a header fájlokkal, így minden platformra megfelelő ugyanaz a kód.
A teljesítmény szempontjából a legnagyobb előny az lesz, hogy a Vulkan API-ban az egységes és gyors kódokban hisz. Ez alapjaiban különbözik attól, amit az OpenGL és az OpenGL ES biztosít, amelyek rengeteg lehetséges utat kínáltak a fejlesztőknek ugyanarra a problémára, és ezek közül nagyon nehéz volt kiválasztani a legjobbat, mert az egyes megoldások nem futottak egységesen optimálisan az egyes hardvereken. Nagyon sokszor kialakult az a helyzet, hogy a gyártók teljesen ellentmondtak egymásnak az optimális programkód szempontjából, ami legjobb esetben is ahhoz vezetett, hogy az adott fejlesztő mindegyik utat lefedte a programkódban, vagyis sokszorosan dolgozott. Legrosszabb esetben pedig akár a megfelelő meghajtó elérhetősége ellenére sem volt hajlandó jól futni a program.
A Khronos Group korábban azt vallotta, hogy a több lehetséges megoldás az egyes problémákra azért jó, mert így minden gyártó igényeit ki lehet elégíteni, de valójában ez a felfogás inkább csak kárt okozott. Például adatfeltöltés szempontjából az OpenGL verziók rémálomnak számítanak, mert szinten minden gyártó eltérő igényeket fogalmaz meg. Ez tarthatatlan volt hosszabb távon, és ezért a Vulkan API nagyrészt lemásolta az AMD Mantle API-jának megoldásait mindenféle alternatíva nélkül, amivel az egész rendszerre való programozás radikálisan egyszerűsödött. Mostantól gyakorlatilag minden problémára egy nagyon gyors út van, és azt használhatja a programozó. Ez persze távolról sem jelenti azt, hogy minden hardveren ugyanolyan hatékony lesz az adott problémára a megoldás, de a gyakorlat azt mutatja, hogy még a kompromisszumok mellett is nagyon jól működik a rendszer.
Az eddigi eredmények szerint az Imagination és az AMD hardverei érzik magukat a legjobban a Vulkan API-ra írt programokban, de fontos kiemelni, hogy ez nem feltétlenül vezethető vissza arra, hogy az egyes problémákra való alternatív megoldások megszűntek. Ennek sokkal inkább ahhoz van köze, hogy a legtöbb kutatás Imagination és AMD hardvereken zajlik, csupán azért, mert a Rogue és a GCN architektúrák jól dokumentáltak, így gyártói segítség nélkül is lehet rájuk optimalizálni. A többi architektúrára az optimalizációt a legtöbb fejlesztő csak akkor adja hozzá, ha a programkód az úgymond vezérplatformokon jól működik, és emiatt az előzetes eredmények nagyon csalókák lehetnek.
Hosszabb távon a Vulkan API egyszerűsítésétől azt várják az érintettek, hogy megszűnnek az alternatív, gyártóspecifikusan optimalizált kódok, ráadásul az API-hoz is hozzá lehet tervezni a készülő hardvereket. Viszont az egyszerűsödés nem azt jelenti, hogy az optimalizálás mostantól elhanyagolható tényező lesz, de a temérdek lehetőség megszűnésével a hardverspecifikus optimalizálás hasznossága redukálódik, így sokkal átláthatóbb lesz a programkód is.
