A Khronos Group három évvel korábban adta ki a Vulkan API-t, amelyhez a konzorcium nagy reményeket fűzött. Az 1.0-s rendszert időközben kisebb módosításokkal látták el, de nagyobb frissítést máig nem kapott. Ezt az állapotot törte meg az 1.1-es Vulkan verzió bejelentése, amely számos korábban megígért újítást kínál immáron nem csak tesztelési céllal, hanem ténylegesen használható szabványos formában.
Az alapfunkciók tekintetében a Vulkan 1.1 két nagy újítást biztosít. Ezek közül az egyik a védett tartalom támogatása, amivel meghatározható, hogy a kódolt multimédiás tartalom csak megfelelő engedélyek mellett lehessen lejátszható. Ez elsődlegesen azért hasznos, mert a különböző videotartalmak esetében a másolásvédelem vezető szerepet játszik manapság, és ezeket csak akkor lehet a feldolgozásra használt futószalagban felhasználni, vagy egyáltalán a kijelzőn megjeleníteni, ha az adott API, illetve implementáció biztosítja a tartalom másolástól való elszigetelését. Ami a Vulkan esetében érdekes, hogy a Khronos Group nem hardveres szintű védelmet használ, így az implementációról teljes mértékben a fejlesztők tudnak dönteni, ami esetenként kedvező tényező lehet.
[+]
A másik nagy újítás a subgroup operációk, amelyhez szorosan kapcsolódik az új, 1.3-as verziójú, SPIR-V nevű reprezentációs felület. Itt nagyjából arról van szó, amit a Microsoft bevezetett a shader modell 6.0 kapcsán. Ezzel az újítással a Vulkan API 1.1 is definiálja az úgynevezett wave terminológiát, ami lehetőséget ad a modern GPU-kba tervezett szálszintű párhuzamosság rendkívül hatékony kihasználására, így egy bizonyos számú szál – vagy a jellemzően használt terminológiájával élve lane – explicit korlátozások nélkül futhat, ellentétben a korábbi lehetőségekkel, ahol ezt gyakorlatilag képtelenség volt normálisan elérni. Ezt a Vulkan – ezen belül is a SPIR-V 1.3 – támogatja a compute és a grafikai shaderek esetében is, bár nyilván a programozás szempontjából a megfelelő nyelvet kell használni. Ezen a ponton jön képbe két további, nem feltétlenül csak a Khronos Group munkájához köthető fejlesztés.
A shader nyelvek tekintetében a Vulkan igazából csak egyet támogat, mégpedig a SPIR-V-t. Ezt jó ideje ismert, és ez a modell ad arra lehetőséget, hogy a SPIR-V előtt lehessen trükközni. A Vulkan API-hoz eredetileg ajánlott GLSL mára igencsak elavulttá vált, és nem mutatkozik különösebb igény arra, hogy a Khronos Group ezt modernizálja. Helyette jön az új HLSL támogatása, amelynél az elkészült kódokat a Microsoft dxc nevű nyílt shader fordítója a SPIR-V CodeGen kiegészítéssel képes lesz lefordítani a Vulkan számára emészthető reprezentációs szintre. Ezzel gyakorlatilag a fejlesztőknek elég csak az új verziójú HLSL-re programozni, és abból a DirectX 12, illetve a Vulkan API is kiszolgálható.
A Khronos Group persze nem csak a HLSL-re gondol, hanem a saját nyelveire is, így a Google, a Codeplay, illetve az Adobe közreműködésével, Clspv néven készül egy olyan nyílt forráskódú eszköz, amely lehetővé teszi az OpenCL C nyelv egy nagyobb részhalmazának SPIR-V-re történő fordítását, méghozzá úgy, hogy a kapott kódot a Vulkan API-n is lehessen futtatni. Ilyen formában a korlátozott GLSL helyett a fejlesztők igen modern nyelveket kapnak, amelyekkel hatékonyabban lehet majd programozni a modern grafikus vezérlőket, figyelembe véve a SPIR-V 1.3 fentebb már tárgyalt újítását is.
[+]
A korábban bemutatott, régebben kísérleti fázisban lévő kiterjesztések is véglegesítésre kerültek, így a Vulkan 1.1 most már ténylegesen lehetővé teszi a több GPU-s rendszerek kihasználását. A Khronos Group megoldása a DirectX 12-höz hasonlít, így a fejlesztőknek alapvetően két lehetőségük lesz. Egyrészt az egyedi konfigurálással tetszőleges formában foghatók munkára a beépített grafikus vezérlők, de akár szimplán igényelhető a linkelt mód is, ami gyakorlatilag az AMD CrossFire és az NVIDIA SLI másolata. Ezek persze csak a működés szempontjából hasonlítanak a régi módszerhez, igazából közük nincs a CrossFire-höz és SLI-hez, mivel a vezérlést nem a meghajtó, hanem maga az API biztosítja az adott operációs rendszer kijelzőmodulján belüli speciális funkciókat aktiválva. Ez például a WDDM 2.0 alatt a linked display adapter módot jelenti.
Szintén újítás az API-k közötti interoperabilitás biztosítása, így például egy Vulkan API-ban létrehozott puffer ugyanabban a programban felhasználható akár az OpenGL ES API-ból is, illetve több folyamat használhatja ugyanazt a kontextust. Mindemellett megjelenik a multiview támogatása, ami gyakorlatilag a shader modell 6.1-ben található SV_ViewID másolata. Egészen pontosan arról van szó, hogy egyetlen rajzolási paranccsal a teljes geometria átküldhető több nézőpontra, és ez kifejezetten hasznos a virtuális valóság szempontjából, hiszen ilyenkor a sztereó 3D-s megjelenítés nem igényli majd két képkocka teljes kiszámítását.
A Vulkan 1.1 bevezet még pár új színformátumot speciálisan a YCbCr színkódoláshoz, valamint megjelenik a 16 bites adattípus szabványos támogatása. Utóbbi akkor lehet hasznos, ha a memória-sávszélesség limitálja a feldolgozást, vagy esetleg a regiszterek statikus allokációja korlátozza a futtatható wave-ek számát. Ilyenkor érdemes lehet kisebb pontosság mellett dolgozni, így kímélve a memóriabuszt és a regiszterek felé kifejtett terhelést, továbbá ha egy grafikus vezérlő natívan támogatja ezt a feldolgozási formát, akkor a számítási teljesítmény is megduplázható.
A Vulkan API 1.1-es verzióját, beleértve a szorosan kapcsolódó SPIR-V 1.3-at minden Vulkan 1.0-t támogató cég kezelni fogja. Az újítások zöme nem igényel új hardvereket, de a megfelelő implementációt el kell készíteni, így a friss, Vulkan 1.1-et támogató meghajtókat meg kell várni.
[+]
A Khronos Group egyébként elégedett a Vulkan API terjedésével, amely egyébként mobil és asztali piacon is igen kellemesen alakul.
