Mint ismeretes a Khronos Group márciusban jelentette be a Vulkan API-t, amelyről egy interjúban is beszélt Neil Trevett, a konzorcium elnöke, és az API specifikációjának lezárása is egyre közelebb van, így erről is egyre több információ derül ki.
A DirectX 12-höz mindenképp hasonlít majd abban a rendszer, hogy itt is lesznek kötelezően támogatandó és opcionális funkciók. Az API alapját adó parancslisták többszálú kreálását természetesen kötelező lesz támogatni, de ez nagyrészt szoftveres funkció, így ebből gond nem lehet. A Vulkan bekötési modellje azonban sokban különbözik a DirectX 12-től. Többek között a Khronos Group által életre hívott API nem tartalmaz túl sok erőforrástípust, ezekre ugyanis a modern hardverek esetében nincs igazán szükség. A bekötés a Vulkan API-ban is több szintre van osztva, így a legjobb szint úgynevezett teljesen bindless architektúrát követel, ahol a bekötés a multiprocesszorba történik meg. A teljesen bindless modellt nem támogató architektúrákon a különböző funkciók emulációjával lesz megoldva a működés, ami nyilván nagyobb többletterheléssel fog járni a processzor oldalán.
Az aszinkron DMA és aszinkron compute opcionális funkció, ahogy az egységes memória is. A SPIR-V-t azonban kötelező támogatni, ahogy a shaderek programozásra vonatkozó nyelvek közül a GLSL-t is. Fontos követelmény, hogy a Vulkan meghajtó mellett kötelező egy legalább OpenCL 1.2-es meghajtó is, illetve ezzel kötelező támogatni az OpenCL C nyelvet. Opcionálisan persze használható egy OpenCL 2.0-s vagy 2.1-es meghajtó a fejlettebb OpenCL C és OpenCL C++ nyelvek támogatásával. Ez a Vulkan és a DirectX 12 közötti a legfőbb funkcionális különbség. Amíg a DirectX 12 csak a HLSL nyelv legújabb verzióját támogatja, addig a Vulkan felkínálja a fejlesztőknek a lehetőséget, hogy a ne csak a ma már eléggé korlátozónak tekinthető GLSL-ben írjanak shader programokat. Ugyanakkor a modernebb OpenCL C és C++ nyelvek használatához szükséges a hardver oldali támogatás.
A Vulkan API a program indításakor ellenőrizni fogja, hogy az adott rendszerre milyen OpenCL meghajtó van telepítve, így a nem támogatott nyelvekben írt shaderek futtatását automatikusan letiltja, így a program akkor is futni fog, ha az adott konfiguráció például képtelen az OpenCL C++ nyelven írt shaderek futtatására.
A nyelvekre vonatkozó opcionális funkciók támogatása egyébként nagyrészt szoftveres fejlesztést igényelnek, tehát akármelyik modernebb GPU-architektúra képes lesz ezeket támogatni, csak egy OpenCL 2.0-s, vagy jobb esetben 2.1-es meghajtóra lesz szükség. Ez egyébként a Khronos Group nézőpontjából ígéretes stratégiának tűnik, ugyanis így az OpenCL implementációk fejlesztését a gyártók bizonyosan fel fogják gyorsítani, hiszen ez komoly teljesítményelőnyt is jelenthet bizonyos játékokban, nem beszélve az extra effektekről.
