Hirdetés
- Eldugott helyek Párizsban, amiket jó eséllyel még nem láttál...
- Samsung Deskmaster 386s/20n
- Keychron K1 V6 Bluetooth/USB-C magyar low profile mechanikus gamer billentyűzet
- Agglegénykonyha 7 – Még egy megosztó – de gyors – étel: resztelt máj
- Amikor a prófécia testet ölt – Finalmouse ULX Prophecy 'Scream' Classic
- sziku69: Fűzzük össze a szavakat :)
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- Meggyi001: Eldugott helyek Párizsban, amiket jó eséllyel még nem láttál...
- ricshard444: iPhone 17 Pro Max - Kedves téglám
- sidi: Samsung Deskmaster 386s/20n
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Gurulunk, WAZE?!
- MasterDeeJay: MSI H110M PRO és i3-8350K (coffeetime mod)
Új hozzászólás Aktív témák
-
PuMbA
titán
Azt kihagytam, hogy OMM-et is használnak, szóval mindkét dolgot, ami benne lesz a DXR 1.2-ben, de természetesen ezek most csak NVIDIA-n működnek, nekik van saját működő API-juk erre
Alogonomus: Mármint miért? OMM és SER csak NVIDIA-n van jelenleg tudtommal, illetve ez a videó a Path Tracing-ről szól, nekem nehéz kivenni, hogy mi érvényes a normál RT-re is.
gainwardgs: Egy kis DLSS-t nyomass
-
Alogonomus
őstag
Na akkor ezért van teljesen pariban maximálisra állított sugárkövetés esetén is az RDNA 3/4 a Lovelace/Blackwell kártyákkal.
-
PuMbA
titán
Inside Doom: The Dark Ages' Path Tracing Upgrade - The id Software Interview!
A SER (Shader Execution Ordering) jó dolog, az elsők között implementálták
Nem hiába jön a DXR 1.2-be. A Vulkan és DX12 API ugyanazt tudja. Mit látnának még az API-kban? A Work Graphs nagyon jó irány, kell. Illetve, hogy ne csak grafikái munkát lehessen benyomni, hanem beleszőni compute-ot vagy AI feladatokat.
-
Gainka
őstag
válasz
szmörlock007 #49395 üzenetére
1600 orat raktam bele 80 fps alatt tudom miröl beszélek.
Lehet van az a szint mikor mindegy, nekem kevés volt.
[link] -
szmörlock007
aktív tag
Vannak emberek akik jó létükben nem bírnak magukkal mit kezdeni, na ezek szerint 144 fps alatt csak a posvány van
Én a BF5-nél konkrétan fixáltam 60 fps-re, és ennek ellenére se volt gondom az eredményességemmel, általában az elejében vagyok, bár én imádom a bf sorozatot, már a bf3 óta. -
Gainka
őstag
Fix 80-100 alatt játszhatatlan, max nézönek és idegroncsnak leszel jó. Mikor kijött a Bf5 én is azthittem, szidtam a játékot, aztan kiderült hogy 60-80 fps kevés, hátrányban leszel még egy gyengébb képességü jatekossal szemben is. Hibá nem akad es elsétálgatsz ugye nem csak ennyiből áll. 100 fps fölé kell gondolkodni, ez van.
-
-
Tökmindegy, mert egyikkel sem lehet érdemben játszani vele normálisan majd. Akár elindul, akár nem.
Főleg hogy ilyen régi gépekben, valszeg a cpu/platform is elavult hozzá. -
Zilko87
aktív tag
válasz
huskydog17 #49389 üzenetére
"Kákán a csomót..."
-
huskydog17
addikt
Azt azért hozzá kell tenni, hogy a játék egyik szériát sem támogatja, se a Polaris-t se a Vega-t, se a Pascal-t. A minimum arch AMD-nél az RDNA1, míg NV-nál a Turing, így ez esetben a hardver és játékfejlesztő is jogosan mondhatja, hogy user error, mert nem támogatott hardverrel próbálkoznak. Ennek ellenére az érintett játékosok megint azt tapasztalhatják, hogy NV esetén (Pascal) működik a játék, míg a pirosaknál nem. Ez nyilván egyfajta kellemes bónusz a zöldek és/vagy a játékfejlesztők oldaláról, míg a piros oldal felhasználói ismét hoppon maradnak, mármint ott nem jár ez a bónusz.
Ennyit számít, hogy a zöldek idén őszig viszik a Pascal mainline driver supportot, így a BF6-hoz lesz driver támogatás még úgy is, hogy a játék nem támogatja a Pascal-t. A piros oldalon ugye 2 évvel korábban, 2023-ban szűnt meg a mainline support a Polaris/Vega arch-okhoz.
Ez most nagyon látványos lett a BF6 esetén.
Itt megint fel lehetne hozni, hogy akkor most melyik oldal is a Finewine.#49388 Zilko87: "THIS BREAKS AMD ADRENALIN SOFTWARE PANEL DONT DO IT IF YOU USE IT REGULARLY!!"
"Melyik kezembe harapjak" esete.
-
válasz
huskydog17 #49383 üzenetére
Polaris/Vega tulajok bukták a Bétát.
[link] -
huskydog17
addikt
válasz
huskydog17 #49383 üzenetére
Frissítés:
Az Intel javította az összeomlást az új béta driverben.
#49384 gainwardgs: Az sokkal időigényesebb és macerásabb főleg a DRM miatt, talán a full launch-nál lesz, ha náluk nem, akkor a PCGH-nál szinte biztos. Egy bétához szerintem még ez a teszt is feleslegesen sok.
-
gainwardgs
veterán
válasz
huskydog17 #49383 üzenetére
Cpu teszt is lehetett volna bent
-
huskydog17
addikt
Battlefield 6 Open Beta - CompuerBase Teszt
A játék már most, nyílt bétában is jó gyors, egy RTX 5050/4060 elegendő a 60 fps-hez. Ugyanakkor RT nincs és a LOD túl agresszív, ezen felül minden felskálázót támogat, kivéve az FSR 4-et, hiába hozott ki az AMD Game Ready driver-t időben. A CB itt nagyon jól írja a lényeget, pont erről beszéltem korábban már sokszor, egy újabb nagy top AAA cím, ami mostohagyerekként kezeli az FSR4-et, valamiért a fejlesztők nem nagyon szeretik, de az AMD is bealudt megint:
"Denn FSR 4 wird trotz Game-Ready-Treiber nicht unterstützt. Hier hat AMD bei einem neuen Top-Titel erneut geschlafen, sodass die eigene RNDA-4-Kundschaft nicht die beste Spielerfahrung haben kann."
8 GB elegendő 1440p-hez is. Felette 12 GB kell, de több nem.
Képminőség fronton messze a DLSS 4 a legjobb, ebben nincs semmi meglepő, ahogy performance téren is kb. a papírforma érvényesül, leszámítva az Intel-t, a kékeknél valami nagy gebasz van, nagyon fekszik az Arc kártyáknak. A770-en nem is működik a játék, mert töltés közben a játék összeomlik. Itt az Intelnek sürgősen rá kéne feküdnie a témára, hogy launch-ra rendbe tegyék. -
Kolbi_30
őstag
-
PuMbA
titán
The Great Hitch Hunt: Tracking Down Every Frame Drop | Unreal Fest Orlando 2025
Ezeket kellene megcsinálniuk a fejlesztőknek UE5 esetén
-
Busterftw
nagyúr
-
T.Peter
őstag
válasz
T.Peter #49378 üzenetére
Pso cache-es pelda: Az egyik project-en mi pso precaching-et valasztottunk bundled pso cache helyett, szimplan azert, mert kevesebb vele a munka. Az engine osszegyujti a pso-kat es runtime compilation utan hasznalja. Ebbol lesz a shader stutter ha nincs eleg kapacitasa a cpu-nak idoben megcsinalni (vagy amig nem elerheto, a default mat lesz hasznalva). A bundled verzional minden elore ossze van gyujtve es pl a menuben van compilation manualisan. Ez nem opcio mondjuk egy Fortnite-nal, de ahogy lathato, a RoboCop-nal az volt. Nalunk a project technical director dontott igy, hiaba ervelt ellene a lead tech artist es en is.
-
T.Peter
őstag
Ez egy olyan hiba, ami nem jott fel problemakent regebben, mert a jatekok masok voltak. Kisebbek, kevesebb asset, stb. Az jogos, hogy erre viszont mar 5.0-val kellett volna keszulni, de az nem az Epic hibaja, hogy sok studional keptelenek azokat a megoldasokat alkalmazni amiket az eloadasban is felsoroltak. Ez az egesz egy folyamat resze, most jutottunk el oda, hogy ezzel valamit kezdeni kell mert nem lehet tovabb huzni. A legtobb motor ugyanezekkel a problemakkal kuzd, csak nem hasznaljak ennyien, ezert kisebb az eselye hogy kijon a problema. Persze vannak kivetelek, ahol ezt a problemat megoldottak vagy megkerultek.
-
válasz
T.Peter #49376 üzenetére
De egy motor alapból nem tartalmazhatna ilyen jellegű hibát. Az rendben van, hogy ezt a stúdióknak lehetősége, alkalma, tudása lenne orvosolni, de az lenne a megoldás ha alapból nem lenne ilyen elemi és alapvetően zavaró hiba benne immár évek és verziók óta.
Ez azért nem egy apró kis hiba, egy bizonyos esetekben felépő gond, hanem ez a motor szerves részeként jelenlévő technológiai hiba.
Azt gondolom, az Epicnek kellett volna már évekkel ezelött orvosolnia, de nekem úgy tűnik hogy bevállalják ezt a dolgot a végfelhasználó torkán letolva, cserébe a kedvező licensz feltételekkel és egyéb, a fejlesztők számára amúgy csábító dolgokkal, ráhárítva a felelőséget a fejlesztőkre és széttárva a kezüket a vásárlókra is.
Azért egy mai játék premierkor nem 20 euros kategória, nem csak feljesztési költségek nőttek meg, hanem az "A" kategóriás játékok árai is a végfelhasználó szintjén. vannak bizonyos játékok és bizonyos kategóriák, amikor elnézi az ember ezt, mert épp egy indie stúdió,de azért egy Robocop az eddigi videók és beharangozások alapján nem indie cím. -
T.Peter
őstag
válasz
huskydog17 #49372 üzenetére
Az indie fejlesztok is belenyulnak, ha fizetnek Epic Pro Support-ert akkor meg meg az Epic is segit nekik. Ehhez nem kell kimondottan motor programozo, nalunk sem volt, megis belenyultunk, mondjuk nem emiatt. [link] Ezt meg nezd meg ujbol, hogy lasd, mik a megoldasok arra, hogy csokkentsek vagy megszuntessek a stutter-t.
A single-threaded kod sem mindenre ertendo, nem veletlen, hogy 5.6-ra atirtak egy csomo reszt ugy, hogy megjobban a worker thread-eket hasznaljak. Azzal egyetertek, hogy ide nem az 5.6-tal kellett volna eljutni.
"Tehát az, hogy a traversal akadások nem a motor hibája, mint ahogy állítottad, szimplán nem igaz."
Ilyet nem irtam. Azt irtam, hogy a megoldas a donteshozokon mulik. Ettol meg a problema az engine miatt letezik, de az, hogy ez nincs kezelve egy adott jateknal, az mar a studion mulik es az Epic is tudna ebben segiteni.Az egyaltalan nem oke, hogy ez az egesz idaig fajult, mert mindenkinek art, viszont objektiven nezve nem jelentheto ki, hogy mindenert az Epic a hibas. Viszont ezt az egeszet mar regen meg kellett volna oldaniuk, kozosen, a studioknak az Epic-kel.
-
Abu85
HÁZIGAZDA
válasz
huskydog17 #49372 üzenetére
Nem kell átírni a motort, egy sornyi kódot nem szükséges beleírni, mert az UE5 gyárilag szállított megoldásokat kínál bizonyos problémákra. Csak az Epic nem tudja, hogy az egyes stúdiók milyen játékot csinálnak, tehát a stúdióknak kell megválasztani azt a paraméterezést, amivel jól fog működni az UE5.
Például a PSO cache egy véleményes dolog. A funkciót az UE5 támogatja, de automatikusan nem aktív, mert nem mindig jó, ha az. Viszont, ha azt akarod, hogy aktív legyen, akkor az r.ShaderPipelineCache.Enabled=1 és r.ShaderPipelineCache.StartupMode=3 parancsokkal bekapcsolhatod, majd a PSO Collectorral szabályozni kell a begyűjtés módját, végül pedig a PipelineCacheToollal gyorsan betölthető formátumra lehet konvertálni a kódot.
Ezt a procedúrát az Epic sosem fogja default engedélyezni, mert nem tudja, hogy mit fogsz csinálni az UE5-ben. Ha mindenre gyárilag engedélyeznék, akkor az iszonyatosan sok PSO kombinációt jelentene, ami akár több gigabájt is lehet. Nagyon extrém esetben több 10 GB is. Gondolj bele, hogy ezt milyen sok idő lenne legenerálni. Nemhogy kávézni mehetnél ki a játék indításakor, vagy minden driverfrissítéskor, hanem megfőzhetnéd a teljes heti menüt, és jó eséllyel még várnod kellene.
Bónusz gond, hogy fejlesztés közben egy ilyen működésű motor nagyon sokat rontana a helyzeten, mert folyamatosan változik a tartalom. Gyakorlatilag mindig újra kellene generálni az egészet, ami jól kibaszna a kisebb fejlesztőkkel, mert fel kellene szerelkezniük 192 magos EPYC procikkal, hogy a fejlesztési idő 80%-a ne abból álljon, hogy várják a generálást.
A legjobb módszer a fentiek miatt az, ha egyénileg meg tudja határozni a fejlesztő, hogy mit gyűjtsön be a rendszer, mert így minden szempontból optimális lehet az eredmény. És erre szánniuk kell némi időt az életükből, mert az Epic sosem fogja megcsinálni helyettük. Az Epic csak eszközt tud adni nekik arra, amivel optimalizálhatják a készülő játékot minden aspektusból.
Az Epic nem tud mit kezdeni a köztudattal, ami összekapcsolja az UE5-öt a stutterrel. Nyilván elkezdhetik elmagyarázni az embereknek, hogy miért van default így beállítva az UE5, de az emberek döntő többségének halvány fingja sincs arról, hogy mi az a shader, így nem értenék meg a döntéseiket. Egyszerűen az egyes akadásokat a játékot fejlesztő stúdiónak kell kezelnie. Erre az Epic nem és sosem lesz képes, amíg a grafikus API-k működése olyan jellegű, amilyen.
És elárulom neked, hogy az Epic foglalkozik nagyon is a problémával. Az ARM-tól tudom, hogy olyan intenzíven benne vannak egy univerzális megoldás keresésében, hogy nagyon kardoskodnak azért, hogy legyen egy egységes vISA a gyártók számára, ami lehetővé teheti a mostani bonyolult shader fordítási rendszer mellőzését, és konzolszerűvé válna az egész működési modell. És ebben egyébként a Qualcomm és a Samsung eléggé támogatja őket, méghozzá úgy, hogy hajlandók lennének a HSAIL-t default vISA-jukká tenni. Csak az a gond, hogy az AMD, az Intel és az NVIDIA meg nem. Ebben nyilván az AMD állásfoglalása a szép, mert ők ezt úgy utasítják vissza, hogy közben HSA tagok.
Jó persze megértem, hogy miért ez most a hozzáállásuk, ők a Sony-val dolgoznak egy saját megoldáson, amit a többiek nem kapnak meg.
-
válasz
huskydog17 #49372 üzenetére
Igen egy magos használat
amikor már intel belépő szintje is lassan 10 magos lesz.
Elő kéne venniük a tökeiket és bevállalni hogy húznak egy határt nem kell minden konfigon futnia terelni kellene a népet az új felé mert probléma az hogy mindenkinek meg kell felelni pedig ez nem fog menni.Na mindegy majd talán az új konzolok változást hoznak kb 2017 és a ps4 elmegy a pî. nyugdíjba.
-
Új dolgokat meg kell tanulni tovább képzést igényel és még utánna jön a rutin de sokat hibáznak addig.
Ez se túl komoly ennél az engine-nél 60fps
5.6:
The latest version, emphasizing the ability to build and deliver high-fidelity, large-scale open worlds at 60 FPS on current-generation hardware.Na akkor majd talán az új vga-k megkűzdenek vele 2017-ben 120Hz-en. A witcher ha olyan open world lenne mint a 3 volt nagy xar volna de "szerencsére"árkád pályák lesznek.
-
huskydog17
addikt
válasz
T.Peter #49371 üzenetére
Az indie fejlesztők 99,99%-a nem fog belenyúlni a motorba semmilyen formában, főleg mert nekik nincs motorprogramozójuk, amit nem is lehet elvárni tőlük és pont emiatt is vesznek egy motort. Emiatt teljesen rá vannak utalva arra, hogy az Epic hogyan rakta össze a motort. Igen, nyilván van probléma, amit a játék készítője orvosolhat, ilyen például a shader compilation stutter, ezzel nincs is gond a fent említett játékban, mert a készítők foglalkoztak vele, PSO stutter nincs is a játékban. A traversal akadásokkal azonban nem tudnak mit kezdeni, mert azt a motor kódja okozza.
Az egész motor brutál CPU limites. Lehet bármilyen ügyes a játék készítője, illetve a pálya tervező, mindegy mennyire óvatosan bánik az assetekkel stb. ha a motor kódja egyszerűen fos, mert brutál CPU limites, akármit csinál, akadni fog, ez kívül esik a területén, ez kizárólag a motor, illetve az motor fejlesztőinek (Epic) hibája.
Ezt egyébként maga a vezér Tim Sweeney is kijelentette, hogy a teljes szimulációhoz és game logic-hoz egyetlen CPU magot használ a játék. Tim elmondta, hogy single threaded kódot sokkal könnyebb volt írni, ezért mai napig az van benne. Nem nehéz elképzelni, hogy akkor mi minden más lehet még a motorban single threaded, amiről Tim nem akart beszélni, mert nyilván ő nem fogja a saját termékét sározni, főleg nem azt, aminek a vagyona nagy részét köszönheti.Tehát az, hogy a traversal akadások nem a motor hibája, mint ahogy állítottad, szimplán nem igaz. Az meg, hogy a döntéshozók miatt van, ez meg ferdítés, pontosabban ez nézőpont kérdése.
Nézhetjük úgy is, hogy ha a döntéshozó a játék készítője és kiadója, akkor igen ők rosszul döntöttek amikor az UE5-öt választották, mert pontosan tudták, hogy ilyen súlyos gondja van.
Nézhetjük úgy is, hogy a döntéshozók az UE fejlesztői akik a mai napig nem írták át a single thread kódot, itt pedig ismét oda lyukadunk ki, hogy a játék készítője nem tehet arról, hogy szarul fut a motor.Felesleges azonban bármit szépíteni a dolgon. A köztudatban egyre negatívabb a megítélésé az UE5-nek, egyre több felhasználó (játékos) utálja, mert mindenki látja, hogy a performance a legtöbb játékban egy rakás kaki. Nem hiába terjedt el a Stutter Engine elnevezése sem. A független tesztekben is legtöbbször szarul szerepel, ezt már a tesztelők is tudják, hogy az UE5-nek aránytalanul magas a gépigénye és akadások jellemzik általánosan.
A fenti játék is pont a motor miatt akadozik, mert az traversal stutter, azzal nem tudnak mit kezdeni, azt csak az Epic tudná javítani, de az 5-ös generációban biztosan nem fogják már. Ezt majd talán az UE6-ban javítják és akkor ott majd lehet azt is reklámozni, hogy "Hűh nézzétek, hogy begyorsítottuk , sokkal gyorsabb, mint az elődje!". Már látom előre, hogy ez lesz.
Nem is akarom tovább húzni ezt az off témát, főleg, mert milliószor ki lett vesézve különböző topikokban.
-
T.Peter
őstag
válasz
huskydog17 #49368 üzenetére
Senki nem tagadja le es mar az Epic is foglalkozik vele mert lathatoan a studiokat nem erdekli elegge ahhoz, hogy megoldjak maguk. A donteshozok a lead-ek, director-ok, stb, akik a vegso dontest meghozzak. Hiaba tudnak a programozok es tech artist-ok megoldani, ha nem kapnak ra idot es tamogatast hozza. Ebbol az egeszbol meg az jon le, hogy az engine a hibas mindenert, mikozben ez nem igaz, sok mindenert igen, de nem mindenert. A pso caching is hasonlo. A studio donthet ugy, hogy a caching a menuben megtortenik es ennyi, de donthet ugy is, hogy nem erdekli, majd runtime megoldja az engine es kesz. Tudjuk melyik mivel jar. Errol sem veletlenul tartott az Epic eloadast es nem veletlenul alakitottak at a pso caching-et (a Fortnite-ra ra is fert, bar az a skin-ek miatt sosem lesz teljesen jo). A hitching-rol is tartottak, mert ott is latjak, hogy nem tiszta minden a fejekben.
-
Abu85
HÁZIGAZDA
válasz
huskydog17 #49368 üzenetére
Az engine nem egy varázsdoboz, ami mindent megold. Az UE5 sem fogja default beállítással lefedni az összes helyzetet, amivel egy fejlesztő előállhat. És ha a default paraméterezés nem elég jó, akkor például lehet alkalmazni különféle optimalizációkat, például PSO cache, async loading, level streaming volumes megfelelő paraméterezése, stb.
Az Epic biztosítani tud egy default működést, ami nagy átlagban nem tökéletes semmire, de kvázi elmegy majdnem minden vele. Adnak neked egy terepjárót, mert fogalmuk sincs, hogy mit fogsz csinálni, de ha már tudod, hogy egyenes aszfalton mész, akkor neked kell kicserélni a gumikat, hogy jobb sebességet kapj. De most képzeld el, ha F1-es autót adnának neked. Terepre azzal nem nagyon mennél, szóval jó oka van az Epicnek arra, hogy default ilyen a motor. Ez az UE5 lényege. Jó mindenre, de semmire sem tökéletes. Neked kell azzá tenned, mert az Epic-kel ellentétben te már tudod, hogy mit fogsz vele csinálni.
-
T.Peter
őstag
Munkat igenyel megoldani, remelhetoleg 5.6-tal ez a munka sokkal kevesebb lesz, mert a legtobb dolog out of box ugy fog mukodni ahogy eddig is kellett volna.
A donteshozoknal a stutter addig nem problema, amig a jatekosok es a sajto nem hozza fel problemanak, mert ennek megoldasatol a jatek nem lesz jobb, viszont fejlesztesi idot kot le. Palyareszek es interakciok kuhagyasa nem oldja meg, ettol meg a betoltes marad mas palyareszen. Ezzel a kezdetektol fogva szamolni kene es mindent ugy kialakitani, hogy kezelni lehessen design es engine oldalon is. A producereknek pedig ugy kene kialakitani a fejlesztesi utemtervet hogy erre legyen ido, de ez nem tortenik meg. QA-nak is ki kell vennie a reszet, hogy a stutter is bug-kent legyen feltuntetve. Hiaba lehet latni pl a stuttert, a vegso dontes peldaul a project technical director-nel van. -
huskydog17
addikt
válasz
T.Peter #49366 üzenetére
"Szoval elmondhatjuk, hogy megint nem az engine-en, hanem a donteshozokon mult."
Nem az engine-en? Akkor a konyhásnénin? Kik azok a döntéshozók? Miért akarjuk letagadni, hogy az UE5 játékok 99%-a traversal stuttering-ben szenved? Ez nekem nagyon is engine problémának tűnik.
-
PuMbA
titán
válasz
T.Peter #49366 üzenetére
Érdekes, hogy majdnem minden döntéshozónak ebbe törik bele a bicskája az UE5-ben, hogy a traversal stutter nincs megoldva
Vajon miért ezt nem csinálják meg / sorolják utolsó prioritási helyre, miért nem valami más, a játékban lényegtelenebb dologtól vesznek el erőforrást? Inkább legyen eggyel kevesebb pályarész, ne legyen egy bizonyos interakció vagy valami, mint hogy szénné akadozik a játék. Ezt sose fogom megérteni.
-
T.Peter
őstag
válasz
huskydog17 #49365 üzenetére
"There are a lot of traversal stutters in the game. Whenever level sections are reloaded in real time, the game gets stuck."
Szoval elmondhatjuk, hogy megint nem az engine-en, hanem a donteshozokon mult. -
huskydog17
addikt
RoboCop: Unfinished Business - ComputerBase teszt
Csak a szokásos stutter fest a sok traversal akadásnak köszönhetően (UE 5.4).
Érdekes 1440p-n, hogy 4 SKU ugyanolyan tempót hoz: RTX 4080 Super, RX 7900 XTX, RX 9070 XT és RTX 5070 Ti
Nem sűrűn látni ilyen összehangolt teljesítményt.Egyébként ahhoz képest, hogy UE5-öt használ, leszámítva a rengeteg traversal akadást, az átlag tempó nem is olyan vészes, 1080p-hez elegendő egy RTX 4060 a 60 fps-hez, míg 1440p-n az RTX 5060 Ti hozza stabilan.
VRAM ügyben 8 GB elegendő 1440p-ig bezárólag. 1440p felett 12 GB kell, de az mindenre elég.
Ezt is megszokhattuk már ettől a motortól, semmi újdonság, mindig takarékosan bánt a VRAM-mal. Na persze vannak ettől még takarékosabb motorok is, de ez is elég jó (ha már ezt nem lehet elmondani általánosságban éve a teljesítményről
). Legalább nincs shader compilation akadás, legalább erre odafigyeltek a készítők.
Szerencsére ez a játék sem érdekel engem.Natívan implementálták a DLSS 4-et és XeSS 2-t, míg az FSR 4 kimaradt, de van 3.1. Hivatalos FSR 4 támogatás semmilyen formában sincs, az AMD sem támogatja driverből, így kizárólag mod-al (Optiscaler) van rá lehetőség.
Ha pedig már FSR 4-nél járunk, egy másik technikai érdekesség:
Cyberpunk 2077 megkapta az FSR 4 és XeSS 2.0 natív implementációt, továbbá FSR 3.1 FG-t, amely bármely felskálázóval működik.
FSR 4 még nem használható, mert az AMD nem készült el a megfelelő driver-rel, ezért a játékban még le van tiltva a funkció, azaz a játék készítők gyorsabbak voltak, mint az AMD driver csapata.Pont erről beszéltem korábban nem egyszer: az AMD-nek arra (is) kéne törekednie, hogy nagyon gyorsan, nagyon sok játékba rakjon hivatalos FSR 4 támogatást (akár natív, akár driver szinten, mindegy). E helyett az ellenkezője történik: iszonyatosan lassan, keservesen terjed, amire számítottam is. Vagy a játék készítőjét nem érdekli, vagy az AMD driver csapata túl lassú vagy egyik felet sem érdekli (Robocop).
-
-
Abu85
HÁZIGAZDA
válasz
Busterftw #49361 üzenetére
Ne vedd számításba azt, hogy máskor mi volt. Ezek a számok nem indikátorai a jövőnek. Az egyes branchek eléggé tág időtartamot fednek le. Van amelyik branch hónapikig jelen volt, és van amelyik csak hetekig. Nem lehet előre tudni, hogy mi lesz. Az az egyetlen reális indikátor, hogy a Microsoft mikor hozza a frissítéseket, mert akkor az biztosan új branchet jelent, hiszen kellenek az implementációk a Windows Update-hez. Ez az egyetlen tényező, amihez az NV, az AMD és az Intel is igyekszik igazodni, mert nyilván lényeges, hogy egy új Windows 11 dolgot még abban a hónapban használhass, és ne több hónappal később.
-
Busterftw
nagyúr
válasz
Alogonomus #49359 üzenetére
A 580 utan szunik meg a tamogatas.
A preview driver nem nagyon jelent semmit, Microsoft funkciokra, vagy Windows Insider build-ekre iranyulnak, peldaul nem tartalmazza az osszes javitast, amelyek a legutobbi, 576-os driver verzioban szerepeltek (576.88).545-nel 6 honap kellett, mig a Windows Previewbol kiadtak "normalra".
Ha a korabbi szokasos kiadasi utemet kovetjuk, akkor a 590 kb 2026 elejen-kozepen lesz kiadva, tehat nagyjabol 1 ev is lehet, amit irtam mar fentebb.
Csak hat minek neznel utana barminek is.
-
Abu85
HÁZIGAZDA
válasz
Alogonomus #49359 üzenetére
Ezt azért lehetett tudni a bejelentés időtartamából is. Általában az NV 4-6 hónappal a kivezetés előtt jelent be dolgokat.
-
Alogonomus
őstag
Azért vált fontossá, mert az 580-as branch alatt az Nvidia megszünteti a Pascal kártyák driveres támogatását. Szóval ha az 590-es branch tényleg a Windows 11 októberi frissítéséhez igazodva érkezik, akkor nagyjából 3 hónapon belül valamikor kerülnek át a Pascal kártyák legacy státuszba, és nem majd csak akár egy év múlva, amivel egyesek próbálták csökkenteni a bejelentés jelentőségét.
-
Abu85
HÁZIGAZDA
válasz
gejala #49357 üzenetére
Nézd, ezek a számok nem határozzák meg, hogy meddig lesz velünk egy branch. Volt már olyan, hogy másfél hónapon belül új branch jött. Inkább az határozza meg a fejlesztéseket, hogy mik készülnek. És az SM6.9 eléggé fontos fícsőr, amit a Microsoft kérhet októberre, és ha kérnek, akkor hozni kell rá a drivert. Nincs mese.
A Maxwell és a Pascal támogatása pedig átkerül Legacy-be. Ezzel jobban is járnak a régi VGA-k tulajai, mert nem túl hatékony kódokat fordít már ezeknek a dizájnoknak a mostani shader fordító. Ha viszont nincsenek az új dizájnok támogatva, akkor vissza lehet térni a régebbi paraméterezésekhez.
-
Abu85
HÁZIGAZDA
válasz
gejala #49353 üzenetére
Idén októberre kell elérniük, mert akkor jön az SM 6.9. A Windows 11 éves frissítése ilyenkor eléggé meghatározza a fejlesztések ütemét.
#49355 FLATRONW : Igazából ez tök normális. Valójában ezek a branchek nem mindig maradnak ugyanaddig. Vannak nagyon rövid életű branchek is. És általában a tervezést nagyon meghatározza, hogy a Windows 11 mikor frissül, vagyis mikor érkeznek az új fícsőrök. Ilyenkor akár hónapokat ugranak, mert van egy fontosabb képesség, amire átrakják az erőforrást. Ezért van már 590-es preview driver, mert már azt fejlesztik, és nem az 580-as branchet. Valószínűleg az 580-as nem is fog újításokat hozni, csak kitöllti majd az űrt, amíg október nem lesz. De amúgy a driver jelzése nem olyan nagy kunszt. Nem értem, hogy miért vált hirtelen fontossá.
-
gejala
őstag
válasz
Alogonomus #49352 üzenetére
Ez csak preview driver, azokat mindig jól előre számozzák, ebből nem lesz egyhamar whql. Évekbe is telhet, mire a release branch eléri az 59x-et.
-
Alogonomus
őstag
válasz
Busterftw #49285 üzenetére
"Illetve az 580 branch kitarhat akár 1 évig is, szóval nem most lesz."
És el is érkezett az 590 branch időszaka.
-
huskydog17
addikt
válasz
Alogonomus #49347 üzenetére
"Szerintem gondold végig a szituációt, mielőtt hozzászólást írsz."
Én átgondoltam, veled ellentétben. Pont te hozod is rendszeresen a hamis információkat, amelyeknek abszolút semmi alapja nincs.
"A War Thunder Mobile, ami a handheld eszközön fut, az egy külön szoftver."
Ahogy b. is írta már: nem. A Mobile verzió - ahogy azt a nevéből teljesen egyértelműen ki is lehet következtetni mily meglepően - kizárólag mobiltelefonokra van. A MSI Claw NEM mobiltelefon, az egy kézi számítógép, egy PC, pont olyan, mint mondjuk egy Steam Deck, amin a PC verzió fut. Fogalmam sincs honnan veszed, hogy a Claw-n a mobil verzió fut, ami szembe egy minden józan ésszel, főleg hogy a készítők leírták, hogy Xess és aktív RT mellett. Szerinted mobilon van XeSS és RT/PT? Mi alapján vagy meggyőződve arról, hogy a Claw-n a mobilverzió fut, hol láttál ilyen kijelentést a készítőktől? Csak mert pont az ellenkezőjét írják a blogon.
"Amit egy MSI Claw 8 integrált grafikus egységeként az Intel Arc Graphics 140V képvisel, az nagyjából egy GTX 1060 vagy RX 580 szintű teljesítmény. Persze ki lehet annyi teljesítményből is hozni 70-90 fps értéket a handheld eszközök képességeihez fejlesztett War Thunder Mobile grafikai részletessége mellett az upscaling és egyebek bevetésével."
Attól, hogy többször ismétled a hülyeséget, még nem lesz igaz. A Claw-n nem mobil verzió fut, hanem a PC verzió. Márpedig ha a Lunar Lake IGP-je ilyen jó tempóra képes Medium PT mellett, akkor a mai, modern dedikált VGA-kkal nincs miért aggódni a teljesítmény miatt.
Ú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!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest