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

• #65017 Abu85 HÁZIGAZDA Yutani #65015

  Új Válasz 2024-07-23 23:41:03 #65017

  Ú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

  válasz Yutani #65015 üzenetére

  Sajnos ez nem ilyen egyszerű. Egyszerűen a Nanite-hoz hasonló geometriai háttér nem is megvalósítható DXR-rel. Nem vélelten, hogy az Epic default szoftveres RT-t használ. Valamelyest hasonló koncepció a Nanite-hoz az Ubisoft Snowdrop 2, de nem annyira kifinomult, mint az Epic megoldása. De az Ubisoft már eljutott addig, hogy hardveres RT-t használjon rajta, anélkül, hogy lebutított geometrián futna a rendszer. Viszont a részletesség miatt muszáj volt programozható bejárást használni, így a hardverbe épített BVH gyorsítókhoz nem tudnak hozzányúlni. Cserébe sokkal gyorsabban fut, mintha hozzányúlnának.

  Mondom ez hasonló irány, amit már egyszer átéltünk a T&L-nél. Először jött a fixfunkciós hardver, aztán gyorsan el is tűnt, mert a programozhatóság hasznosabb volt.

  #65016 b. : A Sony API-ja default programozható bejárást alkalmaz. Ők ezt nem tudják már megkerülni, és nem is fogják, hiszen miért is fejlődnének visszafelé egy fixfunkciós gyorsítóval. Nem is tudna futni rajta az összes kiadott játék, mert az API nem ismeri.

  Mert a DXR mellőzése a gyenge pontokon, mint például fixfunkciós bejárás, pont azt a célt szolgálja, hogy az összes, ismétlem az összes hardveren gyorsabb legyen a sugárkövetés. Ez el van baszva a DXR-ben, és szarul lett kialakítva az egész hardveres háttér hozzá, amit a fejlesztők különböző kerülőutakkal és szoftveres megoldásokkal próbálnak menedzselni. Nem véletlen, hogy a konzoloknál ez programozható, ami a DXR-nél nem az. Így a hatékonyabb, mert programozhatod azt, hogy ki tudd vágni azt a geometriát, ami nincs is rajta a képkockán. DXR-ben erre nem vagy képes, egyszerűen számolod a nem látható dolgokat is. Nyilván masszív hátrányt jelent, hiszen egy programozható rendszer megszabadul ezektől a számításoktól.

  Erre a problémára reflektálnak ezek az új tanulmányok, de nem tudod megcsinálni ezt fixfunkciós BVH részegységekkel, mert nem tudod őket programozni. Ahogy írtam az egész kísértetiesen hasonlít a hw T&L-re. Ahol jött egy újítás, nagyon ütött, de masszív limitjei voltak, így a hardver a következő generációra el is tűnt, helyére jött a programozható ALU. Sokszor van az, hogy a fejlődést nem egy extra hardverelem adja, hanem annak az elvétele. Ennek van is definíciója: Wheel of reincarnation: Term used to refer to a well-known effect whereby function in a computing system family is migrated out to special-purpose peripheral hardware for speed, then the peripheral evolves toward more computing power as it does its job, then somebody notices that it is inefficient to support two asymmetrical processors in the architecture and folds the function back into the main CPU, at which point the cycle begins again. Several iterations of this cycle have been observed in graphics-processor design, and at least one or two in communications and floating-point processors.

  Ha megnézed egyébként, hogy mi történik az Unreal Engine 5-ben, akkor láthatod, hogy a hardveres raszterizálás is szoftveresre vált. Tehát hiába van ott a GPU-kban egy rakás raszter motor, az Unreal Engine 5 compute shader raszterizálást használ a Nanite-hoz. Nem azért, hogy lassítsanak a teljesítményen, hanem azért, mert így a gyorsabb, hiába a fixfunkciós extra hardver, meg anyámkínja. Sőt, ez még fejlődni fog, mert a Work Graphs API pont a kapcsolódó a problémákra fókuszál, tehát egyre többen fognak majd szoftveres raszterizálást választani. Annak ellenére, hogy a hardveres raszterizáló még egy darabig ott lesz a GPU-kban. Az új leképeződizájnokban a szoftveres már gyorsabb, és teljesen mindegy, hogy erre van egy extra erőforrás a hardverben.

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