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

• #34701 Abu85 HÁZIGAZDA Petykemano #34700

  Új Válasz 2018-08-23 10:37:40 #34701

  Ú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 Petykemano #34700 üzenetére

  A függetlenített int32 elsődlegesen ahhoz kellett, hogy sugárkövetésben ez egy, ha nem is nagyon sűrűn, de azért picit erőteljesebben használt operáció. Így az fp32-es shading mellett párhuzamosan lefuthat. Persze csak akkor, ha van elég regiszter hozzá, mert ugye ez még mindig probléma lesz, de legalább az elvi lehetőség adott.
  Az 50% az L1-ből jön, de csak akkor, ha a futtatott shader kevés warpot tud használni a Pascal multiprocesszorán. Lásd a Vega esetében az LDS pressure, amitől a Polarishoz képest a Vega CU shader teljesítménye a duplájára nőtt. Na most a Pascal->Volta/Turing váltásnál nem volt közel duplázás, de azért az összevont cache az occupancy limites szituációkban simán hoz 50%-ot, ha a meghajtó úgy van beállítva, hogy a maximális warpot direkt limitálja, hogy azzal a cache partíción keresztül csökkentse az LDS/register pressure-t. Persze a legtöbb compute shadert úgy írják, hogy ne legyen occupancy limites a Pascal/Polaris és a még korábbi generációkon sem. De azért van már olyan compute shader, ami már az. Ezekhez az új, occupancy limitre kifejezetten ügyelő Vega/Volta/Turing dizájnok az ideálisak, vagy az Intel IGP-i, azok brute force tolják. A gyakorlatban pedig ezeket azért nem látod igazán, mert rengeteg shadert futtat egy alkalmazás, tehát teszem azt a shaderek 3%-ára az új multiprocesszor hatékonyabb, de az összesített teljesítményt inkább a maradék 97% határozza meg, ahol pedig eleve nincs occupancy limit, vagy nem annyira erős, hogy amellett még ne lehessen elfedni a memória késleltetését. Persze azzal, hogy a hardverek fejlődnek, a fejlesztők egyre komplexebb shadereket írhatnak, így pedig egyre több olyan shader futhat egy játékban, ami a régi dizájnokkal occupancy limites lesz.

  A DLSS az olyan mint az SS, csak nem mindenhol alkalmazza a rendszer. Igazából azért hoz sebességnövekedést, mert közben mást viszont nem úgy számol, ahogy natív részlegességgel amúgy tenné. Ezért van megjelölve a DLSS külön, mert a DLSS nélküli eredmény jelöli a natív részletességet. Ha natív részletesség mellett lenne alkalmazva a DLSS, akkor az extra számítástól csökkenne a teljesítmény, de pont az a lényege, hogy ne kelljen némelyik számítást elvégezi.

  Ha ugyanaz a számítás az AMD és az NV között, akkor igazából a képminőség is 99%-ban ugyanaz. Egyedül a szűrés különbsége okozhat eltérést, de ez felfogásbeli különbség, illetve ebből a szempontból az AMD-nek van egy beállítása a driverben, ami annyit tesz, hogy ha a mintázat szűrésének minőségét a user "teljesítmény"-re állítja, akkor azt a minőséget kapja, amit az NV ad default. De az AMD default minősége még mindig eléggé sokban követi a Microsoft WHQL-es, mára már nem kötelező érvényű előírásait.
  A különböző eljárások pedig különböző minőséget adnak. A főbb dolgokat összehasonlítottuk régebbi cikkekben (viszont ezek jó része nem alma-alma összehasonlítás, mert eltér maga az eljárás, tehát természetes némi különbség): [link] és [link]

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