Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Kézzel optimalizált, tehát direkten hardverre szabott shaderek a Radeon 6000, 5000, 500 és Vega sorozathoz lesznek. A sztenderd shaderek viszont akármilyen, shader modell 5.0-t támogató GPU-n futnak. Akár egy őskövület Fermin is. Na most ez azért elmélet, mert bizonyos VGA-khoz már nincs új driver, márpedig marha komplex compute shaderekről van szó, amihez nem árt majd némi fine tune a meghajtó oldalán. Tehát a reális minimum igény inkább az olyan shader modell 5.0-s GPU, amihez még van driver support, jelen állás szerint legalább GCN1, Kepler, Gen7.5.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
julius666
#36
üzenetére
[link] - itt van patent, amire épül.
Igen, de elmondták, hogy nem részleteket akarnak behazudni, mert akkor eltorzulnak az eredeti színek. Ehelyett információt akarnak átadni.
A CyberPunkon belül csak CAS volt. Az nem használt két külön NN-t, mint az FSR.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
julius666
#47
üzenetére
Kétféle pipeline-t használnak a neurális hálókkal. Ezek egymással párhuzamosan is futhatnak bizonyos GPU-kon. Ennek azért van lényege, hogy a részletek csak minimálisan torzuljanak. Ha több adatod van, akkor kevesebb részletet kell behazudni. A hátránya, hogy sok adattal fog dolgozni, így nagyobb a terhelése is a korábbi rendszerekhez viszonyítva. Viszont ugye ennek a célja eleve a gyorsítás, tehát ha többet is számolsz, akkor is gyorsulsz, maximum nem annyit. És itt jön elő a CPU-limit kérdése, mert 1080p-ben ebben már bele lehet futni, és jellemző, hogy egy felskálázásnál ez a számolt felbontás, vagy ennél is kisebb. Tehát a mai GPU-k főleg CPU-limitben lesznek, ahogy van is már teszt, ami ezt mutatja: [link]
Nem értem, hogyan jön ide a CP2077, abban csak CAS van, az FSR teljesen más. Nem igazán értem, hogy miért kevered a kettőt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Itt a probléma, hogy nem mindenki fogadja el, hogy ezek mindig kompromisszumok. A legjobb a natív minőség. Mindenféle felskálázás csak egy kompromisszum, amit a nyert sebességért cserébe érdemes lehet bevállalni. De nincsen előny hátrány nélkül.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Control pont azért kezdett jól kinézni a korábbi játékokhoz viszonyítva, mert átrakták a tensorról a számítást a CUDA magokra. De nem ezen múlik igazából, mert a tensor is ALU, ugyanazt a számítást tudja megcsinálni, mint a CUDA magok, csak sokkal több a korlát benne, ezért igényel sokkal kisebb lapkaterületet.
Valójában a tensor magok felépítése egyáltalán nem illik ahhoz, amit a DLSS csinál, ezért a DLSS 2.0 óta az NVIDIA nem is csak a tensor magokat használja, ugyanis azoknak rengeteg és jelentős korlátjuk van az ilyen komplex eljárásoknál. Csak az eljárás egyszerű, tensorra jól mappelhető részét csinálja a tensor, emiatt került a DLSS 2.0-val be a képbe a frame delay.A lényeg viszont az, hogy ez nem igazán a hardveren múlik. Az NVIDIA is meg tudná oldani a DLSS 2.0-t a tíz éves hardvereken (az ALU-k ott vannak bennük), ha akarnák, csak nem akarják, mert akkor sokan nem fizetnék ki az 1000 dollárt az új VGA-ért.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Sose fognak a felskálázó eljárások tökéletesen működni, de pont a Controlban érték el azt, hogy jobban működjön, mint előtte. Az első DLSS verziók még csak a tensor magokra építettek. A Control ezt hagyta ki, míg a DLSS 2.0 már nem csak a tensor magokra épít, mert valójában ezeket a hardvereket nem erre tervezték. A DLSS 2.0-ban már csak a feladatok egy kisebb részét csinálja a tensor, míg a maradék a CUDA magokon fut. Tehát az, hogy a Controlban váltottak nem átmeneti volt, hanem egy alapvető változás része, ugyanis a tensor funkcionálisan nem alkalmas arra, hogy a DLSS-t mindenféle segítség nélkül futtassa.
A probléma ott keletkezik, hogy a tensor magokat eredetileg olyan üzemre tervezték, hogy nem fog mellettük semmi sem dolgozni a compute blokkokon belül. Ez az adatközpontokban realitás, de egy komplex grafikai számításnál nem az, vagyis van a compute blokkokban egy szem 64 kB-os regiszterterület, és azon osztozkodik az összes FP32 / Int32 mag, az összes tensor mag, valamint az összes SFU. Na most a mai programokban még mindig statikus erőforrás-allokáció van, vagyis az a 64 kB-nyi kapacitás, nemhogy négy eltérő feldolgozótömbre, de egyre sem elég. Emiatt vették le a DLSS 1.9-ben a tensorról az eljárást. Egyszerűen hiába volt rajta, nem használt, mert gyakorlatilag annyi regisztert befoglalt, hogy az FP32 feldolgozók normális elérési idővel használhatatlanok voltak.
A DLSS 2.0 csak kis részfeladatokat rakott vissza a tensorra, pont annyit, hogy ne legyen túl magas a regiszternyomás, hogy az adott compute blokk még éppen működőképes maradjon. Így is veszíteni fog a hatékonyságából, mert sokszor az optimális regiszternyomás alá esik, de legalább nem annyira, hogy csak egy WARP fusson rajta. Tehát a dedikált hardver igazából már nincs annyira használva, mint a DLSS 1.0 idejében, és ennek az oka, hogy hiába nyúlnak hozzá, nincs a compute blokkban annyi regiszter, hogy több feldolgozótömb is működjön párhuzamosan. Lehetne egyébként 256 kB-nyi regiszter a compute blokkon belül, csak ez egy óriási kérdés ám tervezési oldalon, mert a regiszter bizony nagyon tranyózabáló, tehát ha hirtelen elkezdenek négyszer többet rakni a hardverbe, akkor annak az ALU kapacitás issza meg a levét, mert végeredményben ugyanakkora lapkaterületre kevesebb ALU építhető majd be. Tehát hiába látja azt az NVIDIA, hogy a tensor magok komplex grafikai számításokat végző játékok mellett csak extrém ritkán hasznosak, nem merik meglépni azt, hogy sokkal többször hasznosíthatók legyenek, mert ahhoz sokkal több regiszter kell, és az végeredményben kevesebb CUDA maghoz vezet, ami az alkalmazások úgy bő 99,9%-ában tempódeficitet fog jelenteni. Emiatt döntöttek a DLSS átalakítása mellett, hogy ne is használja igazán a tensor magokat, egyszerűen így jobban járnak az aktuális hardvereken.Ehhez egyébként sem kell célhardver. Amelyik ALU tud szorozni és összeadni, az megfelel a célnak. Mint írtam az NVIDIA azért nem engedélyezi a kisebb hardverekre, hogy vásárolj újat. De ennek nincs különösebb hardveres követelménye, szorozni és összeadni jó ideje tudnak a GPU-k.
Az AMD is korlátozhatná amúgy az FSR-t az újabb hardverekre, csak semmi értelme, mert nyílt forráskódú, így úgyis belerakná a régebbi hardverek támogatását a közösség. Az NVIDIA esetében ezt azért nem tudják megtenni, mert zárt a kód.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Kiszedtem a PDF-ből a legjobb minőségi szinthez tartozó prezentációs képeket. Sajna van rajta tömörítés, illetve szerintem az eredeti kép is 4K-s, de jelenleg nincs jobb.
Úgy nézem, hogy az ultra quality van arra belőve, hogy nehezen észrevehető legyen a különbség. A szimpla quality szint már látható különbséget ad, de több sebességet is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Van persze. A fűn és a fán észrevehető a minőségromlás quality szinttel, amit az 1060-nal mutattak.
A gyengébb minőségi szintek nincsenek megmutatva.
Az Anandtech nem tudom, hogy melyik bolygón járt, de külön meg volt jegyezve, hogy ezek valós összehasonlítások, csak ugye a stream miatt nem a legjobban lehet őket átadni, és persze ez nem sokkal kedvezőbb a PDF-ben sem, de azért jobban látszódik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Ha minden shader modell 5.0-t támogató sorozatot felsorolnának, akkor eléggé hosszú lenne a lista. Sokkal egyszerűbb az újabbakat betenni, a többit pedig other jelzés alatt. Az AMD-nek azokról kell az információ, akiknek nem őskövület hardverük van, mert akik régebbivel rendelkeznek, közel sem biztos, hogy a jövőben bővíteni fognak. Ha valaki öt éve nem vett új VGA-t, az jó eséllyel már áttért konzolra, tehát őket nincs értelme csoportosítani.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
De amúgy ezt hol olvastad?
A kód igazából tartalmaz olyan részeket, amelyekhez kellenek bizonyos hardveres képességek, de ezek leginkább az RDNA-tól vannak meg, minden az RDNA2-től. Szóval a GCN-nél nincs nagy lehetőség semmire, mert se nagy cache nincs, se NN ops, kétmagos parancsmotor. Ezek többsége csak az RDNA 2 sajátja.
[ 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
ph Az AMD teljesen nyílt megoldást fejlesztett, ráadásul igyekeztek kiszűrni a hasonló eljárások képtorzító hatásait is.
- Samsung Galaxy A54 - türelemjáték
- Kertészet, mezőgazdaság topik
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- Robogó, kismotor
- Motoros topic
- SkyShowtime
- Mazda topik
- Android alkalmazások - szoftver kibeszélő topik
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- További aktív témák...
