Hirdetés
- Silent Hill 2 Remake - Középpontban a PS5-ös kiadás
- SWORD ART ONLINE Fractured Daydream - Elindult a nyílt teszt
- Hosszabb előzetesen a Tomb Raider animációs sorozat
- Jövő év elején jön a most bejelentett Like A Dragon: Pirate Yakuza in Hawaii
- Rövid teaser trailert kapott a Splinter Cell animációs sorozat
-
GAMEPOD.hu
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Erről beszélnek kb. jó ideje a fejlesztők. Hiába nő a teljesítmény, ha ahhoz nem lehet hozzányúlni, mert valami megakadályozza. A DX API akadályozza meg ezt alapból, de ez a probléma többszintű, mert a DX API nem lenne annyira korlátozó tényező, ha a mai grafikus driverek úgy működnének, mint három éve, csak akkor meg a grafikát kellene lebutítani. Régebben nem igazán törődtek azzal a fejlesztők, hogy mik a grafikus driver igényei. Ma ezek annyira máshogy működnek, hogy követni kell a gyártók ajánlásait, mert más irányból megközelítve rossz lesz az eredmény. Főleg az NVIDIA ajánlásait érdemes követni, mert a GeForce driver nagyon agresszívan kisajátítja az erőforrást, így ha DC mellett nem kap három, illetve IC mellett kettő magot, amihez a program onnantól kezdve hozzá sem nyúl, akkor sok esetben káros lesz a sebességre és a stabilitásra a driver működése. Persze ezt nem minden modern motor követi, például a Frostbite 3 csak egy magot ad a drivereknek, és azért éri el így is azt a jó teljesítményt, amit tud, mert minden lehetséges módon megakadályozza a drivert abban, hogy elvégezze a feladatának egy részét. Azt a részét, amelyet amúgy a Frostbite már elvégzett, tehát felesleges lenne még egyszer erőforrást pazarolni rá. A Frostbite 3 ma az egyetlen motor, amely például DX11 alatt az állapotváltások szűrését csak egyszer futtatja, és azután a rendszer elzárja az adatokat a DX API és a driver elől, hogy az a programszál, amely arra létrejött ne futtasson több szűrést ezeken. A driver szimplán várakozásra van kényszerítve, és addig vár az adatra, amíg a program fut. Nem elegáns megoldás, mert ez a várakozás programfagyást eredményezhet (sőt egyszer biztosan fagyni fog, de kb. 20 óra után, ameddig nem sok ember játszik egyhuzamban). A BF4-nél vagy a PvsZ:GW-nél a DX11-es kód igen sokáig bírja anélkül, hogy a Frostbite 3 driver működését akadályozó modulja device hung hibát eredményezne, amivel ugye kilépne a program. A DA Inquisition az ellenpélda. Ott DX11 alatt sajnos igen sűrű a fagyás. Jelenleg 15% az esélye, hogy a program egy óra játék után device hungot dob és kilép. Ezen nagyon dolgoznak a fejlesztők, mert ez sokkal rosszabb arány, mint ahogy a korábbi játékok működtek, igaz azok nem a legújabb Frostbite 3-at kapták meg.
Felelősöket nem érdemes keresni, mert a probléma többszintű. A legtöbb fejlesztő az új grafikus driverek agresszív erőforrásigényét nevezik meg problémaként, de valójában az, hogy ma öt-hét szálat simán futtat egy driver annak az eredménye, hogy a DX11 2000 batch/frame-es limitjét nem teljesítik a fejlesztők, tehát az NV-nek és az AMD-nek sincs igazából sok választása, valamilyen módon meg kell oldani, hogy meglegyen a 3000-5000 batch/frame-re is a teljesítmény. Nehéz azt mondani a fejlesztőknek, hogy márpedig butítsátok le úgy a PC-s port grafikáját, hogy beférjen a DX11 limitjébe. Saját maguknak ásnák a sírt, ha ezt mondanák a PC-ből élő gyártók, mert a konzolon ezt nem kell megtenni. Szóval a probléma alapja egyértelműen a DX11, amely képtelen kompromisszumok nélkül kiszolgálni a fejlesztők igényeit.
Jelenleg nagyjából három opció van a fejlesztők előtt DX11-re:
- betartani a DX11 limitjeit, így maga az API optimálisan működik, tehát viszonylag sok erőforrás marad a szimulációra, de cserébe a grafikát a konzolos szint alá kell belőni
- túllépni a DX11 limitjeit, így a drivernek rengeteg magot adni, hogy egyáltalán optimálisan működjön, azaz hozható legyen a konzolos grafikai szint, cserébe a szimulációra nem lesz több erőforrásod, mint amennyi tíz éve rendelkezésre állt, sőt, lehet, hogy kevesebbel kell kalkulálni
- kidolgozni egy olyan rendszert a motorba, amely nem engedi a grafikus drivert működni, így sokkal optimálisabban lehet a hardver kihasználása és grafikai butítás nélkül is lehetőség lesz több erőforrást kinyerni a szimulációra, cserébe nem lesz stabil a program, illetve egy ilyen rendszert csak a leggazdagabb fejlesztők engedhetnek meg maguknak, mert extrém mértékű tesztelést igényel
És igen, az utolsó pontot fel lehet úgy fogni, hogy csak pénz kérdése a dolog, de valójában cseppet sem optimális az, hogy meghúzol egy határt, hogy mennyi potenciális fagyást tekintesz még elfogadhatónak. Hidd el pont annyira káros a PC-s játékosoknak, hogy DX11-ben 15% az esélye annak, hogy az új Dragon Age lefagy egy óra alatt, mintha lebutították volna a grafikát.[ 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
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
- Ventilátorok - Ház, CPU (borda, radiátor), VGA
- Ford topik
- Asszociációs játék. :)
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Cyberpunk 2077
- Huawei P40 Pro - kilökték a célegyenesben
- Szeged és környéke adok-veszek-beszélgetek
- Itt az új LOGOUT!
- Zseniális!
- Autós topik
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen