Leegyszerűsített Vulkan lett az AMD V-EZ rétege

A rendszer elsődlegesen a professzionális felhasználást célozza, tehát nem minden területen érdemes rá építeni.

Az AMD nemrég bejelentett egy Vulkan API-ra írt middleware réteget, ugyanis a cég úgy látja, hogy a professzionális, elsődlegesen CAD alkalmazások piacán az érintettek a nyilvánvaló előnyök ellenére is távol maradtak a Vulkan API-tól, de eközben az OpenGL limitációi egyre inkább érződnek. Utóbbi már nem csak az API technikai lemaradásában érhető tetten, hanem a gyártók is egyre kevesebb figyelmet fordítanak az OpenGL implementációkra, ezzel a hibajavításhoz szükséges idők jelentősen megnőttek, illetve a Khronos Group is inkább a Vulkan API-t favorizálja és az OpenGL-t háttérbe helyezi.

A fentiektől függetlenül az OpenGL még használható marad, de egyértelmű problémát jelent, hogy az iparág egyre inkább a Vulkan fejlesztésére és támogatására fordítja az erőforrásait, miközben a professzionális alkalmazások fejlesztőinek igényeit másodlagos tényezőként kezelik. Bár utóbbi nincs egyértelműen kimondva, de a Khronos Group is leginkább azt tartaná reálisnak, ha a professzionális applikációk is áttérnének a Vulkan API-ra, mert ez számos, többletterhelésből eredő problémát helyből megoldana, illetve nem kellene az OpenGL további technikai fejlesztésével foglalkozni, amire egyébként amúgy sem fordítanak ma túl nagy figyelmet.

A másik oldalt szemlélve viszont a professzionális alkalmazások fejlesztői nem kifejezetten rajonganak a Vulkan API komplexitásáért. Számos olyan dolog explicit menedzselését igényli a rendszer, ami például a CAD applikációk piacán nem egy kritikus tényező. Ilyen például a leíróhalmazok és a futószalagra vonatkozó korlátozások közvetlen kezelésének igénye, amelyek egy játék szempontjából hasznosak, elvégre ebből lehet sebességet nyerni, de a professzionális alkalmazások többségénél nincs különösen komoly előnye, miközben a befektetett humánerőforrás tekintetében nem egyszerű feladatokról van szó.

A professzionális iparág tehát problémába ütközik az OpenGL-re vonatkozó fejlesztéseknél, mert a régi API-tól egyre inkább elvonják a támogatást, de a Vulkan a jelenlegi formájában túl bonyolult ahhoz, hogy arra áttérjenek.

Az AMD egy ideje már látja ezt a problémát, és mára kidolgoztak egy arany középutat, amit V-EZ néven illetnek. A kicsit átalakított rövidítés a Vulkan Easy Mode-ból ered, és ahogy fentebb említettük egy Vulkan API-ra írt middleware rétegről van szó. A professzionális CAD alkalmazások kiszolgálását szem előtt tartó rendszer alapjaiban megőrzi a Vulkan sémáját, így nem kell új API-t vagy keretrendszert megtanulni, a lényege csupán az, hogy leegyszerűsítse a megfelelő leképező kidolgozását.

V-EZ Vulkan
A V-EZ és a Vulkan [+]

A fenti két kép nagyrészt bemutatja, hogy miről van szó, ugyanis a V-EZ gyakorlatilag lecsupaszítja a Vulkan API-t, de eközben megőrzi a kompatibilitást is, tehát ha bármelyik cégnek esetleg szüksége lenne egy olyan objektumra, ami a V-EZ rétegen belül nem érhető el, akkor arra külön írható támogatás, méghozzá anélkül, hogy a V-EZ egyszerűsítésre vonatkozó előnyeiről le kellene mondani. Ehhez a rendszeren belül van egy különálló, dinamikus linkelést biztosító segédprogram, amely gondoskodik arról, hogy mindig a meghívott függvénynek vagy objektumnak megfelelő header fájl legyen betöltve. Ilyen módon a Vulkan és a V-EZ nem ütközik össze egymással.

A memóriamenedzsment a V-EZ rétegen belül lényegesen le lett egyszerűsítve, így nem kell a fejlesztőnek törődnie a memóriahalmazok típusaival, illetve ezek tulajdonságaival, ami a Vulkan API alkalmazásoldali implementálásánál az egyik fő nehézséget okozza, de a hasonlóan bonyolult leíróhalmazok és a futószalagra vonatkozó korlátozások közvetlen kezelésének igénye is a múlté a V-EZ rétegen belül, mivel menedzselése automatizálttá válik, illetve a render passok esetében is jelentősen leegyszerűsödik a munka.

A V-EZ érdekessége még, hogy a Vulkan API-val ellentétben nem igényli kötelezően a SPIR-V reprezentációs szintet, tehát direkten elfogadja a GLSL-ben írt shadert is, noha opcionálisan lehetőséget ad a SPIR-V használatára. Itt igazából az a lényeg, hogy az alkalmazás fejlesztője eldönthesse, hogy mit akar. A Khronos Group a SPIR-V-re való kötelezéssel jót cselekszik, hiszen így garantálható leginkább az, hogy a szállított shader kompatibilis lesz az összes elérhető Vulkan implementációval, ugyanakkor a professzionális alkalmazások fejlesztői ezt a változást problémaként élik meg, mert rengeteg olyan GLSL shaderük van, amelyek még az OpenGL érából maradtak fent, és nem tudnak SPIR-V-re fordítani, mert egyszerűen a fordító nem tekinti őket szabványosnak. Itt nyilván magát a problémát az adja, hogy a shader rosszul van megírva, de annyira sok kódról van szó, hogy a legtöbben ragaszkodnak hozzá, még akkor is, ha ezek nem felelnek meg a GLSL specifikációknak. A V-EZ csupán ezért vágja ki a SPIR-V-re vonatkozó igényt, így a régi kódok használhatók maradnak.

Az AMD a V-EZ bétaverzióját már elérhetővé tette az alábbi GitHUB oldalon. Ezúttal zárt megoldásról van szó, de a vállalat megjegyzi, hogy ha a professzionális programokat szállító partnerük külön igényli, akkor megosztják a forráskódot. Egy aktuális V-EZ rétegre írt alkalmazás egyébként minden, legalább Vulkan 1.0.68-at támogató implementáción fut, tehát különálló gyártói támogatás nem szükséges. A konkurensek letiltani sem tudják a működését, hiszen ahhoz magát a Vulkan meghajtót kellene kivenni az eszközillesztőből, amit nyilván senki sem fog megtenni. A V-EZ a fentiek mellett később támogatni fogja a Vulkan 1.1-et is, de egyelőre erre nincs túl nagy igény a professzionális piacon.

Maga a middleware réteg egyébként némi többletterheléssel jár, tehát a sebesség tekintetében nem lehet majd elérni a Vulkan nyers tempóját, viszont a várható eredmény így is jelentősen jobb lesz az OpenGL-hez viszonyítva, miközben az átállás anyagi vonzata jóval kisebb, mintha a Vulkan API-ra kellene ugrani.

  • Kapcsolódó cégek:
  • AMD

Azóta történt

Előzmények

Hirdetés