A SPIR-V lesz a Vulkan fő újítása
A tegnapi napon már lelepleztük, hogy Vulkan néven jön a Khronos Group új generációs API-ja, amelyre korábban jellemzően glNext néven reflektáltak. Ez rendkívül érdekes esemény, mivel eredetileg az API-t 2018 körül lehetett volna bevetni, de a Khronos Group egy olyan merészet lépett, ami évekkel lerövidítette a fejlesztést.
Az előzetes teóriáknak megfelelően a Vulkan név nem véletlen. A Khronos Group részben ezzel szeretné megköszönni az AMD-nek, hogy biztosították API-jukhoz a Mantle forráskódját, illetve az AMD ezzel a névvel szeretné jelezni a piacnak, hogy a Mantle 1.0-s verziója megnyílt, ahogy a (föld)köpeny megnyílik, amikor kialakul a vulkán.
Mivel erről tegnap már írtunk, így a mai napon azt érdemes átvenni, hogy miképpen történt a fejlesztés. A Vulkan nagyrészt hasznosítja a Mantle API-t. A Khronos Group a függvények jelentős részét változatlan formában vette át, ezek nevét ugyanakkor megváltoztatták. A különbség ott keresendő, hogy a Mantle esetében ezek a függvények „gr”-rel kezdődnek, míg a Vulkan API-nál „vk”-val, de a függvénynevek többi része az egyszerűség érdekében nem módosult. Emellett a Mantle-ben elérhető függvények több mint 90%-ához pontosan ugyanaz a kód kell a Vulkan API-val is, ami egyszerűvé teszi a fejlesztők munkáját, hiszen a Vulkan API-ra egy meglévő Mantle kódról pofonegyszerű lesz portolni.
Mivel ez a része az API-nak nagyrészt ki van dolgozva, így az AMD validációs rétegét is átvette a Khronos Group. Ezt ugyanakkor megváltoztatták, mivel a Vulkan a shader fordítás tekintetében nem a Mantle API működését követi.
Mint ismeretes, a Mantle API HLSL forrásból fordított kódot az AMDIL virtuális utasításarchitektúrára. Ez egyértelműen nem jó a Khronos Group számára, így az elmúlt fél évben főleg ennek a modellnek a megváltoztatásán dolgoztak, és a validációs réteget is az új modellhez igazították. Ebbe a munkába bevonták a piac vezető játékfejlesztőit, ugyanis a tradicionális OpenGL API-ban a shader fordítás kapja a legnagyobb kritikát, így a Khronos Group jobbnak látta, ha a Vulkan ebből a szempontból a fejlesztők szakszerű segítsége mellett épül fel.
A SPIR-V az igazi innováció [+]
Az egyik legnagyobb változás a SPIR-V beépítése. A SPIR leginkább az OpenCL API-ból ismert, és egy olyan közbülső fordítási egységről van szó, ami reprezentálhatja a programot a shader forrás és a lefordított bináris között. Ennek két előnye van: egyrészt nem szükséges a fejlesztőknek magát a shader forrást szállítani a végleges programban, másrészt a fordítás erre a köztes szintre egységesítve történik, vagyis garantált, hogy a megírt szabványos shader kód futni fog a Vulkan API-t támogató hardvereken. Többek között pont az OpenGL egyik legnagyobb gondja, hogy ezt nem garantálja.
A SPIR-V kódot jelen formájában egy zárt rendszer fordítja. A Khronos Group nem zárja ki, hogy később ezt a részét is megnyitják a Vulkan API-nak, de mivel alapvetően ez a fordító biztosítja a kompatibilitást, így jobbnak látták, ha házon belül, csak a legfontosabb cégekkel együttműködve fejlesztik. Maga a Vulkan zárt SPIR-V fordítója a GLSL nyelvet támogatja, de ugyanakkor a SPIR-V egy publikusan specifikált reprezentációs szint, és itt jön az újítás igazi előnye. A GLSL használata mostantól nem kötelező, így más nyelvekből is fordítható SPIR-V kód. A Khronos Group szerint akár az adott videojáték-motor is tartalmazhat egy egyedi magas szintű nyelvet, vagy más elterjedt, domain-specifikus nyelvek is szóba jöhetnek, mint például a C++ vagy akár a C++ AMP.
Ez a változás jelentős előrelépés a fejlesztőknek is, ugyanis több vezető stúdió is bírálta már a GLSL-t és a HLSL-t, miszerint túl elavultak, így például jó lenne megoldani a C++ sablonok elérhetőségét is. Ezt az igényt most a Khronos Group meghallgatta, és tett annak érdekében, hogy megvalósuljon. Az újításokkal az eddiginél nagyságrendekkel komplexebb shaderek fejlesztésére adódik majd lehetőség, ami abszolút logikus irány.
A fentiek mellett SPIR-V támogatja majd az új OpenCL platform, ami még inkább kiterjeszti a lehetőségeket, mivel a fejlesztők a jövőben úgy is célozhatják a Vulkan API-t, hogy a shadereket OpenCL C-ben, esetleg SYCL-ben írják meg. Előbbire részben ma is lehetőség van, de a Khronos Group által kidolgozott új modell jóval egyszerűbb interoperabilitást biztosít.
Opcionális funkciók itt is
A Vulkan a DirectX 12-höz hasonlóan számos opcionális funkciót is támogat. Azt tudni kell, hogy a Mantle API alacsonyabb szintű és több lehetőséget kínál, mint a Microsoft API-ja, így az a funkcionalitás, amit az AMD kidolgozott, csak részben jó. Főleg azért, mert ha a Vulkan kötelezővé tenné a Mantle API 1.0-s verziójának összes funkcióját, akkor csak a GCN architektúrára épülő Radeonok lennének képesek támogatni. Ez nyilvánvalóan nem járható út a Khronos Group számára, így számos Mantle API-ban elérhető funkciót opcionálisan támogathatóvá tettek. Ide tartozik az aszinkron compute és aszinkron DMA képessége, illetve részben a bindless bekötési modell is.
A jó hír, hogy a Khronos Group talált járható utakat mindenki számára, így a Mantle 1.0 összes képessége elérhető a Vulkan API-ban. Például az aszinkron compute olyan hardvereket igényel, amelyek parancsprocesszorai képesek több compute parancslistát kezelni, az aszinkron DMA több DMA motort igényel a grafikus vezérlőn belül, míg a bindless bekötési modell esetében arra van szükség, hogy a leírótáblákat direkten a multiprocesszorba töltse be a hardver, de ezek mellett még számos opcionális képesség van, amelyeket a Vulkan API kiterjesztésekhez köt.
Ebből a szempontból a Khronos Group a Mantle 1.0-t alulról egészítette ki, így kidolgoztak egy alternatív bekötési modellt, és ezt azok a hardverek is képesek támogatni, amelyek a leírótáblákat a textúrázó mintavételezőjébe töltik be. Gyakorlatilag ide tartozik minden grafikus vezérlő a GCN architektúrára épülő Radeonokat leszámítva. Úgy működik, hogy a program futtatásának megkezdésekor történik egy ellenőrzés, ami szerint az alkalmazás be fogja sorolni a hardvereket a két bekötési szint egyikére. A teljes funkcionalitású szint lényegében ugyanaz, ami a Mantle API-ban van, míg a korlátozott szintet a piacon lévő összes modernebb hardver képes majd támogatni. A korlátozás egyébként főleg a leírótáblák számára, illetve a pufferformátumok kezelésére, ezen belül is az adatok olvasásának és írásának párhuzamosítására vonatkozik. Ahhoz, hogy ebből a program oldalán ne legyen gond, a fejlesztőknek majd ki kell jelölniük, hogy mely effektek igénylik a teljes funkcionalitású szintet és mely effektek futhatnak a korlátozott szinten.
Nyilván áldozat nélkül nem lehet megoldani az összes hardver tökéletes kezelését, ahogy az a DirectX 12-nek sem megy. Ebben a Vulkan API sem kivétel, és ezért kell számos opcionális funkciót kínálni, de a program futni fog, akkor is, ha nem minden hardveren aktiválható minden effekt. Ebből a szempontból a DirectX 12 és a Vulkan API is nagyszerű munkát végez.
A Vulkan API-hoz egyébként már készül egy gyártófüggetlen debugger is. Utóbbi nyilván nagyon fontos fejlesztőeszköz, és az AMD a Mantle API mellett nem adta át a GPUPerfStudio kiegészítését, vagyis ezt a problémát a Khronos Groupnak kellett megoldania. Megtudtuk, hogy a Vulkan API publikus debuggerét a Valve és a Codeplay szakemberei készítik John Kessenich segítségével.
A Vulkan API jelenleg csak a kiválasztott fejlesztőknek érhető el, de ez gyorsan meg fog változni, így hamarosan bárki megkezdheti vele a munkát. Emellett az AMD még márciusban kiad egy 450 oldalas programozói segédletet, ami megkönnyíti majd az alacsony szintű hardverelérést biztosító API-khoz a munkát. Ez a könyv elsődlegesen a Mantle API-hoz készült, de a kiemelten sok hasonlóság miatt a Khronos Group nagyon ajánlja majd az elolvasását a Vulkan API-ban gondolkodó fejlesztőknek is. Annál is inkább, mert az egyetemeken oktatott, grafikus API-kkal kapcsolatos tantárgyakban átadott tudás nem elegendő az alacsony szintű hardverelérés mellett, ezek a rendszerek ugyanis teljesen máshogy működnek, mint a tradicionális API-k, tehát másképp is kell rájuk programozni.
A jelenlegi információk szerint a gyártók nagyon érdeklődnek a Vulkan API iránt. Az AMD nyilván adott volt, de az NVIDIA, az ARM, az Imagination és a Vivante is bejelentette már a készülő támogatást. Mindemellett számos professzionális szoftvereket fejlesztő cég is közölte, hogy Vulkan API-ra váltanak az OpenGL-ről.
A Vulkan API [+]
A Khronos Group a hivatalos bejelentés mellett elmondta, hogy az OpenGL és az OpenGL ES API-k is fejlődnek tovább, így a Vulkan nem ezek leváltója, hanem ezek kiegészítője lesz.
Abu85
