2. Fórumok
  3. Videokártyák
  4. Megkapta a DirectX 12-t a World of Warcraft
Keresés

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

  • #89 laposonly11 senior tag Ragnar_ #88
    Új Válasz #89
    Ú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

    laposonly11

    senior tag

    válasz Ragnar_ #88 üzenetére

    Ha csak a felbontást növeled minimálisan növekszik a vram igény, azonban ha ehhez még AA is kell, akkor az élsimítás típusától függően a VRAM igény akár látványosan is különbözhet (ehhez még a játékon belül megjelenített objektumok mennyisége is rádob, tehát nem csak játékonként más, hanem egy játékon belül is más lehet, pl. Crysis 1 sűrű dzsungele, egyértelműen több adattal terhelte a hardvert, mint a C2 kicsi városi utcái.) Érthetően itt a gyengébb és gazdaságosabb AA típusoknak kell kevesebb vram, míg a bonyolultabbaknak több, ami magasabb felbontásnál pedig hatványozottabban több, ez a rövid kis teszt jól mutatja a különbségeket pl. egy Shadow of Mordor esetében:
    FullHD - 4K
    4767 MB - 5433 MB
    Ez így alig 13%-al több ramigény
    Addig egy Unigine Heaven esetében viszont:
    1142 MB - 2981 MB
    Itt viszont már több mint 60%-os a növekedés!

    Mondjuk a teszt annyiban hiányos, hogy egy játékon belül, nem hasonlít össze különböző AA eljárásokat.

    (C1 azért került szóba, mert azt akár egy 500 Mb-os VGA-val is ki lehetett játszani highon.)

    - Lehetett de ahogy korábban írtam, alacsony felbontású textúrákat használtak akkoriban (ill. az általános monitor felbontás fele annyi pixelből állt 1280x1024), ha leszeded a 2016 os HD textúra packott a játékhoz, akkor a készítő már 3GB vramot ajánl hozzá: itt a link

  • #87 laposonly11 senior tag Ragnar_ #83
    Új Válasz #87
    Ú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

    laposonly11

    senior tag

    válasz Ragnar_ #83 üzenetére

    Mondjuk a Crysis 1 rossz példa volt, mert ugye abban elég alacsony felbontású textúrák vannak, a Crysis 2 ben meg állítólag még annál is alacsonyabbak, mivel egy játék mérete és hely a vramban legfőképpen a textúráknak kell, lehet hogy az előző generációs konzolok miatt lett butítva a C2 és szűk, gyengébb hardvert igénylő városi környezetbe rakva az egész. Na most a textúrák mérete és mennyisége igen csak megnövekedett, mivel a változatosabb helyszínekhez egyre több tereptárgy is meg kellett jelenjen a játékokban.

  • #84 Raysen623 addikt Ragnar_ #83
    Ú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

    Raysen623

    addikt

    válasz Ragnar_ #83 üzenetére

    A C2 a C1 után egy fostenger volt. Nem véletlenül vitték be a játékteret a városba, ami alatt aztán tesszellálták az óceánt meg még sok minden mást is, hogy a pirosak kártyáit visszafogja. A C3 ismét jobb lett szerintem. A felesleges hw erőforrás pazarlás meg azóta is megy PC-n. Így lehet elérni, hogy a fan-ok minden évben kártyát cseréljenek. Most a memória árak miatt még várnak a gyártók, de figyeljétek meg mi lesz itt ha kijön az új széria.

  • #82 laposonly11 senior tag Ragnar_ #81
    Új Válasz #82
    Ú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

    laposonly11

    senior tag

    válasz Ragnar_ #81 üzenetére

    A Crysis 2, szerintem még mindig jobban néz ki, de abban akkor is csak rövid pályaszakaszok vannak, lényegében egy csőben szaladsz, a GR W. meg tudtommal egyszerre tölt be egy fél megyényi területet.
    Az összehasonlításhoz szerintem inkább a Crysis 1 egyik nagyobb pályája lenne a mérvadó, vagy egy Far Cry 3-4-5.

  • #80 Abu85 HÁZIGAZDA Ragnar_ #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

    Abu85

    HÁZIGAZDA

    válasz Ragnar_ #79 üzenetére

    A DX12 is ilyen. A Vulkan esetében két tényező van, ami fontos még. Az egyik, hogy jellemzően OpenGL-ről váltanak erre az API-ra, amibe nagyságrendekkel kevesebb erőforrást rak minden érintett a DX11-hez viszonyítva. A másik, hogy a Khronos sokkal inkább egy közös nevezőre tervezte az API kritikus részeit, ami jó például az NV-nek, illetve alapvetően mindenkinek. A Microsoft nem igazán foglalkozott ezzel, ami jó volt az Intelnek azt specifikálták és kész. Az részletkérdés volt, hogy helyenként ezzel az NV-nek kárt csinálnak, például a parancslistáknál vagy a root signature esetében. Az AMD-vel sem igazán foglalkoztak, nekik csak szerencséjük, hogy a GCN semmire sem kényes igazán, tehát az is jó, amit a Microsoft specifikál, és az is jó, amit más ajánl, teljesítményben nagyjából ugyanott lesznek.

    A DX12-vel egyébként két tipikus késbe lehet futni. Az egyik a parancslisták helyzete. Ebből sok kicsi kell, hogy az NV-nek jó legyen a program, és az Intel, illetve az AMD meghajtója nem különösebben érzékeny erre, tehát nyugodtan lehet az NV ajánlásai szerint fejleszteni, az más kérdés, hogy ez a program oldalán nem kevés extra meló, tehát mondhatja a fejlesztő, hogy "baszki erre nincs időnk, hozzatok jobb hardvert". A másik tipikus gond a root signatures. Az NV azt szereti, ha buffer viewek közvetlenül ebben vannak, míg az Intelnek ez pont nem jó, és azt kedvelik, ha a Microsoft ajánlásai szerint ebben lehetőség szerint csak közvetetten vannak buffer viewek a leírótáblákon keresztül bekötve. Az AMD-nek pedig igazából mindegy, hasonló a teljesítmény így is, úgy is.

    Egyébként annak oka van, hogy a Microsoft miért így alakította ki a specifikációt. A buffer viewek esetében azért nem ideális, ha közvetlenül a root signatures részei, mert a leírótábla vagy -halmaz mögött ezek állapotát manuálisan követni kell, így ha mondjuk új információ kerül beírásra, akkor tudni kell, hogy az olyan helyre kerüljön, amit a GPU már nem használ. A root signatures részeként ez a szabály nem érvényes, vagyis minden új információt a rendszer új memóriaterületre írja, meghagyva a régi adatot is, ugyanis nem kötelező érvényű, hogy egy leképező kiderítse, hogy az használatban van-e, és jellemzően nem is teszik meg, mert a root signatures részeként nem olcsó az eljárás. Ez viszont azt jelenti, hogy a memória folyamatosan telik meg a játék előrehaladtával, amire végeredményben nagyon nehéz alkalmazásoldali menedzsmentet írni, mert csak egy bizonyos időtávon belül lehet nagy biztonsággal meghatározni, hogy mi lesz a memóriában. Hosszabb távon viszont már jönnek a gondok, ami előhozza azokat a teljesítménykritikus jelenségeket, amelyek létezése a vezető indoka volt az explicit API-k megalkotásának. Szóval a buffer viewek helyzete marhára nem egyértelmű. Igen nyomós indokok vannak arra vonatkozóan, hogy miért nem jó az NV ajánlása. És igazából a mai memóriaárak mellett a brute force módszerben sem lehet bízni, hogy majd úgyis lesz 20-30 GB VRAM a VGA-n, amit tele lehetne pakolni szeméttel.

  • #26 Viktor77 titán Ragnar_ #16
    Új Válasz #26
    Ú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

    Viktor77

    titán

    válasz Ragnar_ #16 üzenetére

    Hiába az irónia, a WoW úgy jó ahogy van. Nem kell szebb grafika, van saját stílusa. Az Unreal engine-s bohóckodások is csak elvettek a hangulatból, nem adtak hozzá semmit.

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

Hirdetés