Jelentős átalakítással készült az új Vulkan API

A core specifikáció mellett mostantól profilokkal is számolni kell, ami célpiacokhoz szegmentálja a rendszert.

A Khronos Group még 2015-ben adta ki a Vulkan API-t, amelyet három évvel később követet az 1.1-es frissítés, ami elhozta a több GPU támogatását is. 2020-ban a konzorcium bejelentette az 1.2-es verziót, ami túlzottan nagy újításokat nem vezetett be, de a programozhatóságon egyszerűsített, most pedig elkészült az 1.3-as specifikáció.

Az újítások jó része nem technikai jellegű, hanem strukturális, ami alapvetően meghatározza majd a rendszer jövőjét. Mint ismeretes eleddig volt egy úgynevezett core specifikáció, amit támogatni kellett a gyártók számára, ha meg akarták kapni a megfelelő hitelesítést. A Khronos Group jelenleg 180 darab KHR és EXT besorolású kiterjesztést tart nyilván, és ezt egészíti ki 100-nál is több gyártóspecifikus kiterjesztés. Mindez alapvetően nem gond, mert a legtöbb aktuális hardver képes megfelelni a minimális elvárásoknak, de az API meglehetősen szabadon fejlődött, ami nagyrészt azt jelentette, hogy a gyártók tervezték a kiterjesztéseiket, majd azokból idővel lett szabványos KHR alternatíva.

Ez végeredményben ahhoz vezetett, hogy a Vulkan API a core specifikáció szempontjából még ma is az OpenGL ES 3.1-re tervezett grafikus vezérlőhöz igazodik, miközben sorra jönnek a komolyabb képességeket biztosító KHR kiterjesztések, amelyek már erőteljes hardveres tudást is igényelnek. Ez azt jelenti, hogy a piac nehezen tudja meghatározni, hogy egy adott Vulkan verziónak megfelelő hardver valójában mire is képes. Konkrétabban fogalmazva az egyes a Vulkan 1.2 implementációk között igen jelentős eltérések lehettek a tudás tekintetében, ami nyilvánvalóan gond minden érintett számára.

A Khronos Group a Vulkan 1.3-ban előállt egy megoldással. A core specifikációt most is az OpenGL ES 3.1-re tervezett grafikus vezérlőkre szabták, és ez alapvetően nem rossz kiindulási alap, de e mellé még bevezetik a profilokat. Bár a működés tekintetében sok eltérés lesz, de a koncepció szintjén ez nem nagyon különbözik attól, amit a Microsoft csinál az úgynevezett FEATURE_LEVEL szintekkel. Lényegében a temérdek képesség mellett megpróbálják a hardvereket közös csoportokba szervezni.


[+]

Az első profilt a Google alakította ki és Android Baseline 2021 névre hallgat. Olyan kiterjesztéseket csap hozzá a core specifikációhoz, amelyeket aktívan használt androidos eszközök nagy része támogat. Ez egy nagyon jó alap lesz a fejlesztők számára, hiszen ha ezt a profilt célozzák, akkor igen nagy felhasználóbázist tudnak majd elérni, miközben hozzájutnak a core specifikációt meghaladó képességekhez.

A változások lehetővé teszi a Khronos Group számára azt is, hogy modern PC-kre szabott profilspecifikációt is tervezzenek, méghozzá anélkül, hogy hátrányba kerülne a többi platform. Készül is egy ilyen a Vulkan Roadmap 2022 Milestone részeként, és ez meghatároz egy olyan követelményrendszert, amely túlmutat az 1.3-as core specifikáción. Többek között a minimum paraméterek megemelésre kerülnek és kötelező lesz számos képesség támogatása. Itt a cél az lehet, hogy a Vulkan API adjon egy olyan egységes követelményszintet, ami nagyjából hozza a Microsoft DirectX 12 Ultimate képességeit, és ehhez ne kelljen gyártóspecifikus kódot használni. Ennek a projektnek az egyik legfontosabb képessége a leíróindexelés. Ez egy EXT kiterjesztés formájában (a hozzá tartózó SPIR-V kiterjesztésen keresztül) már ma is elérhető, de a Khronos Group nem tudja beemelni a core specifikációba, mert nagyon sok ultramobil grafikus vezérlő nem támogatja a bindless erőforrás-bekötési modellt.


[+]

Hogy egy példát is hozzunk a jelenlegi állapot nehézségére, a World War Z című játék fejlesztői már a programjuk kiadásakor is bőven támogattak olyan kiterjesztéseket az alkalmazott Vulkan leképezőn, amelyek nem voltak részei a szabványosnak tekinthető alapnak. Ilyen formában persze igencsak gyorsan futó kóddal álltak elő, de közben számos problémát le kellett küzdeniük, amelyek abból eredtek, hogy bizonyos kiterjesztéseket csak egy gyártó támogatott, és keresni kellett alternatív utat a kód működésére a többi gyártó hardverein. Na ennek vetne véget a Khronos Group, és lenne egy közös alap a modern hardverekre, amelyek ugyanazokat a kiterjesztéseket támogatnák, meghatározott limitek és tudásszint mellett. Erre pedig sokkal egyszerűbb tervezni, mint gyártónként felmérni az elérhető lehetőségeket, majd külön-külön optimalizálni mindenre. Ez amúgy választ is ad arra, hogy a DirectX 12 miért elterjedtebb, ha modern igényekről van szó, a Microsoft ugyanis erre a problémára már a kezdetektől figyelt.


[+]

A fentieken túl a Vulkan 1.3 core specifikációja is kiegészült, és természetesen a lehetőségek bővültek az olyan új kiterjesztésekkel, amelyeket a régebbi hardverek is könnyen támogatni tudnak. Ezek közül talán a legfontosabb a VK_KHR_dynamic_rendering, amely egyszerűsíti az API használhatóságát, de kiemelhető még a gépi tanuláshoz való skaláris szorzat, vagy a shader fordítás jobb menedzselhetősége – utóbbira eléggé nagy igény mutatkozott.


[+]

A Khronos Group a jövőben útitervet is biztosít majd az új alapoknak. Ebben többek között felvázolják majd a tervezés alatt álló új profilokat, ami azért lesz hasznos, mert a Vulkan 1.3-mal akárki létrehozhat külön profilspecifikációt. Na most alapvetően nem lenne jó, ha hirtelen mindenki elkezdene ilyeneket kiadni, mert könnyen lehet ebből idén tíz, aztán száz, majd kétszáz, és ez inkább hátrányára válna az API-nak. Ezért a konzorcium inkább előre felvázolja, hogy mikre készülnek a közeljövőben, hogy ha bárki éppen nem találja meg a számításait a meglévő profilokban, akkor előbb nézze meg az útitervet, hátha ott már készül egy olyan, amire szüksége van.

A Vulkan 1.3-ra valószínűleg minden olyan vállalat készít implementációt, amely támogatja legalább a Vulkan 1.1-et, és ahogy lenni szokott az első béta meghajtók is hamarosan megérkeznek, amelyekből pár héten belül jöhetnek tesztelt kiadások.

Azóta történt

Előzmények

Hirdetés