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

• #26762 Abu85 HÁZIGAZDA

  Új Válasz 2020-04-21 18:04:01 #26762

  Ú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

  Még mindig nem értitek, hogy messze nem annyira egyszerű a sugárkövetés, mint amennyire leegyszerűsítitek. A GPU-k esetében a raszterizálás azért ideális leképezési forma, mert mindig koherens. A sugárkövetés ezzel szemben az esetek jó részében nem koherens. És itt jön az a probléma, hogy a GPU-k azért tudnak igazán hatékonyan működni, mert a grafikai számítások során ritka, hogy folyamatosan véletlenszerű adatelérés történik. Ezzel szemben a sugárkövetés során igen gyakori. Tehát vannak a sugárkövetésnek egyes lépcsői, és ezeknek a lépcsőknek mások a limitációi, viszont a fő limitáció mindenképpen a memória-sávszélesség lesz. Tehát megteheted mondjuk azt, hogy nem négy, hanem egy pixelenként lövöd ki a sugarakat, tehát effektíve négyszeresére növeled a bejárás lépcső terhelését. A fixfunkciós hardver persze, hogy jobban elbírja, de haszna a valóságban nincs, mert a mintavételre nincs még meg a memória-sávszélesség. Ha meglenne, akkor a Crytek is ezt alkalmazná, de ugye kiértékelték, hogy mire képesek a hardverek és ugyanarra a következtetésre jutottak, mint a SEED a pica-pica tesztprojekt esetében. Egyszerűen még elképesztően limitáltak a hardveres lehetőségek, így hiába vagy gyors a sugárkövetés futószalagjának egy lépcsőjén, ha a megnövekedő terhelés miatt a mintavételre már nincs meg a teljesítmény. És ugye itt a mintavétel véletlenszerű, nincs a hardverekben semmilyen koherenciadetektor, tehát minden, amit mondjuk az architektúra tervezésénél arra építettek fel, hogy a raszterizálásnál építkezhessenek a lokalitási elvre, az hasztalan a sugárkövetés során, mert tele lesz szemetelve a cache a nem koherens sugaraktól. Tehát elhiszem, hogy borzalmasan le akarjátok egyszerűsíteni a problémát, de valójában elképesztően bonyolult gondról van szó, és attól, hogy a bejárás hardveresen gyorsítható, még nem nyertél semmit. Ha nyernénk rajta, akkor a Crytek lenne az első, amely adna rá támogatást, de nem adnak. És ez a lényeges, mert például nekik többet érhet az ExecuteIndirect. Utóbbi ugye dynamic shader raytracingnél nem alkalmazható, miközben jelentős teljesítményelőnye van az olyan típusú motoroknál, amilyen a CryEngine. Tehát ahhoz, hogy nekik legyen natív a DXR 1.0-ra támogatás, ki kell kapcsolniuk az ExecuteIndirectet, és ezzel bukják a vele megnyert 5-20% teljesítményt, konfigurációtól függően. Ergo tökre nem mennek vele semmire, hogy a bejárási lépcsőre vonatkozóan gyorsabbak lesznek, ha végeredményben már lassabb az egész képszámítás. De ugyanúgy megemlíthető még a DXR 1.0 mellett a vertex formátum csak 16 vagy 32 bites lebegőpontos lehet. Az FP16 elég kevés, sok artifactet eredményez, míg az FP32 marhára overkill, mivel egy háromszög 48 bájtos terhelést jelent, ergo, marhára fogja majd zabálni a memóriát. A Crytek megoldásának az is az előnye, hogy kompatibilis a 32 bites snorm formátummal, tehát anélkül tudnak sugárkövetést alkalmazni, hogy az DXR 1.0-es FP32-re való kötelező váltás miatt butítani kellene a geometriát.

  Ezek amúgy majd a DXR 1.1-ben meg lesznek oldva, de addig komoly limitációk, és emiatt érdemes az egész képet nézni, mert valójában mindenkinek egy teljes képkockát kell számolni a játékból, ezért nyerhetsz ugyan a bejárási lépcsőn, de ha emiatt buksz egy csomó teljesítményt az FP32 vertex formátummal, illetve az ExecuteIndirect hiányával, akkor hasztalan. Érdemesebb saját megoldással próbálkozni, ahol ugyan a bejárási lépcsőre levetítve a teljesítmény nem olyan gyors, de használható az ExecuteIndirect és a 32 bites snorm vertex formátum.

  (#26758) GeryFlash: Mint írtam a CryEngine esetében az a részprobléma, amiről szó van a processzoron lesz kiszámolva, tehát nem a VGA teljesítménye dönt róla. Az, hogy egy hardver mit fog tudni, nehéz megmondani. A PC-s portot a Crysis Remastered esetében a Saber Interactive csinálja. A Crytek a PS4 és Xbox One verzióért felel, míg a Switch verzió fejlesztése közös a Saberrel. Utóbbi elsődlegesen azért lehet, mert a Sabernek sok a tapasztalata a Switch-csel, illetve a PC-s verziót is jó ötlet rájuk bízni, mert a World War Z-nél igen durva optimalizálást tettek le az asztalra.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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