Új hozzászólás Aktív témák
-
PuMbA
titán
Mármint nem a GDK-ba, hanem hogy hozzá lehet toldani a DLSS kódját kézzel, megkötések nélkül. A Bethesda-nak meg egy nagy pacsi jár tőlem, hogy hallgatnak a játékosokra
Ezek szerint nem csak pénz számít nekik, amit a DLSS implementációjának kihagyásával megspóroltak volna.
-
PuMbA
titán
Starfield to get DLSS, FOV Slider, Ultrawide Support Promises Bethesda, First Hotfix Out Now
Annyian akarnak DLSS-t és töltötték le a mod-ot, hogy a Bethesda belátta, amit kell és egy javításban hivatalosan is beleteszik
Nagyon nem gondolták át a helyzetet.... 90%-os az NVIDIA részesedése PC-n és majd DLSS nélkül megússzák? Hát nem. Ezt én is megmondtam volna nekik ingyen, nem kellett volna tökfej menedzsereket fizetniük
Abu ezek szerint az Xbox GDK-ba bele lehet hegeszteni a DLSS-t
-
Abu85
HÁZIGAZDA
Az SMT-szerű megoldások alapvetően úgy működnek, hogy a mag egyes részei valamilyen módon fel vannak osztva. Erre több megoldás van, de alapvetően egy részegység vagy teljesen megosztott vagy particionált. A teljesen megosztott között is vannak különbségek, hogy miképpen kezelheti a megosztást maga a hardveres szál. Az AMD-nek az SMT-je annyiban eléggé más az Intel HT-től, hogy a parancslisták a magon belül statikusan particionáltak, míg az Intel komplett strukturált megosztást használ ezekre. És ez okozza azt, hogy az Intel HT-je bizonyos helyzetekben nem hoz sebességnövekedést, mert a parancslista közös a két hardveres szálon, holott bizonyos feladatok jobban elvannak statikusan particionált hardverrel.
A jó hír, hogy erre lehet direkten optimalizálni, tehát ez nem egy olyan dolog, amibe bele kellene törődni, az Intelnek vannak arra különböző stratégiái, hogy miképpen lehet elkerülni azokat a helyzeteket, amikor a HT rontja a sebességet. Az más kérdés, hogy ezt mennyire egyszerű implementálni egy adott programba, de nem lehetetlen.
-
consono
nagyúr
Egy kis olvasnivaló a Redditről Abu magyarázata mellé a VKD3D-s fejlesztő pull requestjének a teljes félreértéséről: [Starfield doesnt have major programming faults]
-
PuMbA
titán
Az AMD SMT mivel másabb az Intel HT-jénél? Ugyanis a DigitalFoundry-sok kitesztelték, hogy az AMD SMT nem csökkenti, hanem még hoz is valamennyi teljesítményt, az Intel procikkal ellentétben. Tehát míg Intelen ajánlott a HT-t kikapcsolni Starfield-hez, addig AMD-n nem kell az SMT-t kikapcsolni.
-
Abu85
HÁZIGAZDA
Az AMD rendszereknek nincs olyan limitje, ami megfogja a többi hardveren a Starfieldet. Az ilyen előfordul, mert vannak játékok, amelyek tipikusan érintenek architekturális limiteket. A GeFroce-okét a Starfield érinti. A Portal RTX például a Radeon limitjeit érinti. Ilyen oda-vissza előfordul.
A HT csak több hardveres szál ugyanarra az erőforrásra. Nincs a szálak mögött valós erőforrás, így nem mindig működik jól. Már az elején írtam, hogy a Starfieldre valós magok az optimálisak.
-
-
adr0001
aktív tag
A legfrissebb nV driver megszűntette a bekapcsolt vsync mellett jelenlévô frametime rollercoastert.
-
copass
veterán
végre kijött a digital foundry pc elemzés [link]
fsr ghosting... -
Abu85
HÁZIGAZDA
Uhhh. A kezdőhozzászólás az kemény lett...
Kezdjük ott, hogy az ExecuteIndirect nem akar hintet az alkalmazástól. Egy pointerre van szüksége, ami egy pufferre mutat, ami tartalmazza a szükséges adatokat a rajzoláshoz. Ez a lényege a technikának, és ez nem hiba, hanem fícsőr, azért működik jól, mert koncepcióból így működik.
Ráadásul a legtöbb esetben az ExecuteIndirect nem batch-elhető. Ritkán talán, de az esetek nagy többségében nem az, így teljesen normális, hogy a program úgy hívja meg őket, ahogy a Starfield.Az a baj, hogy ez a leírás egy csomó marhaságot tartalmaz, és nem azt írja, amit a Github linkek. Tökre félre van értelmezve, amit a hack csinál. A workaround arról szól, hogy a RADV, vagyis az openszósz Radeon Vulkan driver implementálta az NV_device_generated_commands_compute kiterjesztést, és ezzel lehet írni egy olyan hacket, ami a működést work graphs-hoz hasonló jellegűvé teszi. De ettől maga az ExecuteIndirect implementáció nem rossz, csak át van alakítva olyanra, hogy még hatékonyabb legyen. Ezt a Bethesda azért nem tudja megtenni, mert a work graphs még nem elérhető a DirectX 12-ben. Idén elérhető lesz, de még nem az.
És eleve azért jön a work graphs, mert az ExecuteIndirect esetenként nem használható hatékonyan. Például most sem. Ha nem lenne ezzel baj, akkor work graphs sem kellene, és nem fejlesztette volna le a Microsoft. De tényleg nem tud mit tenni azzal egy cég, hogy még nem része magának az API-nak. Előbb a részévé kell tenni, és utána lehet használni. Valószínűleg ezen már dolgoznak is.
Maga a workaround, amiről szó van, működhet RADV meghajtóval, és arra engedélyezve is van, de az AMD biztos, hogy nem fogja támogatni gyári szinten, az NV meghajtója pedig bugzik az implementációval, így arra ez le van tiltva. És nem valószínű, hogy az NV ezt javítani fogja, mert a gyártóknak az efféle erőszakos hackek nem fognak tetszeni. Ők nem azért építik be ezeket az új lehetőségeket, hogy kívülről hackelj rá valami nehezen tesztelhető, esetenként random fagyó működést, mert az ő supportjuk lesz ettől leterhelve. Ők azt akarják, hogy a programnak natív, jól debugolható implementációja legyen. Kb. úgy vannak ezzel, hogy ha az ExecuteIndirecthez hasonló koncepció nem túl optimális a rendszerhez, akkor használj work graphs-hoz hasonló koncepciót. Nem az a cél, hogy köztes rétegek hackeljék szarrá a rendszert, tessék megírni natívan. Persze nyilván a közösség az más, ők uralják a protont, a RADV-t, szóval összerakják maguknak, de gyártói zárt driver szintjén ennek biztos nem lesz támogatása. És ennek az oka, hogy a közösségi support sokszor annyi, hogy széttárják a kezüket egy problémánál, hogy ez van, mint most ugye ennél a hacknél, amit csak RADV-re engedélyeztek, mert NV zárt driverrel instabil, és nem tudnak mit tenni, mert a RADV-vel ellentétben nem uralják a forráskódot. A gyártói support nem tudja széttárni a kezét, mert te vetted a hadvert, és fizettél azért, hogy stabilan működjön. Emiatt a gyártónak felelőssége is van abban, hogy ne széthackelt megoldásokat kínáljon neked.
-
PuMbA
titán
-
ebből pontosan az látszik, hogy alapvetően konzolra készült, minden más nem volt fontos, és lehet, hogy feladatonként határozták meg, melyik mag mit csináljon. Elég elavult egy módszer, PS3-on láttam utoljára ilyen megoldást, ott volt nagy hiszti, mikor a GTA-t portolták PC-re, és ezt nem igazították hozzá. Majd a fejlesztők most nekiállnak püfölni, hogy rendesen skálázódjon.
-
PuMbA
titán
Ennyi teszt alapján már tisztán látszik, hogy a játék CPU skálázódása egy közepes szint
A Cyberpunk skálázódása ehhez képest mestermunka, mert minimum kétszer akkora sebesség növekedést ér ugyanazokkal a plusz erőforrásokkal:
-
wjbhbdux
veterán
AMD nem akadályoz -
Abu85
HÁZIGAZDA
Jelenleg az optimális parancsátadásra az ExecuteIndirect van használatban, ami ugyan jó, de az olyan típusú játékoknál, mint például a Starfield megvannak a limitációi. Ezt a rendszert nagyjából 10 éve adták ki a 10 évvel korábbi problémákhoz. A Microsoft a háttérben már kidolgozott egy jobb alternatívát, ami GPU Work Graphs néven jön. Azért csak jön, mert egyelőre nem végleges a specifikáció, de az új Windows 10 és 11 frissítésben az lesz.
Ez a GPU Work Graphs annyiban előnyösebb az ExecuteIndirectnél, hogy a GPU képes magának úgy compute munkafolyamatot kiosztani, hogy ehhez nem használ CPU-időt. Egyszerűen saját magát eteti meg az asszinkron módba besorolt paranccsal. Tehát azt a limitet, ami az ExecuteIndirectet a mai játékoknál limitálja, kiszűri, mert maga a szoftver fog jobban működni, bizonyos dolgokhoz nem lesz szüksége a CPU-ra, így nem is terheli majd azt.
-
paprobert
őstag
válasz
Dragon3000 #246 üzenetére
Egy szálas, architektúrafüggő limitnek néz ki.
Én egyébként már az elmúlt 1-2-3 évben vártam volna ilyen jellegű játékot. Olyan motort, amit futtatva a Zen2-k teljesítménye 30-40 fps környékére esik.
A Starfield majdnem hozza ezt, de őszintén, vártam is volna valami látható szintlépést a hardverkövetelmények növekedéséért cserébe... Egyszerűen nem értem, mire ment el az erőforrás.
-
Raysen623
addikt
Én ezt ennyire nem érzem összeesküvés elméletnek konkrét bizonyíték nélkül. Inkább azt látom, hogy volt egy ajánlás AMD részéről, amire a jó Bethesda csinált valamit, végül az AMD meg elengedte, mondván jóvanazúgyis. Tehát az éppen vállalható kategóriába került így a játék, aztán mehet a javítás ezerrel ha jót akarnak maguknak.
-
Abu85
HÁZIGAZDA
Az RDNA 2 nem szünteti meg a procilimitet, csak annak a meghajtója nem rak akkora többletterhelést rá, mint más D3D12 implementációk. De ettől maga a játék még terheli a procit, hiszen egy rakás dekódolási folyamat van.
Ezzel nehéz mit csinálni úgy, hogy a GPU nem tudja etetni saját magát. Erre kell az új DirectX 12 verzió, hogy megoldják, de akár a DirectStorage is bevethető még, hogy a dekódolási munka csökkenjen. Az más kérdés, hogy úgy meg a GPU-ra kerül a dekódolás, ami meg szintén nem a legjobb, mert jelentősen növeli majd a VRAM terhelését.
-
adr0001
aktív tag
válasz
SindaNarmo #238 üzenetére
Nálam is 5700X, Lucky Golden Sample. Ha elengedem 130W-ig akkor 4750-ig boostol all core anélkül hogy magára olvasztaná az IHS-t. Per pill nincs bajom nekem sem a játékkal, mert mediumban megy 60 fps-t fixen a legszopatósabb helyeken is. Csak amikor kíváncsi lettem hogy a következő VGA vásárlásom után megengedhetek-e majd magasabb részletességet, na akkor lettem szomorú. Ultra-n, mind RDNA2-n, mind Ampere-n <= 50 fps, mindezt 16x9-es felbontásban... A CPU meg 35-50%-on malmozik.
Na de addig is megyek inkább játszani. Meg tűkön ülve várni az FSR3 update-t.
(már ha lesz)
-
PuMbA
titán
válasz
Busterftw #241 üzenetére
Ja
Az a jó, hogy a nagy tesztoldalak közül például a Hardware Unboxed is jól megmondta, hogy ez borzalmas munka, szóval reméljük, hogy a fejlesztőkhöz eljut ez és javítják. Szerencse, hogy ez a játék engem épp nem érdekel, de azt nem lehet ölbe tett kézzel nézni, hogy az AMD ráveszi az embereket CPU vásárlásra mondva csinált okokkal.
A Bethesda-ról sose voltam jó véleménnyel, de legalább megint bebizonyították. A kiváló fejlesztők továbbra is az Insomniac Games, a Naughty Dog, a Turn 10, a Rockstar Games és a Codemasters. Ezen cégek játékait várom mindig.
-
-
SindaNarmo
tag
Én meg pont írni akartam, hogy eddig "megvagyok elégedve" a teljesítményével, már a tesztekhez viszonyítva. Igaz településre még nem mentem be. Sokkal rosszabbra számítottam
A kezdeti állomás/bolygókon 40-50fps 1080p medium fsr nélkül. De majd még finomítanom kell a beállításokat, de reggel nem értem rá.Azt sajnálom hogy nem lehet játékon belül 30fps-re fixálni, vagy legalább is nem találtam meg.
Ryzen 5700x, RX6600
-
adr0001
aktív tag
válasz
SindaNarmo #230 üzenetére
Amit nem láttam a tesztekben az az hogy milyen CPU használat mellett tolják ki azokat az fps-eket. Itt 8/16 Zen3, hlyszín a játékban ahol a GPU 80%-on. SMT-t letiltom, nem lassul. Még 2 mag minusz, nem lassul. Ami biztos az az, hogy semmi köze a magszámhoz, meg hogy RDNA-n is megnézve eltűnnek a frametime spike-ok.
Egy rohadt nagy gány az egész.
-
ez jó tanulság lesz az AMD-nek, hogy mit csesztek el
-
SindaNarmo
tag
Én nem értékelem ennyire vészesnek a helyzetet, mert ez elégé egy mesterséges kombináció (értsd a bármelyik proci + 4090 és csak 1080p-n használod). Valószínűleg magasabb felbontáson közelebb vannak egymáshoz. Gyengébb kártyákról nem beszélve.
Ettől függetlenül a különbség meg van, bár ez csak 1 játék.
Aztán ha több ilyen követi egymást akkor már problémás lehet. -
PuMbA
titán
válasz
SindaNarmo #232 üzenetére
Hogy érted? Ez a játék a Zen 3 CPU-kat nevetségessé teszi. Nekem ez az alátámasztó indokom.
-
PuMbA
titán
válasz
SindaNarmo #230 üzenetére
Igazából mindegy, a lényeg, hogy ha az AMD vagy az NVIDIA keze nagyban benne van egy játékban, akkor abból csak egy optimalizációs szerencsétlenség lesz, mert vagy az egyik vagy a másik oldal szívni fog.
-
SindaNarmo
tag
Csak a korrektség kedvéért 7xxx-es processzorokat említi.
Amúgy ja, tényleg érdekes. mi lenne ha nem csinálták volna?Főleg az a furcsa hogy pl 7900 és a 7950 nem tud a sok magból profitálni. Olyan mintha a max a 8 mag lenne, ami pl a konzolokat nézve még logikus is lenne. Ebből a szempontból lenne érdekes hogy az intelnél csak Hz különbség miatt megy feljebb (generáción belül) vagy közrejátszanak a magok is.
-
PuMbA
titán
válasz
SindaNarmo #228 üzenetére
CPU is, hiszen említik, hogy "highly-multithreaded code":
AMD is Starfield’s Exclusive PC Partner
Annyira multi-thread, hogy egy 6 éves 6 magos Intel veri a 3 éves 16 magos 5950X-üket
Ez eddig az év csúcspontja számomra,, hogy hogy lehet ekkorát kamuzni.
-
SindaNarmo
tag
Azt akkor tudnánk meg igazán ha kb a 13900k, 13700k, 13600k valami alacsonyabb fix frekire hogy csak a mag különbség jöjjön ki közöttük, és akkor kiderülne hogy skálázódik-e vagy sem.
Az tényleg érdekes hogy nem a legjobban teljesítenek és kb csak a x3d tudják tartani magukat (kivéve 7950X3D bár itt gondolom az ütemezővel lehet továbbra is gond)
Már miben van benne a kezük? a VRAM management volt említve nem? -
PuMbA
titán
Most már csak az a kérdés, hogy a 16 magos procik mit számolnak azon a sok magon úgy, hogy közben nem lesz gyorsabb a játék. Partnerséget kötöttek a NASA-val, hogy a kutatási számításokba beszállnak a játékosok?
Azért látszik, hogy ez a játék nem egy optimalizációs csoda. Nem lesz belőle példa, hiába van benne az AMD keze munkája.
-
PuMbA
titán
válasz
SindaNarmo #225 üzenetére
"I really didn’t think I’d ever see the 8700K beat the 5950X on a benchmark chart for a newly released game."
Jó teszt. AMD CPU-k már többedjére a földbe vannak álva és tényleg az a furcsa, hogy ez egy konzolra írt játék, amiben AMD van. Semmit nem ér a több mag, ez a játék nem skálázódik jól. Itt belső, mély architektúrális dolgok számítanak, hiszen 4 maggal is 60 fps fölött vagy átlagban.
-
SindaNarmo
tag
Ja az érdekes.
Mondjuk rá biztos van valahol olyan teszt is, de pl itt megnéztem volna hogy pl 7xxx-es processzor hogy reagál a DDR5 memória különbségekre.
Illetve pont az intelnél ki lehetett volna próbálni hogy ugyan az proci/videokártyánál mi a különbség DDR4 vs DDR5 tekintettben.
Bár gondolom ehhez már végtelen időmennyiség kellene. -
PuMbA
titán
válasz
SindaNarmo #222 üzenetére
Viszont az is érdekes, hogy DDR5-6000 felett meg már nincs különbség. Ha ilyenek lesznek az új játékok, akkor lehet az AMD procikat Intelre cserélni
Én még nem váltottam DDR5-re, elnézegetem a fejleményeket.
-
PuMbA
titán
Starfield CPU Benchmarks & Bottlenecks: Intel vs. AMD Comparison
A 4 magos i3-13100F gyorsabb a 3x nagyobb L3 cache-sel és 2-vel több maggal rendelkező Ryzen 5600X-nél. DDR5?
-
Abu85
HÁZIGAZDA
Ez egy döntés eredménye. Túl sokat számol a szimuláció. Egyébként ez nem jelenti, hogy nem tudnak sebességet nyerni. Például lehetne támogatni később a GPU Work Graphs funkciót, ami valamikor október felé érkezik. Lehetne támogatni az FSR3-at, az Xboxra is jó. A DirectStorage is segíthetne, bár valószínűleg nem masszívan.
Szóval van hova lépni, csak ezek mind nagyobb változások, amelyeket időbe telik beépíteni.
-
Abu85
HÁZIGAZDA
A probléma forrása ott van, hogy a játékot egyáltalán nem tervezték az előző genre, így az igényeknél a minimumnak az Xbox Series konzolcsaládot vették. Emiatt a terhelést is ehhez igazították, a szimuláció komplexitását ehhez paraméterezték. Ezért a nagy igény. Egyre több játék fogja ezt elérni, ahol a last genre már prototype szintjén se terveznek. Ezért növekednek a gépigények idén, és ez még nem a vége ennek.
-
paprobert
őstag
Buildzoid azt elemezte, hogy CPU-memóriasávszélesség benchmarkként működik a Starfield.
Hátrányba hozva a Zeneket az Infinity Fabric bottleneck miatt, és előnybe hozva az Intelt a valamivel jobb memóriavezérlő + magasabb RAM frekvencia miatt.Ez csak akkor lehetséges, ha a Starfield memóriamenedzsmentje a konzolokban adott 230-500+ GB/s-ra lett rátervezve, ami PC-n nem elérhető, és nem is lesz túl hamar.
Szerk.
Én amúgy egyáltalán nem látom, hogy értelmesen lett elköltve a négyszeres CPU erő az új konzolokban a Starfield esetén. Pedig érdeklődve vizsgálom, mert az XB360 óta ez az első nagy ugrás, a játékmenet viszont last-gen szintnek néz ki, vagyis indokolatlan. -
adr0001
aktív tag
Értem Kikapcsoltam a VSync-et, custom beállítás van stabil 60 fps/VSync-re, többségében medium. Nos, 64 fps-nél volt a vége a minimumnak
, és onnan ahol volt lemehetek a végtelenségig felbontásban, ennél jobb nem lesz.
Most akkor átrakom az RDNA2 kártyát a gépbe, megnézem azt is, köbgyök SD felbontásban, ugyanott.
-
podtibi
senior tag
És az nem gyanús neked hogy ez a játék mindennél jobban igényli a processzort? Értem hogy megmagyarázható az oka, de attól még ott marad a kérdés. Hogy van az hogy hirtelen egy játéknak mindennél jobban kell igényelnie a processzort? Nem azért mert úgy csinálták ahogy? Tehát akármi is az oka, a végeredmény nem jó. Javíts ki ha tévedek.
-
-
adr0001
aktív tag
Nem értem a vinnyogást az FSR-re. Van annyira korrekt ez esetben hogy egyemesen sajnálom az időt a DLSS beletákolására, úgy is maradt.
nV-n egy 20-30%-ot még tudnak tolni majd a játékon driverből. Legalábbis wattban ennyi simán bent marad a kártyákban átlagosan, 100% használat mellett.És hát azért Portal RTX-et kiáltani meredek lenne. Ha van is benne másik oldal szopatása, annyira arcpirító mint az, sem ez sem más semmi nem lehet lol
-
Abu85
HÁZIGAZDA
Az eső és a fizika effektek. Leginkább compute shaderekkel oldják meg, mert úgy olcsók, így a CPU-t nem igazán terhelik. Ami itt a legdurvább terhelést kifejtheti azok az assettek kitömörítése. Ezekre ugye a CPU-magok vannak használva, és ez a kikódolási folyamat eléggé megterhelő. Ezt döntően meghatározza az is, hogy meddig van szimulálva a világ. A Starfield nehézsége, hogy van egy rakás nyílt terep, és pár népes város. Nem tudod úgy beállítani, hogy mindkettőre jó legyen, így választanak valami középutat. És itt gond az is, hogy a városok nem annyira komplexek, mint például a Cyberpunk 2077-ben, ahol el lehet fedni a szimulációt a sűrű sikátorokkal. Itt nincs sok ilyen, tehát nem lehet vele trükközni, muszáj kellően nagy távolságra szimulálni a világot. Ezek zabálják a CPU-t, nem a esőcsepp meg a fizika.
És a menedzsment szempontjából nagyon lényeges, hogy az egész játék a moddingot figyelembe véve van írva. Ez mindig áldozattal jár, mert a memóriamenedzsmentet kellően általánosra kell tervezni, hogy bármilyen modot befogadjon a rendszer.
Az általános menedzsmentek nagyon jók akkor, ha rugalmas moddolhatóságot akarsz kínálni, de mivel pont a rugalmasságra készültek, így nem a leggyorsabbak. Lehetne ezek helyet gyors alternatívákat kínálni, cserébe nagyon nehezen lesz moddolható a játék. A kettő együtt nem megy, vagy az egyik, vagy a másik. Valószínű, hogy a Bethesda már tudatosan tervez a moddolhatóságra, mert sokáig életben tartják majd a terméket a felhasználók.
Új hozzászólás Aktív témák
- Battlefield 6
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Milyen légkondit a lakásba?
- Kerékpárosok, bringások ide!
- Samsung Galaxy S23 Ultra - non plus ultra
- A lemondást javasolja az Intel vezetőjének Donald Trump
- World of Tanks - MMO
- Gaming notebook topik
- Szünetmentes tápegységek (UPS)
- Milyen routert?
- További aktív témák...
- Prémium gépház most fantasztikus áron!
- Lenovo ThinkPad X1 Yoga (6th Gen) - i7-1185G7, 32GB, 512GB SSD, multitouch + TOLL
- Motorola E40 64GB, Kártyafüggetlen, 1 Év Garanciával
- Geforce GTX 1050, 1050 Ti, 1060, 1650, 1660 - GT 1030 - Low profile is (LP)
- iKing.hu - Samsung Galaxy Z Flip 7 Blue Shadow Újszerű, karcmentes állapotban 512 GB
Állásajánlatok
Cég: FOTC
Város: Budapest