- Netfone
- Samsung Galaxy Z Fold4 - egyre megy, honnan nézed
- Milyen hagyományos (nem okos-) telefont vegyek?
- Vodafone mobilszolgáltatások
- Apple iPhone 11 - népalma
- Mobil flották
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Milyen okostelefont vegyek?
- Motorola Moto G24 Power - hol van az erő?
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
Hirdetés
-
Ülésezik a hardveregylet
ph Az irodai készülékek és monitorok társaságát egy ház, egy egér és egy DAC egészíti ki.
-
Robotkart irányított a majom a kínai Neuralink agyi chipjével
it A mindezt lehetővé tévő Neucybert a Neuralink kínai riválisa, a Beijing Xinzhida Neurotechnology fejlesztette ki.
-
Rövid előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
gp Továbbra is szeptemberi premierrel számolnak a fejlesztők, reméljük több halasztásra már nem kell számítanunk.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A Strange Brigade nagyon fontos alapja a tesztjeinknek, mert ez az egyetlen alkalmazás PC-n, ami valós idejű defragmentálással működő memóriamenedzsmentet használ, tehát egyedül ez az alkalmazás tudja meghajtani úgy istenigazából a GPU-kat, és a CPU-kra is elképesztően jól skálázódik. Emiatt van az, hogy a fogyasztás szempontjából a Strange Brigade húzza ki az összes CPU-n és GPU-n a legtöbbet a konnektorból. Egy másik játékon akár 20%-kal is kevesebb fogyasztást produkálnak a gépek, egyszerűen nem működnek annyira hatékonyan a hardverek, mint a Strange Brigade alatt, mert nincs annyira jól optimalizálva a motor alattuk. Emiatt van a Strange Brigade mérve a fogyasztásteszteknél.
Alapvetően igyekszünk minden játéknál figyelni arra, hogy optimalizált legyen, de a Strange Brigade egy másik kategória ebből a szempontból. Valószínűleg csak a következő nagy Asura motoros játékra lesz cserélve.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Pedig belemehetünk. Ami a lényege a jól skálázódó alkalmazásoknak, hogy ezeket mondjuk egy Celeron nem biztos, hogy jól tudja futtatni, mert egyszerűen nincs hozzá elég magja. De egy rosszul skálázódó alkalmazást biztosan jól futtat egy sok-sok magos processzor is, mert bőven van hozzá erőforrása, nem is használja ki a program. Ezért mindegy, hogy a nem jól skálázódó alkalmazásoknál mi a helyzet, mert már maga a motor van kényszerűen azért butítva, hogy kenyérpirítón is fusson. Fordítva, jól skálázódó motornál ez nem igaz. Ott szépen meg lehet fektetni egy kétmagost, vagy esetenként akár egy négymagost.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azt nem lehet lemérni. Az csak abban segít, hogy a motor igenis hajtsa a GPU-kat, ne legyen sok erőforrás-korlátozás a kódban, hogy a GPU a futószalagok futtatása között ne csak malmozzon, hanem igen sűrűn tényleges munkát végezzen. És persze ehhez etetni is kell a GPU-t, tehát a procinak is nagy szerepe van, hiszen biztosítani kell a folyamatos parancsgenerálást, mert ha a GPU biza nagyon zabálja ezeket a hatékony feldolgozás miatt, akkor a procinak is nagyon kapkodnia kell magát. De ettől amúgy az AMD és az Intel sincs másképp kezelve, csak nyilván ezeknek az explicit parancslistát generáló motorok például imádják a sok cache-t, mert ugye nagyon sok adattal dolgozik párhuzamosan egy job rendszerű motor. Nagyságrendekkel többel, mint mondjuk egy régebbi, parancsgenerálással alapvetően egyetlen egy feldolgozási szálat terhelő alkalmazás. Ez nyilván logikus. A kettő modellnek nem ugyanaz a terhelése a cache- és a memóriaalrendszerre. És a legtöbb tesztjáték hasonló, persze nem annyira jól optimalizált, mint a Strange Brigade, de azért az átlagnál jobbak. És itt van egy fontos tényező. Ezek a jól skálázódó játékok igénylik a jobb felépítésű, sokmagos processzorokat. Nem nagyon fognak teljesíteni kétmagos Celeronon például. Nem erre tervezték őket. De ezzel ellentétben egy öregebb feldolgozási modellt használó, a parancsgenerálással alapvetően egy szálra terhelő alkalmazás futni fog a kétmagos Celerontól kezdve a 64-magos Threadripperig. Pontosan azért, mert a terhelés egy szálra korlátozódik, tehát pusztán a motor kódja miatt nem tudod a rendszer teljesítményre skálázni. Ergo, amíg egy modern játék esetében baj, ha a magas órajelet előnyben részesíted a magas magszámhoz képest, addig egy elavult motornál ez nem baj, mert úgysem skálázódik az alkalmazás. Tehát amíg egy CS:GO mindenképpen nagyon jól fog futni akár egy 64-magos Threadripperen is, de a jó skálázhatóságra tervezett tesztjátékaink közül egyik sem fog jól futni egy kétmagos Celeronon például. Emiatt értelmetlen a CS:GO-hoz hasonló véglegeteket vizsgálni, mert gyakorlatilag akármelyik piacon kapható processzor jó oda. Nem is kell teszteket nézegetni, hogy hazavigyél valamilyen gépet hozzá, mert tuti, hogy az alapkonfigokkal is lesz vagy 100 fps-ed.
A másik tényező az, hogy ez egy teszt. Nyilván lehetne Super Mariót is futtatni, de nem nagyon feküdné meg a CPU-k és GPU-k gyomrát. 20 éve sem fektette meg, azóta csak gyorsabbak lettek a hardverek. Amire leginkább kíváncsi lehet egy olvasó, hogy a modern alkalmazások és körülmények hogyan hatnak a hardverekre. Persze fontos, hogy Facebookra is jó legyen, de őszintén szóval melyik processzor nem jó arra? Nyilván letesztelhetjük azt is, de effektíve 10/16 magot kínálnak a gyártók mainstreamben. Ezek között a különbséget csak skálázódó programokkal lehet megnézni. Miközben a nem skálázódó programokat úgyis futtatja mindegyik, lesz az egyes modellek között talán 10% különbség. Lásd az egyszálas adatok a CineBench tesztben:
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
CPT.Pirk
#314
üzenetére
Az AC Odyssey esetében nem ez a legnagyobb probléma. Hanem az, hogy az AMD azóta rágja a fülemet, hogy rakjuk be a CPU-tesztbe, amióta megjelent. Az Ubisoftot kérdeztem, hogy mi lehet az oka ennek, amikor a Vulkan portról érdeklődtem, és az volt a válasz, hogy az AMD sok assembly szintű optimalizálást rakott a játékba az újabb Ryzenekre a különböző patch-ekkel, míg az Intelre gyakorlatilag nincs semmi. Ezért rágják a fülemet ennyire, meg adtak ingyen kulcsot korábban, mivel már a programkód szintjén nem ugyanazt futtatják, amit az Intel processzorok. Na most ez így annyira nem tetszik nekünk, az pedig sajna ki van zárva, hogy ennyi idő távlatában az Intel is hasonló dolgokat csináljon. Szerintem már az Ubisoft sem patch-elné vissza.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
CPT.Pirk
#316
üzenetére
Persze, de nyilván nekünk is van annyi eszünk, hogy ezt észrevegyük. Nem véletlenül profilozom le a tesztjátékokat több konfigon. Ha valami furcsaságot látok, akkor ennyi.
Az meg őszintén szólva nem zavar, ha adnak a gyártók kulcsot a címekhez, ha ahhoz nincs direkt követelmény. Mailt írhatnak hetente, hogy "teszteljük már lécci". Az álláspontunk eléggé világos mindenki felé. Köszönettel elfogadjuk a kódokat, de semmit nem garantálunk, és semmi beleszólásuk nincs attól, hogy adnak tesztszoftvert. Ha úgy döntünk, hogy nem használjuk a játékot, akkor ennyi. Ez akkor is világos mindenkinek, amikor adják a kódot.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egyáltalán nem CPU-baszó a játék. Alig használ valójában CPU-időt. Amikor még megjelent, akkor megnéztem a VTune Profilerrel, és a rendelkezésre álló kapacitásnak nagyjából a 15%-át használta egy négymagos Core i7-en. Összehasonlításképpen a Strange Brigade ~60%-ot használ. Sokkal több áramot is zabál utóbbi játék alatt az a Core i7.
Az a százalék, amit kiírnak a különböző programok nagyon csalókák ám. Ott arra építenek a szoftverek, hogy mennyi ideig fut az egyes szálakon az oprendszer üresjárati folyamata, és annak az inverzét veszik terhelésnek. De az Intel szinte mindegyik VTune előadásban elmondja, hogy ez még nem jelenti azt, hogy a processzor dolgozik is. Csak annyit jelent, hogy az OS/program(ok) valamiért nem tud semmilyen munkát kiosztani a szálaknak. Ez lehet attól, mert a hardveres szál tényleg dolgozik, és attól is, hogy valamilyen erőforrás-korlátozás miatt nem csinálhat semmit. Az AC Odyssey esetében pont az utóbbi áll fent. A grafikus kernel meghajtók szerver szálai korlátozzák az erőforráshoz való hozzáférést, így a processzorra például az Afterburner hiába jelez szálanként 60-80%-ot, a valóság inkább 15% esetenként. Csak ezt ugye az operációs rendszer nem tudja megmondani, mert az oprendszer üresjárati folyamata jóval egyszerűbb metódust használ a terhelés mérésére, mint egy teljesítményszámlálós profilozó. És emiatt sokszor teljesen az ellentét mutatja a valóságnak.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A gyorsabb CPU-tól ez nem javul, mert a szoftveres gond, ami limitálja a feldolgozást nem szűnik meg. Pont ezért nem tud skálázódni az AC Odyssey, pedig vannak a tipikus négymagosoknál sokkal, de tényleg sokkal gyorsabb processzorok is. Innentől kezdve mindegy, hogy aláraksz-e 64 magot mondjuk, mert a programkódban lévő limit megfogja, akármelyik bitangerős processzort. Még a Threadrippereket is, pedig azok teljesen más kategóriák a teljesítményt tekintve.
Ezekre a régi programkódokra nem éri meg processzort fejleszteni. Egy erős négymagosról mondjuk 8-12 magra lépsz, és nyersz maximum +5%-ot. Eközben a fejlesztésbe fektetett pénz nagyságrendekkel több. Azt a +5%-ot hozod tuninggal, és ha megnézed a mai nagyfrekis procik fogyasztását, akkor még tuning mellett is kevesebbet vesz ki a konnektorból a régi dizájn.(#327) Cassi: Kérdés, hogy mire veszik a pénzt és fáradtságot. Ha mondjuk ugyanazt a pénzt befektették volna az explicit API-ra, akkor nemcsak az AMD procik jártak volna vele sokkal jobban, hanem az Intelek is. Tehát nem mindegy, hogy mibe rakod az erőforrást. Emiatt hülyeség egy elavult motor kritikus részeit assembly szinten optimalizálni. Olcsóbban kijön az explicit API-ra való átállás, és nagyságrendekkel többet nyersz sebességben. Most az, hogy az AMD nem ebbe rakta a pénzt, hanem másba, az a saját hülyeségük. Legközelebb majd gondolkodnak mielőtt cselekszenek, és akkor nem kell talán kérni sem, hogy teszteljük az applikációt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Régebben mértem, amikor még jöttek hozzá a patch-ek, de egy ideje már ráhagytam, mert átálltunk az explicit API-ra. Az AMD és az Intel is kiemelten ezeket az API-kat használó játékokat javasolja, hogy skálázódni tudjanak a sokmagos processzoraik.
(#330) rumkola: Az explicit API-kat máshol low-level API-knak írják. Mi azért hívjuk explicit API-knak mert valójában a low-level leginkább csak a Mantle-re volt jellemző, illetve a konzolos alacsony szintű hozzáférések tartoznak még ide. A DirectX 12 és a Vulkan nem kifejezetten low-level. Alacsonyabb szintű, mint a régi API-k, de nem annyira, mint a konzolos API-k, illetve a Mantle volt. Emiatt hivatkoznak ezekre maguk a fejlesztők is explicit API-kként, mert tulajdonképpen arról van szó, hogy a korábbinál lényegesen több kontrollt tesznek lehetővé. Ezeket low-levelnek hívni nem célszerű tehát, mert valójában nem igazán low-level hozzáférések, csak a korábban megszokott jelentős korlátoktól mentesek, de ugyanakkor messze nem adnak akkora szabadságot, mint mondjuk a PS4-en a GNM, az Xbox-on a Mono hozzáférés, vagy az AMD házi API-jának tekinthető Mantle. Itt azért megjegyzem, hogy az utóbbi három megoldás extra képességeire PC-n nincs is igazán szükség. Amíg például rohadtul megnehezítette az életet a deferred context, tehát célszerű volt ettől megszabadulni a PC-n a DirectX 12 és a Vulkan esetében is, addig különösebb bajt nem okoz, hogy egyik szabványos explicit API-ban sincs meg a Mantle végletekig általánosított erőforrás-kezelése, vagy a konfigurálható futószalagja. Sebességben előny lenne mindkettő, de messze nem akkora, hogy ne tudjunk élni nélkülük. Sőt, a konfigurálható futószalag konkrétan nehezíti a programozhatóságot, bár nyilván sebességet hozott, de bőven jó az a futószalag, ami most van. A szabványos explicit API-k tehát kicsit átgondoltabbak már. Nem vállaltak szükségtelen reformokat, hanem csak a velős problémákra koncentráltak.
A chiplet pedig nehezen kerülhető szó, hiszen több processzor is chiplet dizájnt használ a piacon.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#00137984
#344
üzenetére
Az Unreal Engine 5 is futhat PC-n, és nem a grafikus API-kkal van most gond, ezek jók a motorra. A baj, hogy hiába raksz a PC-be SSD-t, attól még nem lesz semmilyen API-d, ami támogatna hierarchikus lapozással működő gyorsítótárazást az SSD-ről a VRAM-ba. Enélkül pedig a Nanite modul nem üzemképes, csak az Unreal Engine 5 többi része. Viszont Nanite nélkül a lényeges is elveszik a motornak.
Ilyen megoldás egyébként a Microsoft-féle DirectStorage API az SFS-sel. De mindkettő csak Xbox Series X-re érhető el. A DirectStorage nem jön egyelőre PC-ben, az SFS-nek pedig egy eléggé butított, streaming nélküli verziója van benne a DirectX 12 Ultimate-ben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Az meg őszintén szólva nem zavar, ha adnak a gyártók kulcsot a címekhez, ha ahhoz nincs direkt követelmény. Mailt írhatnak hetente, hogy "teszteljük már lécci". Az álláspontunk eléggé világos mindenki felé. Köszönettel elfogadjuk a kódokat, de semmit nem garantálunk, és semmi beleszólásuk nincs attól, hogy adnak tesztszoftvert. Ha úgy döntünk, hogy nem használjuk a játékot, akkor ennyi. Ez akkor is világos mindenkinek, amikor adják a kódot.
Új hozzászólás Aktív témák
ph Az AMD Ryzen 3 3100 és 3300X processzor most megmutatja!
