A tegnapi napon számoltunk be arról, hogy egy pletyka szerint az NVIDIA külön lapkára helyezné a sugárkövetést, ma pedig már az új Radeon mesés sugárkövetés melletti teljesítménye jöhet szembe az olvasókkal. Mindezt a Moore's Law Is Dead csatorna videója szállította, amely azt állítja, hogy a sugárkövetés aktiválása csupán 9%-nyi tempóveszteségbe kerül az új csúcs-Radeonon.
A fenti videóban persze vannak más adatok is, többek között egy specifikáció, de ezek annyira nem meglepőek. A 22 TFLOPS körüli érték valószínűleg az AMD egy korábbi projekciójából származik, ugyanis a cég már közölte a partnereivel, hogy ez a számítási kapacitás a cél a friss fejlesztésnél (32 bites lebegőpontos operációk mellett), azt pedig jó ideje tudni, hogy 80 CU, vagyis jobban mondva 40 WGP, azaz multiprocesszor található majd a lapkában. Innen már csak le kell számolni az órajeleket, ami persze nem lesz pontos, mert az AMD erre vonatkozóan még a gyártóknak sem adott meg semmit, azon kívül az RDNA 2 minták maximális üzemórajele 2,7 GHz, ami az eredeti RDNA 2,1 GHz-éhez képest nyilván előrelépés, de ez egy abszolút maximum érték, tehát a tényleges paraméterekre vonatkozóan nehéz belőle következtetni.
A számítási kapacitással nem is akarunk különösebben foglalkozni, ez már egy régóta ismert célszám, így annyira nem meglepő adat. Az viszont igen, hogy a sugárkövetés aktiválása csupán 5-9% közötti deficitet jelent.
Sejtjük, hogy honnan származik az információ, tehát részben van benne igazság, de pont az a része a lényeges, amely nem került megemlítésre a videóban. Először is lényeges tisztázni, hogy a sugárkövetés egyelőre csupán effektekre van használva a játékokban, és jelenleg mondhatni olyan tipikus problémák megoldására, mint a ambient occlusion, a globális illumináció, az árnyékok, illetve a visszatükrözés. Ezek eltérő teljesítményigénnyel rendelkeznek. Tekintve a mai hardverek korlátjait, nem lehet ezeket ész nélkül alkalmazni, és a jelenlegi limitek mellett leginkább a visszatükrözés az az eljárás, ami nagy sebességveszteséget okoz. Az ambient occlusion, a globális illumináció és az árnyékok annyira nagy problémát nem jelentenek, de persze sok függ attól, hogy milyen hosszan kell számolni a sugarakkal, illetve az sem lényegtelen, hogy utóbbiakból menyi van. Az árnyékoknál ennek különösen nagy jelentősége van, mert gyakorlatilag nincs árnyalási munka, amely részfeladat egyébként a legnagyobb sebességgyilkos szokott lenni.
Valóban létezik egy olyan információ, hogy a jövőben a sugárkövetés aktiválása sokkal kisebb sebességvesztéssel jár majd, de nem igazán a hardverek miatt. A Microsoft az első DirectX Raytracing bemutatásakor – nevezzük DXR 1.0-nak, mert már az érintettek is ezt teszik – egy úgynevezett dynamic shader based raytracinget kínált fel. Ez leginkább annyit tudott, hogy működött, de egyáltalán nem a teljesítményre volt optimalizálva. A rendszer alapvetően annyit tett, hogy kilőtte a sugarakat, a hardver megkereste, hogy hol talál el egy háromszöget, ha egyáltalán lesz találat, és ennek megfelelően jöhetett egy hit vagy miss shader. Bármelyiket is hívta meg a program, az be lett linkelve az erre vonatkozó bekötési táblába, és ez alapján tudta a rendszer megosztani a hit vagy miss shaderrel a szükséges adatokat, vagyis ilyen formában volt végigkövetve egy sugár útja.
Az új DirectX Raytracing, rövidebb nevén DXR 1.1 a fentiekkel szemben bevezeti az úgynevezett inline raytracinget. Ez alapvető váltás a korábbi módszerhez képest, mivel megszűnik a bekötési tábla, illetve nem lesz több elszeparált dinamikus shader. Ehelyett már az eredeti shader tartalmazza a kontextus struktúráját, és utasítja a hardvert, hogy kezdje meg a bejárási lépcsőt. Ha egy sugárnak lesz találata, akkor a függvény visszatér, viszont már ott van a kontextus struktúrája a shaderben, amivel rögtön megkezdődhet a munka, nem kell már semmiféle adatmozgás, illetve elszeparált dinamikus shader indítása ehhez.
A jelenlegi lassú sugárkövetési teljesítményt leginkább a DXR 1.0 működéséből eredő jelentős többletterhelések okozzák. Felmerülhet a kérdés persze, hogy miért csinálták ilyenre az első DirectX Raytracinget, ha kvázi rögtön kitaláltak egy sokkal gyorsabb alternatívát ugyanarra a problémára, és azt be is vetették a DXR 1.1-ben. Nos, a szabványos működést az is meghatározza, hogy mire képesek az elérhető hardverek. Tehát elméletben lehet, hogy sokkal hatékonyabb az inline raytracing, viszont a gyakorlatban ehhez megfelelő hardverdizájn is kell. Lehet, hogy egy architektúrának jobb, ha kézileg lehet optimalizálni a hit vagy miss shader kötegelését, amire a DXR 1.0 például lehetőséget ad. Az ilyen dizájnok a DXR 1.1-gyel csak hátrányt szenvednének, mert nem elég jó a kialakított hardver ahhoz, hogy valóban hatékonyan tudjon dolgozni bekötési tábla, illetve több elszeparált dinamikus shader nélkül. A Microsoft tehát hiába adta volna ki a DXR 1.1 specifikációját sokkal korábban, ha csak az idei év végén lesznek hozzá optimális hardverek.
Amikor tehát 10% alatti lassulásokról beszélünk, és hasonlókról tényleg lehet hallani, akkor az egy DXR 1.1-gyel elérhető tényező, vagyis nem következtethető vissza ez a sebességvesztés a DXR 1.0-val készült alkalmazásokra. Azokon belül a sugárkövetéses effektek továbbra is viszonylag nagy tempóveszteséget generálnak majd, tulajdonképpen még az új hardvereken is. Szintén nem szabad abból kiindulni, amit Mark Cerny mondott a PlayStation 5 első bemutatóján. A szakember szerint már látott az érkező címekben sugárkövetésre épülő visszatükröződést, méghozzá komplex jelenet mellett, szerény teljesítményigénnyel. Ez rendben is van, csak a Sony konzolja nem a Microsoft grafikus API-ját használja. Ráadásul több helyről is hozzájutottunk már olyan információkhoz, hogy a PlayStation 5 saját Raytracing kiegészítése még a redmondiak DXR 1.1-es rendszerénél is hatékonyabb. Mindez azt jelenti, hogy a Microsoftnak még van némi dolga ezzel, mert a hardver látszólag többre képes a PlayStation 5-ben, mint amit jelenleg ki tudnak hozni belőle például PC-s szinten. Viszont alapvetően hibás következtetésekhez vezet ezeket az adatokat a PC-kre visszavetíteni, főleg a DXR 1.0-ra írt játékokra vonatkozóan.
