2. Fórumok
  3. Videokártyák
  4. Egyelőre csak az új Radeonokon működik a Godfall sugárkövetést használó effektje
Keresés

Hirdetés

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

  • #45 Abu85 HÁZIGAZDA b. #43
    Új Válasz #45
    Ú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 b. #43 üzenetére

    Ez azért lehet a véleményed, mert még nem láttad, hogy mennyire gyorsan fut ez a játék RT-ben 6800 XT-n. 1440p-ben 105 fps-t tud. RT-t kikapcsolva 121 fps. Szóval nagyon gyors az RDNA 2-re az implementáció. Az egyetlen gond, hogy két pofára zabálja a memóriát, mert nem csak pár virtuális méterig engedik futni, ahogy a régebbi játékokban, hanem nagyon messzire lövik a sugarakat. Így viszont sok objektumból kell betölteni a legrészletesebb verziót a memóriába.

    A Cyperpunk fejlesztői már megírták, hogy a megoldásuk teljesen szabványos. A Godfall azért megy csak az AMD-n, mert nem is szabványos, csak a DXR 1.1-re építettek egy kiegészítést, ami leviszi a memóriahasználatot. De ezt csak AMD-n tudják alkalmazni, mert NV-nek nincs olyan szervizkönyvtára, ami detektálná a találatokat a DXR-ben. Valószínű, hogy lesz, mert ezt a problémát pusztán a DXR 1.1 alatt nem lehet megoldani, tehát muszáj lesz valami NV specifikus API-t bevetni, hogy levigyék náluk is a memóriahasználatot. Jó eséllyel ez már létezik, csak még nem publikus, de ők bőven elérhetik, mert szükségük van rá. Ha van a találatra szervizkönyvtár, akkor onnan már át lehet vinni a munkát mondjuk az OptiX-ba. Az már egy sokkal kevésbé kötött rendszer a DXR-hez viszonyítva, és ott meg lehet csinálni ugyanazokat az optimalizálásokat, amiket az AMD-re megcsinálnak. Azzal már mehet is a kód, de az sem lesz szabványos. Viszont legalább jól fut, és ez a fontos. Megtehetnék azt is, hogy szarnak bele, és akkor vegyél 3090-et, ha be akarod kapcsolni, de az nem a normális hozzáállás, neki pont ugyanolyan fontos egy NV VGA-val rendelkező felhasználó, és ha ki tudnak dolgozni az NV-vel erre egy optimalizálást, akár az NVAPI-n keresztül, akkor megcsinálják.

    #44 arn : Őket semmi, de tesztelni, és production ready szinten effektet szállítani elég nagy különbség. Utóbbi esetben ugyanis számít, hogy mennyire gyorsan fut.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • #51 Abu85 HÁZIGAZDA b. #46
    Új Válasz #51
    Ú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 b. #46 üzenetére

    Meg lásd sok játék, de itt nem ez a lényeg, hanem, hogy mennyire messzire lövik a sugarakat. Ettől függ a terhelés is. A Godfall a nyílt jellege miatt eléggé távolra is számol, és ez az oka annak, hogy az RT effekt annyira memóriaigényes, mert nagy távolságban már rég valamelyik kis részletességű LOD-ot kell használni a modellekre, de az RT effektnél a sugár kilövésének pillanatában kell megválasztani a LOD-ot. Ha hamar találja el a sugár az objektumot, akkor ugye közel van a kamerához, és kell a részletes geometria, de ha messze lesz találat, akkor nem kell a részletesség, viszont ezt menet közben az aktuális DXR futószalagokon nem lehet jól kontrollálni, tehát kényszerből beállítják a maximális LOD-ot mindenre, mert a sugár kilövésének pillanatában nem lehet tudni, hogy a kamerától milyen távol lesz találat. Ez a probléma. A régebbi RT játékok ezt úgy kezelték, hogy nagyon limitált távolságig lőtték ki a sugarakat, és az eredményt sem a maximális részletességű LOD szinttel számolták. Ez egy memóriakímélőbb megoldás, csak rondább. Ha minden kötél szakad, akkor ezt is bevetheti a Godfall, csak a DXR 1.1 lehetőséget ad bizonyos korábbi limitációk megkerülésére, és emiatt jóval nagyobb távolságra dolgoznak, mint régen, ugyanakkor ez teremt új limitációkat, például azt, hogy az effekt rendkívül memóriazabáló lesz. De úgy néz ki, hogy ez valamilyen mértékben kezelhető a DXR-en kívül, és ezért alkalmaznak alternatív megközelítést. Az AMD-nek és az NV-nek is van saját trace engine API-ja erre (Radeon Rays és OptiX), és ezek sokkal többre képesek, mint a DXR, viszont szükség van egy olyan összeköttetésre, amivel a DXR-en belüli munkát részben átviszik egy külső komponensre. Erre kell a szervizkönyvtárakba egy találatjelző. Ha ez megvan, akkor igazából gyártóspecifikus lesz ugyan az RT, de nagyon sokat tudnak segíteni azon, hogy leküzdjék a DXR 1.1 működésének extrém memóriazabálását.
    Mondhatod, hogy szemetek, amiért ezt csinálják, de végeredményben nem kevés többletmunkával azt érik el, hogy kevesebb sebességvesztés, illetve kevesebb memóriahasználat mellett szebb effektet kapj a hardvereden. Időigényes és nehéz elérni, de végeredményben tényleg megtehetnék azt is, hogy szarnak rá, és akkor fut ahogy fut NVIDIA-n, nem optimalizálják le, te meg veheted a sok VRAM-os GeForce-ot. Jelenleg olyan 1500 dolláros kiadásba fájna neked, ha nem dolgoznának rajta, hogy működjön az olcsóbb termékeken is.

    #48 Duck663 : A PhysX már rég nagyon jól fut a CPU-kon. Nem véletlenül kopott ki a GPU-s feldolgozási formája, mert gyakorlatilag utolérte a CPU-s sebességben.

    A DXR a szabványért van, de nem tud mindent a szabvány. Mindkét DXR futószalag eléggé limitált, a DXR 1.1 kevésbé, de ettől még vannak határai, és nagyon komolyak. A gyártóspecifikus Radeon Rays vagy OptiX többre képes, és bizonyos effektek működéséhez érdemes ezeket bevetni, mert a sebességnövekedés, vagy pusztán a memóriahasználat javulása ezekkel jelentős lehet.

    Ott van még a driverekben a Mantle, a fejlesztői módban elérhető. De egy végfelhasználónak ez nem kell, teljesen jó a DXR is az AMD-nek, amit nem tudnak vele megcsinálni, arra van Radeon Rays 4.0.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • #76 Abu85 HÁZIGAZDA b. #75
    Új Válasz #76
    Ú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 b. #75 üzenetére

    Sokkal nagyobbal. Az eddig megjelent játékok közül ők küldik a legmesszebb a sugarakat. Ezért probléma nekik a memória, míg a többinek ezért nem volt az. Ez van. De elvileg meg fogják oldani úgy, hogy nem kell visszavenni a távolságból.

    Ha erre lesz életképes megoldás, akár specifikusan per gyártó alapon is, akkor az másnak is jó, mert kezelik az egyik legnagyobb gondot: a memóriazabálást. A megoldás mehet is a következő DXR-be.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • #78 huskydog17 addikt b. #77
    Új Válasz #78
    Ú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

    huskydog17

    addikt

    LOGOUT blog

    válasz b. #77 üzenetére

    Azért lett ilyen, mert az AMD így akarta, ezért fizettek a fejlesztőknek. A fejlesztők simán csinálhattak volna olyan eljárást is, amit az eddigi alkotások, így sokkal alacsonyabb lenne a VRAM fogyasztás, de a megrendelés kikötötte azt, hogy kifusson a 10 GB-ból, ezért a fejlesztők az ennek megfelelő eljárást választották és becsomagolják egy "nekünk a minőség a fontosabb" PR bulshit dobozba.

    Ez a másik oldalon is van amúgy: a Cyberpunk 2077 ray tracing effektjei kizárólag RTX kártyákon fognak menni kezdetben (a játék megjelenésekor), majd később jön az AMD patch. Nem véletlen, az NV így kérte, ezért fizettek a lengyeleknek egy csomó pénzt.

    Amúgy igen, értelmetlen, de pénz beszél. Nem érdemes ebbe többet belelátni.

    Gameplay csatornám: https://www.youtube.com/channel/UCG_2-vD7BIJf56R14CU4iuQ

  • #80 Yutani nagyúr b. #79
    Új Válasz #80
    Ú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

    Yutani

    nagyúr

    válasz b. #79 üzenetére

    Tehát amit Abu mond, semmiképpen sem lehet igaz, mert a gonosz AMD direkt kiszúr az NV tulajokkal.

    Apropó, azt tudtátok, hogy a nagy magasságban átrepülő jetek kémiai anyagokat szórnak a légkörbe, hogy mérgezzék és butítsák a zemberiséget? Most kiderült az is, hogy az AMD pénzeli a műveletet.

    #tarcsad

  • #83 Yutani nagyúr b. #82
    Új Válasz #83
    Ú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

    Yutani

    nagyúr

    válasz b. #82 üzenetére

    Mi van, ha azt mondta a fejlesztőnek az AMD, hogy itt a 16 gigás kártya, tudtok messzebbre lőni sugarat, próbáljátok ki. Hú de fasza, nem fut ki a VRAM-ból, az RTX 2000 meg kit érdekel, az úgyis a múlt. Aztán jött az RTX 3080 10 gigával, kipróbálták: de gyerekek, itt nagy b+ van, a piac nagyobb részének nem lesz így jó, vissza kell venni a távolságot, mert nem férünk bele 10 gigába. Na fasza, csak itt a határidő, ki kell jönni ezzel a sz@rral. Mindegy, a parancsot meg nem b@szhatjuk, mert szaporodik, szóval akkor release, de azonnal kérjük be a dokumentációt az NV-től és kezdjünk dolgozni a megoldáson, hogy NV kártyákon is jól fusson.

    Persze ez csak fiction, de van olyan jó, mint a ti változatotok. :)

    #tarcsad

  • #84 Cassi senior tag b. #82
    Új Válasz #84
    Ú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

    Cassi

    senior tag

    válasz b. #82 üzenetére

    Senki sem panaszkodna, ha csináltak volna egy alapszintű DXR megoldást, ami fut Nv-n is, és egy emeltet, ami csak az új Radeonokon. Akkor a kettőt össze is lehetne hasonlítani. De nyilván nem volt rá idő, tudom. :U

  • #90 Abu85 HÁZIGAZDA b. #77
    Új Válasz #90
    Ú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 b. #77 üzenetére

    Azért elég jelentős problémát jelent a nagy részletességű LOD-ot használni távol. Megbirkózik vele a hardver, de nagyon zabálja a VRAM-ot. Szóval ennek a kezelése nem egyáltalán nem felesleges, mert a VRAM-mal lehetne ám spórolni is. A brute force megvalósítás nem mindig kifizetődő.

    #88 morgyi : A Godfall implementációja az AMD-n azt csinálja, hogy dinamikusan LOD-ot vált a sugár kilövése után. Ezt programozható bejárással meg lehet csinálni nagyon egyszerűen. A gondot az jelenti, hogy szabványos futószalagon belül nem programozható a bejárás. Az NVIDIA-ra már dolgoznak egy megoldáson, ami hasonlóan képes a LOD-dal játszani, igaz nem pont ugyanúgy, ahogy az AMD-n teszik, vannak vele kezelendő kellemetlenségek, de úgy néz ki, hogy ráhackelhető ez a működés a hardverre, és így Ampere-en is spórolnak a VRAM-mal, miközben az effekt minőségében nem éri majd hátrány a GeForce-okat sem. Van realitása annak, hogy ezt megcsinálják. Ez fontos lehet számukra, mert ez az optimalizálás jelentheti a GeForce-okon a különbséget sebességben. Nem mindegy, hogy 100 fps-sel fog menni a 3080, vagy 20-szal.

    [ 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