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.

A cikk még nem ért véget, kérlek, lapozz!