2. Fórumok
  3. Videokártyák
  4. Még ebben a hónapban megérkezik a FidelityFX Super Resolution
Keresés

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

  • #57 Abu85 HÁZIGAZDA Nagynozi #55
    Új Válasz #57
    Ú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 Nagynozi #55 üzenetére

    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.

  • #58 Dilikutya félisten Nagynozi #55
    Új Válasz #58
    Ú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

    Dilikutya

    félisten

    válasz Nagynozi #55 üzenetére

    Gondolom, az AMD sem most kezdte fejleszteni, csak most mutatta meg, amikor már volt is mit megmutatni. Nyugi, ők se akkor hallottak először a DLSS-ről, amikor te. :)

    Nem vagyok perverz, csak haladok a korral. (Még mindig: Rock&roll feeling baby, rock&roll feeling.....)

  • #60 Abu85 HÁZIGAZDA Nagynozi #59
    Új Válasz #60
    Ú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 Nagynozi #59 üzenetére

    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.

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