- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
ph A Kereskedelmi Minisztérium egyelőre csak felméri a helyzetet, egyelőre nem látni, hogy tudnak-e bármit is tenni.
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
-
Xbox Game Pass [2024] - A májusi lista
gp Az elkövetkező időszakban többek között megkapjuk a Kona II Brume című játékot.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Az Intelnek is van 18 magig skálázódó asztali processzora. Nem értem, hogy miért keverjük ide az AMD-t mindig, amikor már házon belül is vannak jobban skálázódó CPU-k, amelyek előnyt adnak, ha éppen nincs szabad erőforrás egy explicit párhuzamosan számolt batchnek.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mint írtam, attól függ, hogy miképp van megírva a játék. Az explicit API-n már előnyt jelent a több erőforrás, mert annyira szét tudja osztani, ahány szál van. Ez a lényege a DirectX 12 és a Vulkan API-nak. És itt egy fejlesztő már nem az átlag fps-t nézi, azt lényegében a VGA határozza meg, hanem az a szempont, hogy az erőforrások lefoglalása mennyire okoz apró akadásokat. Ezeket a presentek közötti idő mérésével nem is lehet látni. Viszont érzékelhetők, és például egy performance counterek alapján történő monitorozás során láthatóvá is vállnak, hogy hol fut bele a program olyan szituációba, ahol elfogy az erőforrás, és kénytelen várni a folyamat, amíg egy szál felszabadul.
Hasonló dolog ez az AFR több GPU-s rendszerekhez, ahol igazából mérni nagyon nehéz a képkockák szinkronizálását, mert a presentek közötti idő kimérése, ahogy a legtöbb FPS-t mérő program működik, nem mutat meg mindent. Viszont érezni érezhetted, hogy nincs minden rendben, csak nem lehetett egyszerűen kimérni. Ha olyan egyszerű lenne ez, akkor nem készítenének ennyire sok magggal rendelkező processzorokat, de ma már jóval kedvezőbb a játékoknál a helyzet. A legtöbb mai motor simán skálázódik 40 szálig explicit API-val, a Nitrous AotS-be beépített aktuális verziója 104 szálig is, de van egy developer verzió a Steamen, aminél 136 szál a maximum, csak azt nem ajánlják játszani, mert vannak vele stabilitási problémák. Szóval egyáltalán nem véletlen, hogy ennyire nő a magok száma, az Intel is hozza jövőre a 10 magos mainstreamet, de már készül egy 12 magos 14 nm-es gaming lapka is, ami eddig nem volt benne az útitervben. Nyilván az id tech 7 sok dolgot meghatározhat, mert jelenleg az 70+ szálig skálázódik, és nagyon hasonló feldolgozási modellt használ, mint a Nitrous, tehát később akár ugyanúgy elérhetik ők is a 100 szálat. Ezt mind az teszi lehetővé, hogy az explicit API-k parancsátadása explicit párhuzamos, illetve nincs a drivernek kernel szerver szála, ami zavarná a feldolgozást.Amit egyébként még nagyon sokan rosszul értelmeznek az a processzor leterheltsége. A Windows erre vonatkozó adatja rendkívül félrevezető, mert csupán azt méri az operációs rendszer, hogy az idle szál a rendelkezésre álló erőforrásokon, egységnyi szinten mennyi ideig fut. De ez nem jelenti automatikusan azt, hogy a processzor akkor is le van terhelve, amikor az idle szál nem fut! Ezt a Windows, illetve a százalékos adatokat közlő programok nem tudják megmutatni, mert lényegében az idle szálig van erre rálátásuk. Ahhoz, hogy lásd mi történik a hardverben már performance counterek alapján kell vizsgálni az alkalmazást. És ott bizony sokszor kiderül, hogy hiába jelez a Windows 99%-ot a processzor terheltségére, a valós munkafolyamat pusztán a processzoridő 30-40%-át teszi ki. És ez az a tényező, amivel a régi API-k nem tudtak mit kezdeni, mert a driver kernel szála összeütközött a program munkafolyamataival, és gyakorlatilag egymást akadályozták. Bárhogy is optimalizáltad az alkalmazást, akármennyi magod volt, nem igazán tudtál egy bizonyos százalékos leterheltség fölé kerülni. Láttad a profilozóban, hogy a processzoridő teszem azt 80%-a szabad, de nem tudtad, hogy mit csinálja ahhoz, hogy befogd. És ez nem igazán az átlagos sebességet rontotta, mert ha szimplán mérték egy presentek közötti időkülönbséget, akkor alapvetően azt kaptad, hogy nagyjából minden szuper, kaptál egy jó magas fps-t, de érzésre mégsem volt mindig reszponzív. Az explicit API-k alapvetően erre a problémára reagálnak, és szándékosan tüntették el a driver kernel szálát, mert gyakorlatilag az volt a probléma. Innentől kezdve ha látod, hogy a processzoridő 80%-a szabad, akkor lehet úgy optimalizálni, hogy azt az erőforrást befogd. Persze nem feltétlenül egyszerű, de legalább nem lehetetlen, mint korábban. Emellett az API-k működése arra épül, hogy a parancsátadás explicit párhuzamos, ez a fő oka annak, amiért annyira jól optimalizálható a működés, tehát lehet, hogy fps-ben, pusztán a presentek közötti méréssel nem látsz előnyt, de minél több processzoridőd van, annál reszponzívabb lesz a program, mert annál több szabad erőforrás van a feldolgozásra, és annál kevesebbet kell egymásra várni a folyamatoknak. És emiatt skálázódnak a mai motorok, explicit API-n futó motorok 30-40 szálig, mert fps-ben ugyan ennek nincs igazán mérhető hatása, de reszponzivításban megérezhető. Ha nem lenne az, akkor nem törődnének vele a fejlesztők, mert bele kell fektetni a programozói erőforrás, de alapvetően megéri, mert ha úgy érzed, hogy a kijelzett fps ellenére nincs minden rendben, akkor veszel egy több maggal rendelkező processzort, és arra a program automatikusan skálázódik, és reszponzívabb lesz. A régi API-kkal ezt nem lehet megcsinálni, ott egyszerűen ha négy magnál úgy érzed, hogy az fps ellenére rossz az élmény, akkor annak annyi, nincs mit tenni a hardver oldalán. Hiába veszel nyolcmagost, akkor sem fog változni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
ph A Core i9-9900KS limitált mennyiségben készül, így sietni kell, ha valaki szeretne magának egy példányt.
