A Khronos Group márciusban bejelentett Vulkan API-jának töretlenül zajlik a véglegesítése, amely a tervek szerint ősz környékén meg is történhet. A korábban leírtakhoz képest azonban egy nagyon érdekes lehetőséget is sikerült kiharcolniuk a szabványosításban résztvevő programfejlesztőknek.
A Vulkan kapcsán érdemes megjegyezni, hogy az iparág történelmében ez az első API, amelyet úgy fejlesztettek, hogy a neves játék- és programfejlesztőket, illetve az általuk képviselt stúdiókat a gyártókkal egyenrangú félként kezelték. Ez már egy hatalmas előrelépés az API kialakításában, hiszen így egy gyártónak esetleg akkor sem lehetett lehetősége elgáncsolni bizonyos API funkciókat, ha az nem tetszett számára, ugyanis egyértelmű fejlesztői támogatás mellett a Khronos Group az iparág érdekeit az egyéni érdekek elé helyezte.
A fejlesztők nézőpontja régóta ismert azzal kapcsolatban, hogy az aktuális API-k korlátozzák a programjaik működését, így abszolút érthető, hogy minden erejükkel harcolnak az olyan jogokért, amelyek nagyobb beleszólást engednek az új API kialakításába, és a Khronos Group esetében most nyitott ajtókon kopogtatnak, sőt, kopogni sem kell.
A Vulkan API-hoz való kiterjesztésekre vonatkozóan egy nagyon érdekes döntés született nemrég. Amíg a régi modellben a kiterjesztések elkészítésére csak a gyártóknak volt lényegi esélye, addig a Vulkan esetében a munkacsoport tagjainak tekinthető fejlesztők megkapják a lehetőséget, hogy saját kiterjesztéseket írjanak, ha valamilyen funkcióra esetleg szükségük lenne, és tudják, hogy a kiszemelt hardver képes rá, de azt esetleg semmilyen módon nem érhetik el az API-ban.
A fejlesztők számára ez rövid időn belül a második győzelem a megszokott rendszer felett, hiszen rendkívül frusztráló, ha valamilyen adatról tudják, hogy ott van a grafikus vezérlőn belül, de a különböző API limitációk miatt azt nem érhetik el szabadon – és ugyanez igaz a hardverek képességeire is, amelyekhez esetleg nem férhetnek hozzá. A gyártók próbálják felmérni az általános igényeket és ezekre tervezni kiterjesztéseket, ám vannak egészen specifikus igények, amelyeket jellemzően kis létszámú csoport kérvényez, de ezek háttérbe szorulnak, mivel kevés fejlesztőt érdekelnek. Ez még akkor is igaz, ha az érintett rétegben az iparág legjobbjai dolgoznak.
A Vulkan API specifikus kiterjesztései kapcsán némi limitáció azért akad, ugyanis ezt a dolgot olyan eljárásokra lehetne használni, amelyek inaktiválása nem befolyásolja a programfuttatással kapcsolatos felhasználói élményt, azaz a direkten nem célzott hardvereken is működőképes marad az alkalmazás. Ez érthető kikötés, hiszen a fejlesztők valóban képesek lehetnek specifikus kiterjesztést írni egy általuk jól ismert és folyamatosan tanulmányozott GPU-architektúrára, ugyanakkor széleskörűen támogatható kiterjesztéseket jó eséllyel már nem tudnak tervezni, jellemzően azért, mert bizonyos GPU-architektúrák megismeréséhez nincs erőforrásuk, vagy nincs lehetőségük, még akkor sem, ha elvi szinte a szakmai felkészültség megfelelőnek tekinthető.
