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

• #55841 Busterftw veterán Petykemano #55840

  Új Válasz 2021-07-16 11:55:40 #55841

  Ú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

  

  Busterftw

  veterán

  válasz Petykemano #55840 üzenetére

  Megforditva, elofordulhat az, hogy Nvidia tensor core-okon gyorsabban fusson, ha az Nvidia arra optimalizal?

• #55842 Alogonomus őstag Petykemano #55840

  Új Válasz 2021-07-16 12:09:06 #55842

  Ú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

  

  Alogonomus

  őstag

  válasz Petykemano #55840 üzenetére

  Több helyen olvastam olyan fejtegetést, hogy az Infinity Cache az óriási adatátviteli sebességének és elhanyagolható késleltetésének, meg a kisebb felbontásból származó nagyobb találati aránynak köszönhetően bizonyos szempontból már tekinthető az FSR "hardveres gyorsítójának" is.

• #55844 Abu85 HÁZIGAZDA Petykemano #55840

  Új Válasz 2021-07-16 12:15:52 #55844

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

  Ez a kód eléggé ALU-intenzívre van szabva, szóban akkor fog gyorsabban futni, ha több ALU kerül a hardverbe. De dedikált maggal nem.

  A dedikált magnak mindig az a gondja, hogy sok követelmény van a kód felé, és ez behatárolja a fejleszthetőséget. Ez látható a DLSS-nél. Az kezdetben a tensor magokon működött, majd az 1.9-cel lekerült róla, ekkor jött egy nagy minőségbeli ugrás. Majd a 2.0-2.1-gyel részben visszakerült, de a 2.2-vel megint lekerültek feladatok a tensorról. Egyszerűen maga a tensor mag egyáltalán nem hatékony abban a feladatban, amit a DLSS mostani verziója csinál, így jobb lesz az eljárás, ha a munka jó részét nem is a tensor csinálja meg.

  És innen trükkös a helyzet, mert építesz a hardverbe egy rakás olyan feldolgozót, amire próbálsz valamilyen munkát rakni, de közben rossz lesz a hatékonyság. A DLSS-nél ez úgy működne jól, ha a tensor magoknak lenne dedikált regiszterterületük, de akkor meg a lapka fele a tensor lenne, amit használhatsz 100-akárhány játékkal, a többi cím alatt pedig minden drámaian lelassul, mert az ALU-nak szánt tranyókat elvitte a tensor regiszterterülete.

  Értem, hogy sokan hisznek ebben a gyorsítás dologban, de ez a valóságban elég nagy kockázat. A DLSS-en borzasztóan látszik, hogy mennyire nem jól működik, a kezdeti kód óta folyamatosan kerül át a normál ALU-kra a feldolgozás, mert hiába jó papíron a tensor valamire, ha nem olyan dologra használod, amire le van tervezve a hardver. Ha pedig úgy használod, akkor meg szar lesz a minőség, lásd DLSS 1.0. Pont ugyanez lenne a baja egy FSR-nek is, ha elkezdenél dedikált hardvert építeni rá, és még a fejleszthetőséget is behatárolja.

  Olyan lehet, hogy a feladat egy kis részét gyorsítod egy külön hardverrel, de eleve egy olyan eljárás az FSR, ami egy elég gyönge GPU-n is 1 ms alatt megvan. Most ha annak egy részfeladatát felgyorsítod, akkor meglesz egy hasonló képességű modern GPU-n az eljárás 0,8 ms-ból, és akkor megveregetheted a vállad, mert az kb. 1-2 fps plusz a végleges képkockára. Cserébe ellőttél egy csomó pénzt a hardverre, a hozzáigazított szoftverre, és a tranyók egy része az FSR-t nem támogató játékokban nem is aktív. Badarság ilyet csinálni jelenleg.

  #55841 Busterftw : A tensor már a DLSS új verzióival is nagyon rossza hatékonyságú, felesleges az NV-nek az FSR átalakításába pénzt ölnie, mert a dedikált hardverek használatától csak lassulnának.

  #55842 Alogonomus : Annyira nem memóriaintenzív ez az eljárás, hogy az IF nagymértékben számítson. Valamennyit mindenképpen számít, de ez még +1 fps-t sem ad ki.

  [ 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