Keresés

Hirdetés

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

  • Carlos Padre

    veterán

    válasz K0vasz #48 üzenetére

    Ha igazak azok a hónapok óta keringő pletykák, hogy a Series X 4-szeres RT teljesítményt ad a 2080-hoz képest, akkor elég csúnyán fog öregedni, igen :)

    Genyó vagyok, ha hülye vagy megmondom.

  • Carlos Padre

    veterán

    válasz K0vasz #83 üzenetére

    Csak ismételni tudom magamat, vesd össze a Rachet & Crank gameplayt BÁRMIVEL amit az Nvidia nyújtani tud és gondold át mégegyszer amit írtál.

    Genyó vagyok, ha hülye vagy megmondom.

  • Kansas

    addikt

    válasz K0vasz #83 üzenetére

    A konzolokban DX12Ultimate(DXR1.1)-képes GPU-k lesznek, csak majd a Sony nem úgy hívja, mert tojik a DirectX-re. A Microsoft gyakorlatilag úgy is hívja.

    Az AMD nem "utoléri az NV-t", hanem implementálja azt a szabványt(DX12U), aminek a része az új generációs DXR, tehát papíron ugyanazt tudja feature szinten, mint az RTX-ek(DLSS-t kivéve, de az sebességjavító eljárás, nem látványvilág-javító, így e tekintetben lényegtelen).

    Ahogy annak idején az AMD-t(low-level PC API kapcsán pl.), most az NVidiát dícséret illeti, hogy egy előre mutató technológiát bevezetett, de ahogy annak idején az AMD-nek, most az NV-nek sem sikerült önerőből elterjeszteni - mindkét esetben szabványosítás és össz-gyártói támogatás hozta el az elterjedtséget(Mantle -> Vulkan + részben DX12).

    Tippem szerint az RT-képes konzolok és AMD kártyák megjelenése utáni fél-egy évben jelentősen több DXR-t támogató játék fog megjelenni, mint az NV-exkluzivitás majd' 2 éve alatt...
    Szintén tippem szerint az RDNA2-es AMD kártyák az új konzolok startja környékén jönnek, majd október-novemberben, az NV-kártyáihoz árazva, talán egy bolhafingnyival jobb ár/érték aránnyal, szokás szerint.

    (#88) morgyi : egyedül biztos nem, és alighanem a konzolok sebességét se fogják elérni az első ilyen megoldások a fixfunkciós egységek hiányában, de talán első körben annyit elhoznak PC-re is, hogy ha gyors SSD-t érzékel a telepítő, akkor nem multiplikálja a lemezen az asset-eket(kisebb lesz az installált méret) és talán jobban optimalizálja SSD-re a betöltéseket is, tehát ha nem is teljesen, de gyors SSD használatával javarészt megszabadulhatunk a töltőképernyőktől... talán.
    Valahol el kell kezdeni...

    [ Szerkesztve ]

    Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.

  • Abu85

    HÁZIGAZDA

    válasz K0vasz #99 üzenetére

    Igazából PC-n a Ratchet & Clank aktuális verziója nagyon nehezen futna. Az adatmennyiség, amivel real time dolgozik, az nagyjából 100 GB. Ez PS5-ön könnyű, mert alapvetően a játék úgy működik, hogy a telepített program lesz maga a rendszermemória. A PS5 valós memóriájának egy kis része, konkrétan 2,5 GB lesz a CPU memóriája, a maradék, OS által nem használt terület pedig egy utolsó szintű, több GB-os cache-ként működik, ahova az SSD-ről streameli a rendszer az éppen szükséges tartalmat. Ezért tudnak olyat csinálni, hogy egyik pillanatról a másikra kicserélik a főhős körül a pályát, ugye a dimenzióváltás. Na most ezt PC-n is meg lehetne oldani, de szükség lenne arra, hogy az adat ott legyen a RAM-ban és a VRAM-ban, viszont nem elérhetők olyan memóriakapacitással rendelkező VGA-k, amelyek el tudnának bánni ekkora adatmennyiséggel. A dolog úgy lenne megoldható, hogy a gyors váltások valójában töltőképernyőt eredményeznének, így ha a gépben lenne mondjuk 64 GB-nyi rendszermemória, akkor onnan másolhatók lennének a szükséges adatok a VRAM-ba, és akkor futna PC-n is, de elképesztően megtörné a játék működését, mert ez egy játékmenetbe épített elem, minden dimenzióváltásnál a loading felirat, majd a várakozás megtörné az élményt.

    Az az Unreal Engine 5-ös techdemó is hasonlóan működik. Az egész adatmennyiség, amit feldolgozó 150 GB fölötti. Működne ez PC-n is, mert a számítási kapacitás megvan, de hiányzik a memória VGA-król hozzá, így olyan pop-up "élmény" lenne az egész, mint anno volt a Rage. Ezen úgy segít az UE5 PC-n, hogy 128 GB rendszermemóriát használ, de még így is rengeteg a popup. Egy szimpla, 32 GB RAM-mal rendelkező PC-n 20 másodpercig is eltart, amíg feltextúrázza az aktuális környezetet a motor. Addig persze fut, tudsz benne járkálni, csak elmosódott minden felület, és mivel a mai VGA-k VRAM-ja eléggé limitált, gyakorlatilag rövid időn belül törölni kell a tárolt tartalmat, tehát az egész egy pop-up fesztivállá válik. De persze lefut, a Rage is működött pop-up mellett. Csak a játékosok nem voltak kibékülve, hogy várni kellett, amíg a textúrák megjelentek.

    (#84) morgyi: Az, hogy az explicit API memóriamenedzsmentje nehéz, nem jelenti azt, hogy nem tetszik a fejlesztőknek, hiszen van egy nagy különbség a régi API-hoz képest. Ha esetleg nem működik a program, akkor tudnak rajta módosítani, míg régi API-val ez lehetetlen volt, a gyártókat kellett megkérni, hogy ha van esetleg idejük, akkor csináljanak már valamit, ha szerencséjük volt fél év alatt csináltak is.

    ---

    Általánosan a DXR-re.

    A DXR 1.0 nagyrészt a Microsoft és az NVIDIA megoldása volt, míg a DXR 1.1 már sokkal átfogóbb egyeztetés eredménye, így elég nagy kooperációval alakult ki. Az AMD megoldása egy harmadik alternatíva, és elérhető mindkét új konzolon. Alapvetően a Microsoft, a Sony és az AMD közös fejlesztése, ebbe a PC-s GAB tagok nem szóltak bele. Majd ezt is eléjük fogják rakni, és akkor erre készülhet egy szabvány.

    [ Szerkesztve ]

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

  • Carlos Padre

    veterán

    válasz K0vasz #99 üzenetére

    Hogyne. Főleg úgy, hogy a Minecraft RT is a határait feszegeti a DF szerint.
    Az Unreal 5 bemutató másnapján egy csájníz oldalon feltűnt 2070es videó után meg akkora a kuss a témában a fanboyokon kívül, hogy öröm nézni. Biztos a Sony-Epic maffia odahatott.

    Genyó vagyok, ha hülye vagy megmondom.

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