Új hozzászólás Aktív témák

• #5 Abu85 HÁZIGAZDA

  Új Válasz 2025-03-22 06:16:09 #5

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  Le van írva, hogy nem a fícsőrök a gond, hanem az, hogy ettől még továbbra sincs megoldva az RT-nek a memóriazabálása, és a rossz hatásfoka.

  De akkor részletesebben. Az opacity micromaps segítségével a shader invokációk csökkenthetők, vagy akár el is hagyhatók. Ha elég nagy a geometria, akkor ez valóban hozhat 2x-es gyorsulást, de ahhoz nagy geometria kell, mert átlagos geometriánál ez nem igaz. Ott inkább 10-20% plusz a jellemző, és ez csak az eljárásra értett gyorsulás a tradicionális alpha testinghez viszonyítva. Tehát a teljes képkocka szintjén számolva ez a gyorsulás nem lesz nagyobb 0,9-1%-nál. Optimális esetben. Emiatt nem implementálta ezt senki, mert ahol számít, ott a DXR eleve rossz hatásfokkal működik, ahol pedig használható, ott szökőévente ha nyernek +1%-ot a teljes képkockára levetítve, ami nem éri meg a befektetett munkát.

  És pont emiatt baj, hogy amúgy az opacity micromaps egy tök jó dolog lenne, tényleg nem igényel extra hardvert, mert egy szoftveres fícsőr az egész, a legújabb hardverekbe implementálni lehetne, legrosszabb esetben az LDS-t használva, de igazából amíg a bejárással kapcsolatos gondot nem oldja meg az DXR, addig pont annyira fogják használni ezt a képességet a fejlesztők, amennyire most használják. Semennyire. Mert ez most is elérhető. Sőt, már több éve elérhető, és most is lehetne támogatni +1%-ért. De senki sem csinálja.

  A DXR verziónak annyi előnye, hogy nem az NVIDIA specifikációi szerint van tervezve, hanem az ARM specifikáció szerint. Tehát nem az NVIDIA technikája lett implementálva, hanem az ARM-é. Elsődlegesen azért, mert hatékonyabban működik, de még így is kicsi potenciális gyorsulás, amíg a DXR bejárással kapcsolatos gondjait nem oldják meg. Viszont az ARM megoldása implementálható a legtöbb hardverre. Ezért tudja az NV is támogatni a Turing és az Ampere architektúrán, holott a saját megoldásukhoz Ada kell minimum. És emiatt a többi gyártó modernebb dizájnjai is támogatni tudják. De a jelenlegi geometriai terhelés mellett 1% extrát, ha hoz, ez továbbra sem változott meg.

  A shader execution reorderingnek már több haszna van, de azt is csak ritkán implementálták eddig. A legnagyobb gond vele az, hogy sok munkát igényel, és akkor van csak hatása, ahol már a DXR eleve nem működik jól a nem koherens sugarak miatt. Például ezt eleve megpróbálják elkerülni a játékok, nem véletlenül, hogy az egyetlen cím, ami a shader execution reorderinget eddig beépítette az a Cyberpunk 2077 volt, de kizárólag az egyik beállításra, méghozzá az overdrive módra. És ezt jó okkal tették így, mert csak az overdrive mód alkalmaz másodlagos sugarakat. Tehát minden más módnál 0%-ot hozna a shader execution reordering, de overdrive mód alatt is az a gond, hogy a másodlagos sugarakkal kapcsolatos számítások a teljes sugárkövetés 2-3%-át teszik ki, tehát a shader execution reordering ezt a 2-3%-ot gyorsítja kb. a kétszeresére. Tehát a teljes képkockát tekintve itt is kb. 1-2%-nyi összesített gyorsulásról van csak szó.
  
  Mellesleg ez az egész például az Intel és az AMD modernebb dizájnjait azért érintik kevésbé, mert a Battlemage részlegesen, míg az RDNA 4 teljesen kezeli a másodlagos sugarak koherenciáját. Egyszerűen a hardver mindenféle extra szoftveres támogatás nélkül csoportosítja a sugarakat, hogy a koherensek lehetőleg közös szálcsoportba kerüljenek.

  Szóval örüljetek az 1%-nak, ha tetszik nektek, de ez semmit nem javít azon, amiért sokszor rém lassú a DXR. Az arabus által közölt 20-40% pedig irreális. Ha ennyit jelentene mindenki implementálta volna az elmúlt 2 évben, mert ennyi ideje érhetők el. De nem basszus, 1-2% maximum, ez is szökőévente.

Új hozzászólás Aktív témák