A Khronos Group az elmúlt év márciusában jelentett be Vulkan API-t, amelynek a fejlesztése még az elmúlt évben véget ért. A megjelenéssel eredetileg a SIGGRAPH Asia 2015-öt célozták meg, ahol csiripeltek is partnerek az API-ról, de akkorra sajnos nem sikerült lezárni a conformance test specifikációját, így a kiadás gyakorlatilag a mai napra csúszott.

A korábban közölt adatok lényegében nem változtak, mivel a Vulkan API nyitott könyvnek tekinthető. A nyílt specifikáció mellett az új rendszer fő előnye a konkurens DirectX 12-höz képest a SPIR-V, amely egy modern reprezentációs szintet kínál a fejlesztők számára, így lényegesen jobb lehetőségeik vannak a shaderek megírására, ahhoz képest, amit a Microsoft biztosít. Persze, ha össze akarjuk hasonlítani az API-kat, akkor a DirectX 12 bekötési modellje fejlettebb a Vulkan API-nál. Ezen a ponton tehát a Khronos Group fejlesztése némileg hátrányt szenved, de tudni kell, hogy a Vulkan tervezésénél az ultramobil hardvereket is figyelembe vette a konzorcium, ami bizonyos kompromisszumok megkötését igényelte. Összességében azonban kellemes rendszert sikerült összehozni, ami jó alternatívája lehet a DirectX 12-nek.

A Vulkan API specifikációja a hardver parancsmotorjai szempontjából is különbözik a DirectX 12-től. Mint ismert, a Microsoft alapfunkcióként követeli meg a multi-engine támogatását, tehát ha hardveresen nem is, szoftveresen le kell kezelni a copy, a compute és a grafikai parancslistákat. Amennyiben a hardver az adott parancslistát nem támogatja, úgy az API automatikusan a magasabb szinten álló parancsmotorba tölti be a feladatot. Legrosszabb esetben mindegyik parancs megy a grafikai parancsmotorba. Elvben ebből nem lehet probléma, de a gyakorlatban már az Oxide Games például megégette magát, mivel pont emiatt a működés miatt kellett az NVIDIA Kepler és Maxwell architektúráira egy alternatív kódutat írniuk.

A Vulkan a Mantle-höz hasonlóan szabványos kiterjesztésként definiálja a hardveres parancsmotorokat, így a copy és a compute parancslistákat különállóan lehet kezelni. Ennek a módszernek az előnye, hogy ha az adott gyártó úgy gondolja, hogy rossz lenne a hardverének a feladatok párhuzamos feldolgozása, akkor egyszerűen nem kell támogatni a kiterjesztést, annak ellenére sem, hogy elvben esetleg működne. Ilyen módon a fejlesztő írhat egy teljesen szabványos multi-engine kódot, miközben nem kell attól félnie, hogy az a kódút bizonyos architektúrákon rendkívül rossz sebességgel fut le. Persze multi-engine funkciót kihasználhatóvá tevő API-k esetében ez egy időszakos probléma, de akkor is kell rá egy megoldás, amíg az elavultabb hardvereket nem váltja le valami modernebb konstrukció.

A Vulkan legnagyobb előnye egyébként az új renderpass funkció. Utóbbi sem a Mantle, sem pedig DirectX 12 API-nak nem része, így egy tényleges újdonságról beszélhetünk. Ezt elsődlegesen a mobil piacon érintett gyártók erőltették, mivel az ultramobil architektúráik az általános TBR logikai futószalagjához hasonló elven működnek. A legtöbb asztali gyártó architektúrája viszont az általános IMR futószalaghoz áll közelebb. A különbségekről az alábbi cikk részletesen beszámol. A két elv közötti eltérés a mai API-kban viszonylag jól le van kezelve, de csak viszonylag és nem tökéletesen, ami problémának is tekinthető. A renderpass funkcióval a Vulkan ezt próbálja tökéletesíteni.

Egy renderpass objektum tartalmazza a képkocka struktúráját. Ezzel megoldható a TBR elvű architektúrák alapvető kezelése, vagyis megadható az az információ a meghajtóknak, amivel eldönthető, hogy az adatok mikor kerüljenek a belső és mikor a külső pufferbe. Eddig a legtöbb API eljutott, de a renderpass rendelkezik egy extrával, egészen pontosan a subpassekkel. Ezek számos fontos információt tartalmaznak képkockapuffer mellékletekről, és az alkalmazás közvetlenül kezelheti a subpassek közötti függőséget. Ilyen formában a TBR elvű architektúrák esetében pontosan meghatározható, hogy a rendszer mikor mit kezdjen a mozaikokra fenntartott pufferrel. A subpasseket azonban az IMR elvű architektúrák is képesek felhasználni persze más formában. Ezek függőségének közvetlen kezelését kihasználva a megfelelő helyzetekben megadható a hardvernek, hogy teljesen párhuzamosan végezzék el a subpassek leképezését, illetve jobb esetben szinkronizálás nélkül, akár sorrendtől függetlenül is megoldható a munka. A renderpass objektum bevezetésével tehát összességében a TBR és az IMR elvű architektúrák is hatékonyabban használhatók ki az API oldaláról.

A Vulkan esetében fontos kiemelni, hogy lehetőséget ad a platform szállítójának az egyedi feature set specifikáció megszabására. Ezt a Google rögtön kihasználta, így az Androidra a keresőóriás fogja megszabni azt, hogy mit kell támogatni a Vulkan API-ból a gyártóknak. A Windows esetében a Microsoftot ez a lehetőség nem érdekelte, vagyis végül a Khronos Group fogja kiadni a feature set specifikációt a Windows operációs rendszerekre, és ugyanezt fogják megkapni a Linux disztribúciók is.

A gyártók szempontjából az ultramobil piacon az Imagination Technologies PowerVR Series6 és Series7, a Qualcomm Adreno 400 és 500, az ARM Mali-T600, -T700 és -T800, valamint a Vivante VEGA termékcsalád, illetve az NVIDIA Tegra vonal biztosan támogatja majd az új API-t a Google által meghatározott feature set specifikáció mellett. Az asztali piacon az AMD az összes GCN architektúrára épülő Radeonra, az NVIDIA a Kepler és a Maxwell architektúrára alapozó GeForce-okra, míg az Intel a Skylake lapka Gen9-es architektúrát használó IGP-jére ad ki biztosan Vulkan API-t támogató meghajtókat. A listákban szereplő hardverek persze még bővülhetnek, de egyelőre ennyit jelentettek be az érintettek.

A gyártók többsége jelezte, hogy a szükséges meghajtókat még a héten biztosítani fogják, akár publikus formában, vagy esetleg a fejlesztőknek a zárt csatornákon keresztül. A Khronos Group emellett egy programmal is kedveskedik, így egy béta állapotú frissítést kapott a The Talos Principle című játék, amit így Vulkan API-n keresztül is lehet futtatni. Ez mondjuk nem a legjobb példa az API képességeinek szemléltetésére, de a semminél azért több.