2. Fórumok
  3. Videokártyák
  4. Kikapcsolhatatlan sugárkövetést kínál az új Avatar játék
Keresés

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

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

    Mert az AMD-nek a képgenerálója van benne, az pedig az FSR3 része. Az NV-nek a képgenerálójához Reflex kell, de azzal vannak kompatibilitási gondok a mostani motorral. Emiatt nem igazán dolgoznak rajta, hogy bekerüljön, mert több dolgot kell frissíteni a motoron, hogy egyáltalán működjön a Reflex. Az NV pedig nem engedi meg Reflex nélkül a saját képgenerálóját. Szóval az Ubisoft csak azt nem tudja beépíteni.

    Egyébként később lehet Reflex a Snowdrop 2-ben, de kétséges, hogy az Ubisoft visszamenti-e a változásokat az Avatarig. Valószínűleg inkább nem.

    Ray Reconstructionhöz hasonló implementáció van az FSR3 kódban. Az Ubisoft írt bele egy kiegészítést, kihasználva azt, hogy nyílt a forráskódja. A DLSS-be nem tudják ezt beleírni, mert nem nyílt a forráskód. De egyébként valószínűleg megoldható lenne, mert pusztán extra adatok feldolgozásáról van szó, az menne a DLSS-nek is, de nem tudják átírni a futószalagot, hogy az FSR-nek táplált extra adatot feldolgoztassák az NV felskálázójával. Az XeSS-nél elvileg megoldható lesz, de ott megint nem fog működni a képgeneráló. De egyelőre az XeSS még nincs aktiválva.

  • #37 Abu85 HÁZIGAZDA PuMbA #35
    Új Válasz #37
    Ú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 PuMbA #35 üzenetére

    Az AMD azért ült oda a Snowdrop 2-höz, hogy az Ubit átsegítse ezen az irányon. Nyilván számukra az lesz itt a jó, hogy nekik van erre saját API-juk, amit az Ubi később használhat. De ugye ez egy bonyolult dolog. Előbb jó, ha a rendszer működik, aztán lehet nézni azt, hogy az eddig DXR-ben megvalósíthatatlan dolgok működnek-e. Ehhez viszont kell majd a specifikus API. Aztán majd egyszer lesz erre egy szabvány. Valószínűleg gyorsan, ha a DXR-ben megvalósíthatatlan dolgokat elkezdi az Ubi beépíteni az AMD-re. Akkor elkezd hátránnyá válni, hogy másnak nincs erre API-ja, és csak fallback mód van mindenre. De itt a lényeg az, hogy a Microsofton legyen egy nyomás, hogy inkább nyomja a resetet a DXR-re, és kezdjük újra egy gyorsabb megoldással. Aztán ahhoz majd tervezhetők új hardverek.

  • #33 Abu85 HÁZIGAZDA PuMbA #30
    Új Válasz #33
    Ú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 PuMbA #30 üzenetére

    Az Ubisoft nem azt ígérte, hogy változik az erősorrend, hanem azt, hogy az RT megoldásuk teljesítménycsökkenése kicsi lesz. És ez be is következett. Ezt írja a hír is.

  • #29 Abu85 HÁZIGAZDA bertapet11 #28
    Új Válasz #29
    Ú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 bertapet11 #28 üzenetére

    A programozható bejárás a felhasználóknak és a fejlesztőknek kedvez. A lényege az, hogy kontrollt ad a teljesítmény felett, így x minőség elérhető úgy, hogy a teljesítményvesztés minden hardveren 10% körül lesz, nem pedig 20-40% között, hardvertől függően.

    Az AMD onnan jött képbe, hogy nekik van egy saját, Radeon Rays API-juk erre, amit ma a HIP-en keresztül el lehet érni, és kínál DirectX 12 interoperabilitást. Maga a Radeon Rays be is lesz építve a Snowdrop 2-be, mert az Ubisoft jelenleg megkezdett irányába pont beleillik, viszont az új Avatar még csak a fallback implementációt tartalmazza, mert ugye szükség van egy olyan compute shader kódra is, ami szabványos, tehát azokon a hardvereken is működik, amelyek nem támogatják a Radeon Rays API-t az egyes feladatok gyorsítása céljából. Ugye erre az AMD is készít egy fallback implementációt Brixelizer néven, csak az Ubisoft ezzel párhuzamosan tervezett egy nagyon hasonló rendszert magának (az persze elképzelhető, hogy a kutatást megosztotta az AMD és az Ubisoft egymással, mert tényleg feltűnően hasonló a két rendszer). Nyilván aki ezt magának nem teszi meg, majd használhatja a FidelityFX Brixelizert fallbacknek. Utóbbi elérhető lesz az Xbox GDK-ban is, ellentétben a Radeon Rays API-val, ami csak PC-s.

    Aztán ezeket majd le fogja váltani a következő, traversal shadert használó DXR specifikáció, ami a jó ég tudja, hogy mikor jön, évek óta csak ígéri a Microsoft. Addig amíg nem születik meg, ilyen gyártói API-k lesznek, plusz Brixelizerhez hasonló compute shader fallback.

    Megjegyzem, hogy a Vulkan itt ki tudna törni, mert nekik nem annyira fontos a jelenlegi RT specifikációhoz igazodás, mivel amúgy sem használják a Vulkan RT-t sokan. Tehát nekik jóval kisebb gondot jelentene rátenyerelni a resetre, mint a Microsoftnak. Holott ugye ugyanazzal a limittel küzdenek. Egyszerűen simán lemásolhatná a Khronos a PlayStation 5 API RT specifikációját, amelyben van traversal shader. De akár az Xbox RT API-ja is lehet alap, ott is van per-objektum programozhatóság, csak PC-re ne hozza a Microsoft.

  • #27 Abu85 HÁZIGAZDA Kansas #23
    Új Válasz #27
    Ú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 Kansas #23 üzenetére

    A Microsofté, de a felhasznált gyorsítóstruktúra valószínűleg nem az övék, és emiatt lett az black box. Szóval a Microsoft keze is meg van valahol kötve, és rá vannak kényszerítve a lassú megoldásra, mert nem tudják kiadni a gyorsítóstruktúra specifikációját a licenc hiányában. Enélkül pedig a kód elég sok, és elég fontos részei ellenőrizhetetlenek. Ha ott van a teljesítményt csökkentő limitáció, akkor egy fejlesztőnek megfejthetetlen, hogy pontosan hol keletkezik a limit. Ezért van most egy reset előkészülőben, mert el kell vágni a kompatibilitást a mostani DXR-rel, ha tovább akarnak lépni.

  • #17 Abu85 HÁZIGAZDA flashpointer #6
    Új Válasz #17
    Ú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 flashpointer #6 üzenetére

    Eldönthető, hogy hatása van-e. Ezek már a DXR első verziója óta meglévő problémák. Egyszerűen maga az API nem kezeli jól ezeket a szituációkat a per-objektum programozhatóság hiányában. Ezért dolgozik a Microsoft a saját megoldásán, csak ugye a probléma az, hogy a Microsoft új megoldása nem igazán kompatibilis a mostani specifikációkkal, tehát nyomni kell egy great resetet.

    Az Intelnek van erre egy nagyon hasznos megoldása, csak nem megoldható szimplán a DirectX 12-ben. Valami hasonló jöhet a Microsofttól is, csak szabványosan. [link]
    Itt le lehet tölteni egy videót is, amiben az Intel részletesen prezentálja, hogy mi a gond, és milyen megoldási javaslatuk van rá. [link]

    Az Ubisoft a saját megoldásával pont ugyanerre reagált, csak compute shaderrel oldották meg, hogy kompatibilis maradjon a DirectX 12-vel. Ennek is megvannak a hátrányai, csak ma jobb szabványos megoldásra lehetőség nincs, ha a DXR limiteket el kell kerülni. Márpedig egy olyan geometriai részletességű játékban, amilyen az új Avatar, el kell kerülni, mert nagyon nagy lenne a memóriaterhelés, illetve a sebességvesztés a per-objektum programozhatóság hiányában.

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

Hirdetés