Az AMD bejelentette a Dense Geometry Compression Format SDK 1.0-s verzióját, amely gyártófüggetlen módon oldja meg a részletes geometria problémáját, és ez különösen fontos lett manapság, hogy a sugárkövetés terjedőben van.
Az alapvető gondot az Unreal Engine 5 sajátjának tekinthető, Nanite nevű, virtualizált geometriát biztosító rendszerek jelentik, amelyekhez hasonlóval többen előállnak majd a jövőben. Bár az egyes implementációk némileg eltérhetnek, az alapkoncepció ugyanaz lesz mindegyiknél, így jelentősen megnövelhető a modellek részletességi szintje. Ez önmagában jó, mert a részletesebb grafika felé megyünk, de nagyon kis háromszögeket kell majd feldolgozni, ami bizonyos szituációkban azzal jár, hogy gyorsabb compute shaderen keresztül raszterizálást végezni, illetve egészen magas lesz a memória terhelése is. A sugárkövetést szintén nem könnyítik meg ezek a kis háromszögek, mivel a jelenlegi API-knak egy fontos része zárt. Konkrétan fogalmazva gyártóspecifikus gyorsítóstruktúrákon keresztül lesz kezelve a bejárási lépcső, amit a fejlesztők nem tudnak programozni, így el kell fogadniuk ahogy működik az egész, akkor is, ha nem illik a virtualizált geometriához.
A fenti probléma nem most került elő, többek között az NVIDIA már megpróbálta kezelni a Displaced Micro-Mesh Engine-nel, de ezt egyrészt csak az Ada Lovelace architektúrára épülő GeForce-ok támogatták, másrészt speciálisan tervezett geometriát igényelt, vagyis minden programhoz kétszer kellett volna megtervezni és szállítani a modelleket. Emiatt nem is különösebben érdekelte ez az irány a fejlesztőket, hiszen irreális volt elvárni a rendszer támogatását.
Hirdetés
Az NVIDIA is rájött erre, így a Displaced Micro-Mesh Engine-nel végeztek, helyette a Mega Geometry technikára tértek át, amelyről az alábbi cikkben bővebben írtunk. Ez már azért jobb ötletekre épít, mint a Displaced Micro-Mesh Engine, hiszen nem kell hozzá speciálisan tervezett geometria, ami azért nagy előny, emellett a Turing, az Ampere, az Ada Lovelace és a Blackwell architektúra is támogatja. A gyorsítóstruktúra felépítésének optimalizálása, illetve a bejárási lépcső felgyorsítása tehát vállalható irány, viszont van egy nagy hiányossága: nem oldja meg a geometria tárhely- és memóriaigényének gondját.
Az AMD a fentiek miatt közelítette meg más irányból a kérdést, konkrétan olyanból, ami direkten a problémára ad választ. A DGF, azaz a Dense Geometry Format tulajdonképpen egy geometria tömörítését lehetővé tevő technika. Nagyon leegyszerűsítve, ami a textúráknak a DXT (a DirectX API-ban biztosított textúratömörítő formátumok összegző neve), az a geometriának a DGF.
A DGF esetében skálázható, blokkalapú, veszteséges tömörítésről van szó a meshletekhez, amely valóban reprezentálja a geometriát, így bármihez használható. A fejlesztők a modelleket a megszokott módon készíthetik el, majd miután ez megvan, egy tömörítővel legenerálhatják ezek DGF formátumú verzióját. Ráadásul a rendszer a működéséből eredően úgy dolgozik, hogy a gyorsítótárhoz igazodjon az adatok elhelyezése, így egy háromszög biztosan elérhető egyetlen memóriatranzakcióval.
A szoftverek már ezt a tömörített geometriát szállítják, és az ezzel járó összes folyamat kompatibilis a DirectX 12 és a Vulkan API futószalagjával, tehát a megszokott munkameneten nem kell módosítani, ugyanúgy kell csinálni a raszterizálást és a sugárkövetést, ahogy eddig, a DGF teljesen illeszkedik a meglévő programkódokhoz.
A fejlesztők természetesen meghatározhatják a geometria tömörítésének precizitását is. Itt többféle mód közül lehet választani, de általánosan elmondható, hogy minél jobb a tömörítés hatásfoka, annál több torzulással lehet számolni a geometriát tekintve. Mivel ez az egész minden modellre külön konfigurálható, így tetszőlegesen lehet dönteni arról, hogy az egyes tartalmakhoz milyen precizitás az optimális. Paraméterezéstől függően egyébként 5-7-szeres lehet nagy átlagban a tömörítés hatásfoka, vagyis ennyivel kevesebb helyet foglal majd az adattárolón, illetve a memórián – konkrétan a VRAM-on – belül az adott modell.
A fentieknek nemcsak a sugárkövetésre, hanem a raszterizálásra is hatása van, tehát a DGF nem csak a modern eljárásokhoz való, ugyanakkor a formátum kialakítását tekintve érezhető, hogy főleg a sugárkövetéshez van tervezve. Ilyen formában a DGF egyszerre oldja meg a memória terhelésének, illetve a gyorsítóstruktúra generálásának problémáját.
A hardverek kezelése szempontjából azért lesznek eltérések. A legtöbb GPU-n egy kitömörítést végző compute shadert kell futtatni, hogy a memóriában tárolt tömörített adat kezelhető legyen a grafikai feldolgozás során, vagyis konkrétan ki legyen tömörítve. Értelemszerűen ez legalább – shader modell 6.0-s – compute shadert támogató grafikus vezérlőn fut, gyártótól, valamint eszközillesztőtől függetlenül. Ha azonban az adott hardver direkten kezeli a DGF formátumú kódolt geometriát, akkor egy erre szabott hardverelem képes a tárolt, tömörített adatokat is olvasni, vagyis a kitömörítéshez használt shader szükségtelenné válik. Mindez azért nagyon kedvező a fejlesztők számára, mert elég csak a modellek tömörítésével foglalkozniuk, illetve felkínálni egy kikódolást biztosító shadert, hogy a leszállított tartalom minden hardveren futtatható legyen. Ha így tesznek, akkor azzal az adott alkalmazás tárhely- és memóriaigénye csökkenthető, nem beszélve az egyéb előnyökről, amelyek többsége főleg sugárkövetés mellett realizálható. Utóbbihoz viszont szükséges a hardverbe épített dekódolóblokk, de a tárhely- és memóriaigénye csökkenése minden grafikus vezérlőt érint.
A Dense Geometry Compression Format SDK 1.0-s verziója az alábbi GitHub oldalon keresztül érhető el. A fejlesztőkörnyezet támogatja a DirectX 12 és a Vulkan API-t, illetve az ezeket kezelő összes grafikus vezérlőt. Ezen túlmenően az AMD utalt rá, hogy a jövőben hoznak majd olyan hardvert, amely a DGF-et natívan kezeli, tehát olvassa a tömörített adatokat is, azok kikódolása nélkül.