Új hozzászólás Aktív témák
-
#49953
Abu85
HÁZIGAZDA
Pocoyo.hun
#49952
Abu85
HÁZIGAZDA
válasz
Pocoyo.hun
#49952
üzenetére
A figyelmeztetés az nem tiltás. És az AMD szerint még ma is vannak eladásaik az MI 308-ból Kínában. Majd ha hivatalosan megtiltják a cégeknek, hogy ezt rendeljék, akkor nem lesznek, de egyelőre nem tiltották még meg. A H20-at viszont teljesen megtiltották, ott már nem csak figyelmeztetés van.
Ha az AMD túl nagyra nő, akkor valószínűleg ellene is tiltást fognak kiadni, de még nem tették meg. Emiatt csak a H20 van kitiltva.
Valószínű egyébként, hogy a Hygon bonyolítja a helyzetet, mert az 49%-ban kínai tulajdon, és abba az IP-t az AMD rakja bele. Tehát van egyfajta fegyver az AMD kezében, hogy ha valami kellemetlent dönt a CCP, akkor ők meg majd nem folytatják a Hygon együttműködést. Ez azért fontos, mert a kínai, házon belüli adatközpontok 100%-a Hygon fejlesztésű. A Zhaoxin versenyez még ezen a területen az x86-tal, de a KH-50000 is Hygon licenc. Az AMD-t nehezebb lesz innen kirakni, mert van a kezükben valami, amitől a kínaiak még nem búcsúznának, mert nincs mivel pótolni.
-
Abu85
HÁZIGAZDA
A kínai dolog nem ennyire egyszerű. Itt a helyzet ott kezdődött, hogy az USA engedélyt adott az NV-nek és az AMD-nek a H20 és az MI308 szállítására, ha leadják az ezek eladásából származó bevétel 15%-át. Kína viszont erre rögtön azzal reagált, hogy megtiltották a kínai cégeknek, hogy vegyenek H20-at. Ezért csökkent az NV részesedése gyakorlatilag 0%-ra. Viszont azóta kiderült, hogy a kínai döntés csak a H20-at tiltja, az MI308-ra nincs még hivatalosan ilyen tiltás. Ezt az AMD szállítja is, bár valószínűleg fel vannak rá készülve, hogy ha nagyra nőnek, akkor őket is tiltani fogják, tehát nagy fókuszt azért nem helyeznek ide. De emiatt jelenleg csak az NVIDIA szorult ki, az AMD még nem.
#49945 Busterftw : Inkább nem tud vele mit tenni, mert egy dolog az USA exportkorlátozása, és akkor eladják Szingapúrnak, ahonnan majd becsempészik, és egy másik dolog, hogy Kína tiltja, amikor már a csempészés sem opció. Szóval nem esik nekik jól, és nyilván aggódnak is miatta, de kezdeni nem tudnak vele semmit.
-
Abu85
HÁZIGAZDA
Az OOO memóriaelérés raszterben főleg az ilyen mindenre jól optimalizált játéknál jelent előnyt, mert itt működik eléggé agresszíven a streaming és a LOD-kezelés, hogy számítson, hogy az adatok megérkezhetnek a hardver számára optimális sorrendben, és nem csak a kérések sorrendjében.
Valamekkora előnyt mindenhol ad az AMD szerint az OOO memóriaelérés, de itt a mérhető előny a kérdés, és ahhoz sok memóriaelérés kell, mert akkor lesz elég sok kérés ahhoz, hogy valós problémát jelentsen a kérések nem optimális sorrendje.
-
Abu85
HÁZIGAZDA
Kifejtem jobban akkor, amit a COD-ban látunk nem igazán hardveres eltérés. Részben az, mert számít a hardver, de a motor működését nézzétek. Három dolog jellemző az újabb IW motorokra.
- nagyon shader-gyilkosok, tehát iszonyat mennyiségű compute shader van bennük, főleg a post-process oldalon
- majdnem minden objektum vagy effekt más futószalagállapotot használ, amivel együtt jár a bitangsok különálló rajzolási parancs, és a sok százezer dinamikus shader
- kolosszális mértékű a dinamikus textúra streaming és a LOD váltások számaEzek egyébként főleg abból erednek, hogy maga a motor szinte teljesen dinamikus rendergráfot használ, ami még most sem jellemző a legtöbb másik motor esetében, a többség inkább amolyan féldinamikusabb rendszer, kellő számú statikus rendergráffal, hogy valamilyen mértékben korlátozzák a PSO-váltások számát. Tehát effektíve minden motor alkalmaz már dinamikus módszert, mert sok helyre ez kell, a kérdés inkább az, hogy mely renderszakaszok futnak még statikusan, például általában a G-buffer még ilyen, stb.
Viszont a DirectX 12 API-t alapvetően a dinamikus módszerhez tervezték, tehát bátran át lehet térni erre a leképezés egyes szakaszain, és a COD újabb motorverziói ezt nagyon ki is használják. A többi motornál még nem ennyire, de az irány az egyértelműen ez. A másik "nagyon dinamikus" motor egyébként még az Ubisoft-féle Anvil, ami az új verzióiban eléggé hasonlít a COD újabb motorverzióira.
Ha ilyen irányba megy egy motor, akkor az helyből magával hozzá azt, hogy majdnem minden objektum vagy effekt más futószalagállapotot használ, tehát megnő a PSO-váltások száma, a rajzolási parancsokat érdemesebb különállóan kezelni, stb. Ez a hardver tekintetében nem akkora gond, de a szoftver tekintetében már az lehet. Ugyanis minél inkább erre megy egy motor, annál inkább meghatározza a teljesítményt az, hogy a shadereket hogyan fordítja a driver fordítója, hogy a kódvalidálás mennyire gyors, hogy a rajzolási parancsok összességében mennyi DWORD-öt emésztenek fel, hogy az egyes parancsok betöltése mennyire blokkolja a GPU és a CPU feldolgozását, stb. Na most ebből a szempontból az AMD meghajtója eléggé egy versenyautó, egy csomó dolgot nagyon furán csinál a DX12 és a Vulkan alapimplementációját biztosító PAL réteg, ami nagymértékben javítja a teljesítményt, miközben elvben kevésbé biztonságos, de látszólag senkit sem érdekel, mert a programok így is futnak, miközben baromira gyors a driver, és átmegy a hitelesítési teszteken, tehát a Microsoft és a Khronos szerint valid eredményt biztosít. Az NV meghajtója valamiért túlbiztosított, ami azt eredményezi, hogy bizonyos helyzetekben egy banyatankos nagymama sebességével működik, de a programokat futtatja. És a legtöbb esetben ez jó, mert a tesztek úgyis 9800X3D-vel mennek, tehát a banyatankos nagyi tempó is eléggé el lesz fedve, mert kegyetlenül gyors a tesztproci. Csak ez nem minden játékban lesz igaz, mert a COD-ok és az AC-k már 9800X3D-vel is limitesek lehetnek. De ha az AMD kiadna mondjuk egy 9800X3D-nél kétszer gyorsabb procit, akkor ugyanaz lenne a COD-ok és az AC-k alatt is az erősorrend, mint a többi játékban, mert a kétszer gyorsabb szálszintű teljesítmény jobban fekszik a banyatankos nagyinak.
Egyébként ez az oka annak is, amiért a Microsoft-féle Advanced Shader Delivery kapcsán az AMD-nek és az Intelnek már tesztdriverük is van, míg az NV még csak azt jelentette be, hogy támogatni szeretnék majd valamikor. Az Advanced Shader Delivery pont arrafelé terelné a fejlesztőket, hogy nyugodtan menjenek a PSO-váltások növelése felé, az Advanced Shader Delivery megoldja az akadások gondját. Az NV tehát előbb-utóbb rákényszerül a banyatankos nagyijuk versenyautóra cserélésére, és valószínűleg már dolgoznak is rajta. Vagy ha még nem, akkor az Advanced Shader Delivery mindenképpen jelzés, hogy ezt nem tudják elkerülni, szóval el kell kezdeniük visszarakni a programozóikat az AI-ról a játékosoknak szánt driver fejlesztésére.Az RDNA 4 némi előnye pedig pusztán az OOO memóriaelérésből származik. Ez inkább COD-specifikus, mint általános dolog, ugyanis a COD-ok nagyon agresszíven streamelnek. Nagyon sok LOD szintet használnak, sok váltással, hogy gyors legyen a sebesség, ez különösen igaz a BO7-re. Persze ezt le kell tervezni, szóval nyilván a fejlesztés oldalon szopcsi, de megcsinálják, így senkit nem izgat, hogy erre mennyi erőforrást költöttek. Részben innen származik a sok PSO-váltásuk is. Na most a dinamikus textúra streaming és a LOD váltások ilyen mértékű száma mellett már masszív előnye lehet annak, hogy az RDNA 4-nek a memóriaeléréseket nem szükséges sorrendben végrehajtania. Erre a többi GPU nem képes, ezeknél a hardver alapvető működése múlik azon, hogy az adatok a kérés sorrendjében fussanak be, és az egyes wave-ek feldolgozása is csak ebben a sorrendben lehetséges.
-
Abu85
HÁZIGAZDA
És ezeknek nagyon egyszerű oka van, amikor a root signature-be kötik be az erőforrásokat, akkor azok nem megbonthatók, tehát az AMD kénytelen nagyobb csomagokat készíteni, ami így erősebben terheli a saját koncepciójukat. De a játékok 99%-a nem ilyen, már csak azért sem, mert a root signature-be való bekötést, maga a Microsoft nem ajánlja. Például az Atomfallt külön emiatt módosították, mert instabil működést okozott, hogy nem úgy használta a DirectX 12-t, ahogy azt előírta az API tervezője.
De valóban igaz, hogy ha nem úgy használod a DirectX 12-t, ahogy a Microsoft előírja, az a pár játék, az valóban jobb az NV és az Intel driverével, mert az AMD drivere a DirectX 12 játékok 99%-ára van tervezve.
-
Abu85
HÁZIGAZDA
Annyit hozzátennék, hogy az egyes gyártók között az egységes API-k mellett is nagyon eltérő a Vulkan és a DirectX 12 implementációja. Sőt, az AMD-nél nincs is külön implementáció, egy közös PAL rétegen keresztül kezelik mindkét API-t, és csak a különbségeket menedzselik az ICD réteggel.
A lényeg az, hogy részben hardveres sajátosságok miatt más az egyes erőforrások kezelésének és menedzselésének menete, ami nagyon röviden így néz ki:
Az NVIDIA még az explicit API-knál is erőteljesen épít egy úgynevezett push bufferre, ami azt a célt szolgálja, hogy a lehető legtöbb metaadattal lássák el a hardvert, miközben ritkítják a futószalagok kiürítésének számát. Ennek az ára a nagy memóriaigénye, illetve a CPU oldalán több munkára van szükség, hogy a driver push bufferét megfelelően menedzseljék. A bekötés tekintetében pedig az NVIDIA előre gyorsítótárazza a leírótáblát, és utána ezt csak szükség esetén módosítja. Ez megint több memóriát és CPU-időt eszik, viszont az állapotváltások minimalizálhatók, amire eleve haknis az a fajta működés, ahogy az NV drivere feldolgozza az adatokat.
Az Intel sok tekintetben épít a CPU-ra. Amit csak tud a CPU állít össze, és a GPU-nak elég csak beolvasnia. Nagyon sok munkát megspórol így maga a GPU, mert kész futtatandó assemblyket kap a CPU-tól. De mivel ez így működik, nehéz batch-elni, és egy rakás dekódolási munkával jár már a CPU oldalán, hogy a GPU dekódolási munkája megelőzhető legyen, ami nagyobb többletterhelést ad.
Az AMD épít a legkevésbé a CPU-ra, mert maga a PAL úgynevezett leírócsomagokat dolgoz fel. Ez nincs külön kezelve az API-kban, de maga a Mantle eleve olyan jellegű feldolgozással készült, amilyen jellegű nagyvonalakban a DirectX 12 és a Vulkan, és emiatt a két szabványos API-ba is beletervezték az egyes erőforrások feloszthatóságát. Mondhatni ez egy Mantle örökség, amit a Microsoft nem vett ki a prototípus kódból, és a Khronos is továbbvitt, hogy a hardver számára optimalizálható legyen a valós feldolgozás, miközben az API maga a finom részleteket elmaszkolja. Az AMD drivere tehát majdnem mindent ilyen leírócsomagokban kezel, és ezek a csomagok elképesztően picik, miközben teljesen függetlenek egymástól, tehát nem számít, hogy esetleg két csomag nagyobb műveletet bont meg, azokat a hardver össze tudja rakni belül, ha a két csomag megérkezik számára. A drivernek csak azt kell menedzselnie, hogy a két csomag egymás után fusson be. Mivel így minden munkamenet nagyon picire van szabva, a processzoridő is elég kevés lesz velük. Ráaádsul a sok eltérő csomag miatt nagyon párhuzamosítható az egész, szépen lehet osztani a munkát 4-5-20-30 magra. Utóbbi a kulcs az AMD-nél, mert nem azért olyan hatékony a drivere, mert valami elképesztően szűkre van szabva a munka. Ők is használják a CPU-t rendesen, csak nagyon párhuzamosítva, hogy a kis csomagok feldolgozása jól menedzselhető legyen, jól be lehessen illeszteni ezeket a meglévő magok szabad kapacitására.
A fenti különbség felel azért, amit láthatunk a tesztekben, ha gyengébb CPU mellé kerülnek a hardverek. Például egy tipikus hatmagos CPU egyik nagy hátránya az, hogy mindenképpen lesz egy-két mag, ami jobban lesz terhelve. Ez nagyon tipikus a többszálú feldolgozáskor. És a program terehelése mellett még az NV és az Intel drivere is főleg egy-két magot terhel, mert nagyobb munkákat csinálnak meg. Az AMD előnye itt onnan ered, hogy a driverük nem terhel be nagyon egy-két magot, hanem szépen szétosztja a munkát az összes mag között. És ezért lehet látni azt például a HUB overhead tesztjeiben is, hogy mennyivel jobban bánik a CPU-idővel, mert gyengébb CPU-val sem jön erőteljesebb CPU-limit.
-
#49861
Abu85
HÁZIGAZDA
huskydog17
#49856
Abu85
HÁZIGAZDA
válasz
huskydog17
#49856
üzenetére
Te tényleg nem tudsz olvasni? Nézd már meg, hogy mit írtam.
Az Intel csinált egy alternatív stratégiát a különböző, GPU-nak küldött csomagok kezelésére. Ez ugyanis sokszor nagyon rossz volt az egyes API-kon. És ennek az oka részben hardveres, egészen pontosan azért mert sosem PCI Expressen való bekötésre tervezték a GPU-t, de részben szoftveres, mert amikor ezt a részét írták a drivernek, akkor sem gondoltak még arra, hogy valaha is PCI Expressen keresztül kötik be a GPU-ikat. Ez a szoftveres rész átírható, még a hardveres tervezés ellenére is, mert csak amiatt olyan amilyen, hogy eleve nem volt korlátként kezelve a PCI Express busz, mert nem is volt az IGP-knél. Most viszont van, és lehet hozzá igazodni. Ezt csinálja a driver, másképp küldi be a csomagokat, így azok szép ciklusosan lesznek feldolgozva a parancslistából. Nem nagyon fordulhat elő az a szituáció, hogy felhalmozódás történik, ami például a kapcsolódó gondok gyökere.
És azért csinálja ezt az Intel, mert a Battlefield 6 például nagyon másképp működik, mint a korábbi Battlefieldek. Erről nyilván tudtak már hónapok óta, és látható is, hogy például ez a játék még 9800X3D mellett is CPU-limites tud lenni. Ezért van az, hogy amikor előhozol egy erőteljes parancsgenerálós szituációt benne, akkor a Radeon 9070 XT bárminél több fps-t tol ki. Nem a GPU a gyorsabb minden más GPU-nál, hanem az AMD drivere dolgozza fel a rajzolási parancsokat sokkal gyorsabban. Emiatt van az, hogy ha mondjuk egy átlagosabb CPU mellé teszed a Radeon RX 9070 XT-t, teszem azt egy tipikus hatmagos Core vagy hatmagos Ryzen mellé, akkor ennél a GPU-nál nem tudsz gyorsabbat venni a piacon, ha az adott játék CPU-limitessé válik. Mert ilyenkor nem a hardver ereje a kulcs, hanem a driver hatékonysága.
A Battlefield 6 kifejezetten haknis erre, és emiatt az Intel GPU-i nem is nagyon kedvelték a bétát, de az új funkciókkal már jobban viselkednek. És lehet, hogy ezek az új funkciók most még fehérlistás, de mivel jóval gyorsabb a régi működési módnál, kellő tesztelés után ez lesz az általános mód, mert mindenhol gyorsít. Ezért mondta az Intel, hogy még csak per játék szinten működik, de nem mondták, hogy sosem fogják ezt engedélyezni általánosan.
-
Abu85
HÁZIGAZDA
És ezzel semmi gond nincs. Általában a befektetők kíváncsiak, hogy a változásért mi felelt inkább. És mivel pont egy négy éves cikluson volt a két konzol, így akkor került ezek ára új, alacsonyabb kategóriába, de nyilván az adott negyedévben jobban számított az, hogy sok Radeon RX 7000-et vettek az emberek.
Ezt félreérted. Az ember attól nem lesz hülye, hogy nem tud felbontást váltani. Egyszerűen csak nem olyan képzett felhasználó. Nagyon sokan nem képesek rá, és nyilván a piacnak a nagy része ilyen. Úgy kb. a 70-80%-a biztos. És aki erre nem képes, nyilván azt se nézi meg, hogy mit vásárol pontosan.
Nem tudom, hogy a driver hogyan lett idekeverve. Igazából az NV-nek volt vele problémája, de leginkább azért, mert egy nagyon-nagy váltás előtt voltak, és túlságosan sok hardvert szolgáltak ki egy csomagból. Egy ponton túl ez nyilván hátrányos, főleg úgy, hogy az NV még az egyes API-k implementációját sem költséghatékony módon oldja meg. Ez sok tesztidőt, sok erőforrást és sok pénzt igényel. Ha nem rakod mögé ezeket, akkor belefuthatsz olyanba, amibe az NV belefutott. De pár hónap alatt korrigálták a hibák nagy részét.
-
Abu85
HÁZIGAZDA
Nem az számít, hogy mióta vannak piacon a konzolok, hanem az, hogy mióta szállítják a partnereknek a lapkákat. Egy ideje tudható, hogy az AMD két éves ciklusokban korrigálja az árat. Tehát van a kezdeti ár, majd két év múlva csökken, majd megint két év múlva, és így tovább. És az első lapka leszállításától számítva mérik a két évet.
-
Abu85
HÁZIGAZDA
A konzolok esetében nem igazán az eladási mennyiség a fontos, hanem az eladási ár a lapkákra. Mivel az életciklus végén járunk, az AMD már a lapkákat is nagyon kevés haszonnal árulja, mivel már visszahozták azt a profitot, amire terveztek. Emiatt ugyanazt a lapkát jóval kevesebbért adják már el a Sony-nak és a Microsoftnak.
#49826 b. : Ez pedig régóta megfigyelhető, és semmi rosszindulat nincs benne. Még a gyártóknak is van erről statisztikájuk. Például nagyon érdekes adat, hogy az AMD nem csinál olyan programot a driveréhez, ami az ügyfél helyett beállítja a program grafikai paraméterezését. És az oka ennek az, hogy a saját felmérésük szerint az ügyfeleik 72%-a erre önállóan képes. Az NVIDIA azért csinál ilyen programot, mert a saját felmérésük szerint 10 ügyfelükből 8 azt se tudja, hogy felbontást hogyan kell váltani. Az Intelnek van erre a legjobb arányuk, nekik a legtudatosabbak a felhasználóik, és ilyen szempontból a legképzettebbek.
-
Abu85
HÁZIGAZDA
Azt azért nem hiszem, hogy globálisan is kétszer annyi 9070 XT fogyna, mint 5070 Ti. Ugye itt figyelembe kell venni, hogy bolt válogatja. Nagyon fontos adat, hogy ki mennyire tudatos vásárló. Azok a boltok, amelyek megosztják ezeket az adatokat, főleg tudatos vásárlókra építenek, tehát olyan emberekre, akik nagyjából tisztában vannak a teljesítménnyel, olvasnak újságot, stb. És ezért nagyobb a Radeonok eladása itt. De például a diszkont-szerű boltokban már inkább a GeForce-ok eladása nagyobb, mert ott főleg nem hozzáértő emberek vásárolnak gépeket. Tehát a globális arány azért nagyon más lehet, mint ezekben a boltokban.
-
#49813
Abu85
HÁZIGAZDA
Pocoyo.hun
#49810
Abu85
HÁZIGAZDA
válasz
Pocoyo.hun
#49810
üzenetére
Senki sem mondta, hogy nem jó, hiszen azt nézi, hogy mennyi VGA hagyta el a gyárakat. Tehát tökéletesen alkalmas arra, hogy felmérje, hogy piacot, de ha arra vagy kíváncsi, hogy mik vannak a gémerek gépeiben, arra nincs megoldása a JPR-nek, mert addig tudja nézni, amíg a dobozban vannak, és ha egy gyártó 70%-ban kínai AI adatközpontoknak adja a VGA-kat, akkor oda adja. Ugyanez történt a kriptovalutáknál. Ott is megvoltak az eladások, csak VGA-t nem látott senki a boltokban.
Ezért van az, hogy mást mutat a JPR, és mást mutatnak a boltok saját eladásai, akik elárulják, hogy miből mennyi fogy. De egyik sem rossz, csak más piacról szól. A boltokból nem igazán megy semmi a kínai AI-piacra, tehát egy elég nagy tétele a piacnak kiesik.
Azt kell megérteni, hogy a JPR és a boltok is igazat mondanak, tehát nincs a kettő között összeférhetetlenség, csak a boltokba az egyes gyártók VGA-inak 60-70%-a el se jut.
#49811 S_x96x_S : De a JPR nagyon is hitelesen kezeli ezt. Amit leírnak a teljes jelentésekben, az teljesen behatárolja, hogy mit és hogyan mérnek. Ebből a szempontból az eredmények, amiket közölnek hitelesek. Azért érzitek úgy, hogy nem valós, mert azt hiszitek, hogy csak a gaminget mérik, de valójában a VGA-piacnak csak egy része gaming, mert sok VGA megy kínai AI-ra. Ugyanez volt a kriptonál, ott láttuk az eladásokat, hogy megtörténtek, de nem láttuk a hardvereket a boltban. Tehát a JPR szépen lemérte, hogy a gyárból mi kerül ki, és azok 90%-a el is ment valamelyik bányászfarmra. De ettől a JPR statisztikája teljesen hiteles, csak akik azt várják, hogy a gamingről szól, csalódnak benne, viszont sose mondta a JPR, hogy ez csak gaming, nem tudják meghatározni, hogy a gyárból kikerülve mire használnak egy VGA-t. Ezt egyébként még egy bolt sem tudja meghatározni, ha eladnak egy terméket.
-
#49806
Abu85
HÁZIGAZDA
huskydog17
#49805
Abu85
HÁZIGAZDA
válasz
huskydog17
#49805
üzenetére
Ó anyám, ezt de félre tudjátok érteni, de jól van, a Youtube-on nem szakemberek csinálják a tartalmat, hanem hobbisták.
Akkor röviden, hogy mi a gond. Az egyes API-kon a parancsok kezelése nem elég egységes az Intel dizájnokon. Ez részben hardveres probléma, mert eredetileg úgy tervezték a dizájnt, hogy sosem lesz PCI Expressen keresztül bekötve, így nem foglalkoztak az efféle bekötés tipikus problémájával. Mivel azonban egy VGA így van bekötve, szembesülnek vele, így a jóval közvetlenebb integrációra tervezett architektúra egy rakás limitációba ütközik. Ezeknek a limitációknak egy része azonban tisztán szoftveres. Főleg abból származik, hogy a driver nem batch-csel elég agresszíven, így nem vonják össze elég hatékonyan a GPU felé küldött csomagokat. Ez felel nagyrészt a magasabb többletterhelésért, mert ez a fajta működés IGP szintjén lehet, hogy kb. jó, de PCI Expressen már nem az.
Amit az új driverek csinálnak, hogy szoftveresen jobban kezelik ezeket a parancsátadásokat. De ez nem alkalmazásspecifikus, maximum ez a működés nincsen minden alkalmazásra engedélyezve, mert tesztelni kell, hogy nem okoz-e problémát. De idővel a régi működés úgyis ki lesz véve, mert az teljesen felesleges, ha van mellett egy jóval gyorsabb működési mód. Csak előtte tesztelni kell ezt úgy százezer alkalmazással. Szóval nem, ez nem alkalmazásspecifikusnak készült, hanem alapvetően erre áll majd át a driver, viszont ehhez még bő fél év tesztelés kell, mire előszedik az összes alkalmazást, és megnézik, hogy jó-e az új csomagkezelés.A cégek a változásokat mindig így vezetik be. Előbb 10-20 alkalmazásban próbálják ki, majd a lista bővül 100-200-ra, aztán mind mehet, kivéve azok, amikkel van valami gubanc. Vagyis a kezdeti fehérlistás működést felváltja a feketelista.
-
#49804
Abu85
HÁZIGAZDA
huskydog17
#49803
Abu85
HÁZIGAZDA
válasz
huskydog17
#49803
üzenetére
De ez általános javulás. Nem is titkolja az Intel, hogy miért volt, még ha nem is jelentették be ezt hivatalosan. Majd írok róla nemsokára.
A Celestial szerintem az alapproblémával helyből nem fog küzdeni, mert az már a működés szintjén is dedikált GPU-nak készült. A jelenlegi és korábbi dizájnokban az alapproblémát az okozza, hogy alapvetően nem úgy készült az architektúra, hogy egy szűk buszon lesz bekötve.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#49801
üzenetére
Nem csak ennyi. A saját partnereikkel oké, de akik nem partnerek, azoknak nincs kötelességük beszámolni. Ezért ezt eléggé hosszadalmas felépíteni. Egyszerűbb lenne, ha az AMD, az Intel és az NVIDIA összefogna ebből a szempontból, mert akkor egymás partnereinek adatait elkérhetnék, de ezt jelenleg csak az Intel támogatná.
-
Abu85
HÁZIGAZDA
De a JPR az a gyárból kikerülő VGA-kat nézi. Nem tudják a gyártók, hogy azok egyáltalán eljutnak-e a boltokba. Persze valószínűsíthetik, hogy melyek azok a tételek, amelyek majd kínai AI-ban kötnek ki, de biztosan nem tudják, mert nem kérdezik meg a vásárlót, hogy hova viszi a négy-öt kamionnyi árút.
Egyébként a JPR is megjegyzi, hogy a bolti eladások ettől nagyon különbözhetnek, de a piackutatásuk helyes, mert leírják, hogy mit mérnek. Most attól, hogy a vizsgált tételek 60-70%-át sosem látják boltban? Hát... ettől még eladások a gyártók oldalán.
Egyébként az AMD már jelezte, hogy dolgoznak azon, hogy bolti statisztikát hozzanak erről, csak be kell kérniük ezt, hogy összesítsék, és globálisan azért elég sok bolt van.
-
#49752
Abu85
HÁZIGAZDA
Pocoyo.hun
#49749
Abu85
HÁZIGAZDA
válasz
Pocoyo.hun
#49749
üzenetére
Sokat gyártanak, csak még mindig nagyobb a kereslet rá, mint amennyi készül. Erről pont az elmúlt héten kérdeztem őket. És igazából nem az a gond, hogy nem akarnak többet gyártani, hanem az, hogy egy VGA-nál az átfutási idő kb. négy hónap. Tehát ha most nézik a keresletet, és ahhoz igazítják a rendelést, akkor abból a kereskedők majd jövő februárban fognak érezni valamit. A mostani gyártási mennyiség pedig nyár elején lett meghatározva.
A másik gond, ami igazából véleményes, hogy gond-e, hogy az AMD-nél a gyártást az OEM igények és a kereskedői igények határozzák meg. Az NV-nél van egy extra tényező, a kínai feketepiac. És utóbbi kiszámíthatatlan, mert nem biztos, hogy a Kínába szállítók mindig elviszik a gyártósorról lekerülő GeForce-ok zömét. És ha valamikor nem viszik el, akkor azok ugye kereskedelmi forgalomba kerülnek, tehát a keresleten túli mennyiség kerül piacra, ami gyorsan az MSRP-hez löki az árakat. Ezt is kompenzálja az NV úgy, hogy a következő körre kevesebb GPU-t gyártanak.
Az induló készleteknek ehhez nincs már köze, mert az csak az első pár pár hetet határozzák meg. Azok már rég elkeltek.
#49750 Yutani : Ez egy érdekes tényező, de a valóság más. Valójában az a tapasztalat, hogy nem lenne sokkal nagyobb kereslet, ha olcsóbb lenne. Ezért határozzák meg a gyártási mennyiséget úgy, hogy mi az optimális mennyiség. Itt az jelzi a bajt, ha mondjuk egy termék az MSRP ár alá csúszik. Ez akkor történik meg, amikor a raktáridő túlmegy az elfogadható szinten, tehát már inkább szabadulni akarnak a porosodó VGA-któl, amiket nem tudtak eladni, mert egyre nagyobb költség ezeket tárolni. Mert ennek is van költsége, és ha mondjuk valami beragad, akkor pár hétre van attól, hogy ne legyen az eladásán nyereség. Ezért az se jó, ha kevés ideig van raktárban egy termék, mert akkor nagyobb az igény rá, és az sem, ha sok ideig van raktárban, mert akkor nagy a tárolás költsége.
-
Abu85
HÁZIGAZDA
Az MSRP ár megközelítését az határozza meg, hogy egy hardverre mekkora a kereslet. Ha az kielégíthető a legyártott mennyiséggel, akkor bizony az MSRP közelébe fog kerülni az adott VGA igen gyorsan. De ha nagyobb a kereslet, akkor erre nincs esély, mert nagyobb az igény a termékre, mint amennyit meg lehet venni belőle.
-
Abu85
HÁZIGAZDA
válasz
gejala
#49709
üzenetére
Semmi köze a drivernek az architektúra dizájnjához. Azért voltak és vannak driverproblémák, mert ugyanazt a munkát sokkal kevesebb ember végzi az NV-nél manapság, mert a rendszerprogramozók az adatközpontok támogatásával vannak elfoglalva. Ha ma is ott lenne a GeForce driverek mögött a korábbi évek humánerőforrása, akkor ugyanaz lenne a minőségi szint, mint a korábbi években. Ez teljese független az architektúrától, ezt az befolyásolja, hogy mennyi ember dolgozik rajta.
#49707 BerserkGuts : Ez meg egy teljesen független probléma. A GeForce RTX 50-nek nem optimális az az optimalizálás, ami 400-500 millió, játékosoknál lévő hardvernek pont jó. Nyilván nem az 1-2 milliós bázisra fognak dolgozni. Ezzel szemben az NVIDIA tehetetlen.
-
Abu85
HÁZIGAZDA
Ez az RTX 40 és 50 viszony pedig egy másik tényezőből ered. A legtöbb shadert olyan optimalizálással írnak, hogy jól fusson a konzolokon. Na most ezek a konzolok ugyan nem RDNA 2-k, de a wave feldolgozást tekintve az RDNA 2-höz állnak a legközelebb. És ez azért nagyon kellemes, mert van egy olyan működési módjuk, amire optimalizálva, az erre írt shaderek jól fognak futni PS5 és Xbox Series gépeken, Switch 2-n, RDNA1-4-en, GeForce RTX 20-30-40-en, tehát egyetlen egy optimalizálási stratégiával egyszerre lefedsz nagyon-nagyon sok hardvert. Viszont ez a módszer pont nem fog jól futni GeForce RTX 50-en. Ha viszont a Blackwellt célozzák, akkor meg az előbbi rengeteg hardveren nem fut majd jól a shader. Tehát a működést tekintve inkább azt a rengeteg hardvert célozzák, amely több százmilliós felhasználóbázist jelent. Ez sem magának a Blackwellnek a problémája hardveresen, csak annyira sok gépen fut jól az a shader optimalizálási stratégia, ami a Blackwellen nem annyira kedvező, hogy nem túl észszerű lépés 1-2 millió user érdekét 400-500 millió user elé helyezni. Az meg ki van zárva, hogy 300 ezer sornyi shadert kétszer írjanak meg, egyszerűen anyagilag nem kifizetődő.
-
Abu85
HÁZIGAZDA
Annyit még hozzátennék, hogy az nem igazán egy GPU-ból eredő dolog, hogy a 9070 a Borderlands 4, vagy az újabb UE5 motorú játékokban nem "csak" 7%-kal jobb az 5070-nél, hanem ~20%-kal. Itt inkább arról van szó, hogy maga az UE5 küzd egy erős limitációval, ugyanis a Nanite és a Lumen a jelenlegi compute shader paradigmát használva problémás, mivel CPU által kiadott, egymáshoz láncolt különálló dispatch-ekre épül. Ezek papíron ugyanazok gyártónként, de az AMD D3D12 drivere kevesebb többletterheléssel dolgozik, tehát igazából itt csak arról van szó, hogy amikor egy játékot ez a compute shader paradigma limitál a CPU oldalán, akkor a Radeonokat ez kevésbé limitálja. Tehát innen ered a különbség. Nem a hardver a jobb az AMD-nél, hanem a driver működik hatékonyabban. És minél inkább limites ebből a szempontból egy játék, annál nagyobb az AMD driveréből származó előnye.
De pont azért akar az Epic áttérni a Work Graphsra, mert még az AMD hatékonyabb driverével is létezik ez a limitáció, tehát maga a feldolgozási modell jellege a limites. A Work Graphs azért hasznos itt az Epicnek, mert ezzel a GPU önállóan tudja kezelni a függőségekkel rendelkező, egymásra épülő munkafolyamatokat, így nagyon lecsökken a CPU<->GPU szinkronizációk száma, tehát a többletterhelés ugyan létezni fog továbbra is, de a GPU kevesebb megszakítással dolgozik, amivel kevesebb driver- és API-hívás szükséges. Ergo megszűnik az a limit, ami most a nagyon sok CPU<->GPU szinkronizációkból ered.
-
Abu85
HÁZIGAZDA
Ez inkább egy döntés eredménye. Az Epic a múlt évben a Work Graphs felé indult, így arra készítik fel a motort, hogy idővel a Work Graphs egy alapértelmezett funkció legyen. Ehhez pedig a kutatásra használt gépekben Radeont használnak, vagyis egy ideje a döntéseket aszerint hozzák meg, hogy mit tapasztalnak RDNA 3-mal, és ez az RDNA 4-nek is előnyös. Aztán a többi hardverre utólag szoktak optimalizálni, ami még mindig nagyon jó, de nem ugyanaz, mintha már eleve dizájnban is erre terveznének.
-
#49663
Abu85
HÁZIGAZDA
huskydog17
#49661
Abu85
HÁZIGAZDA
válasz
huskydog17
#49661
üzenetére
Ne beszélj csacskaságokat, sehol sem volt megemlítve, hogy Borderlands 4 az NVIDIA hibája.
-
Abu85
HÁZIGAZDA
Ez így is van, de ugye itt alapvetően az a gond, hogy a DirectX 12-re és a Vulkan API-ra a fejlesztők nem tudnak önállóan optimális memóriamenedzsmentet írni. Ez most így persze nem akkora tragédia, mert az AMD-nek van mindkettőre általános menedzsmentre D3D12MA és VMA néven. Több száz játékban hibátlanul működik már. Viszont ez általános menedzsment, vagyis van némi követelmény az egyes erőforrások elérését tekintve, és az AMD a szabványos formát követi mindegyik API-n. Például követelmény, hogy erőforrás a root signature-be ne legyen bekötve. Ez egy hivatalos Microsoft ajánlás. Eközben az NV a saját modernebb eljárásaiban az erőforrásokat mindig a root signature-be köti. Na most a D3D12MA-nak ez nem jó, tehát le kell cseréni egy másik memóriamenedzsmentre. Viszont a Microsoft jó okkal mondja, hogy közvetlenül ne legyen erőforrás kötve a root signature-be, mert nem úgy tervezték az API-t, hogy ezt kezelni tudja, és problémákat okozhat, például akadozást. És ez egy nagyon régi vita az NV-vel, de az NVIDIA hajthatatlan évek óta, és akkor is úgy akarják használni az API-t, ahogy nem ajánlott a különböző problémák miatt. Volt már egyébként a háttérben arról szó, hogy egy új Agility verzió megszünteti a root signature-be kötés lehetőségét, de az meg kompatibilitási problémákat okozna, mert rengeteg szoftver dolgozik így. Emiatt a Microsoft még mindig csak szépen kéri az NVIDIA-t és a többi céget, akik ezt csinálják, hogy ha egy mód van rá, akkor ne legyenek hülyék, és kövessék azt az előírást, amire az API-t tervezték, úgy szép vajsimán, akadásmentesen fog működni a programkód.
-
Abu85
HÁZIGAZDA
Egyrészt rajta vannak, másrészt mindenen akadozik, harmadrészt rohadtul nem egyszerű javítani, mert kikerült a játékból a D3D12MA. És az okozza az akadozást, hogy áttértek egy saját memóriamenedzsmentre, ami több nagyságrenddel rosszabb, mint amit korábban használtak. Viszont a D3D12MA nem volt kompatibilis bizonyos NVIDIA technikákkal, amiket megkapott a játék, és utóbbiért az NV fizetett, hogy benne legyen, úgy is, hogy közben ez a GeForce-okon is akadozást okoz. Nem tud igazából mit tenni a cég, mert rengeteg pénzt kaptak azért, hogy az újítások benne legyenek, csak a D3D12MA ezekkel nem működik. És ennek a javítása hónapokig tarthat, de lehet, hogy évekig. Hacsak nem utalják vissza a pénzt az NV-nek, és nem térnek vissza a D3D12MA-ra.
-
#49631
Abu85
HÁZIGAZDA
Pocoyo.hun
#49629
Abu85
HÁZIGAZDA
válasz
Pocoyo.hun
#49629
üzenetére
Eljut a vevőkhöz, csak Kínába több jut. Nézd meg a GN videóját erről.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#49620
üzenetére
Igazából a Mindfactory és a JPR is igaz. A Mindfactory a PC Gaminget mutatja a saját vásárlói szempontjából. A JPR pedig mindent, ami kijött a gyárból, még azokat is, amelyek Kínába kerültek egy AI adatközpontba.
Nyilván fontos figyelembe venni, hogy ki mit mér. Ki milyen adatra kíváncsi. Ha arra, hogy miből mennyi került ki a gyárakból, függetlenül attól, hogy hova kerültek, akkor a JPR adatja a jobb. Ha arra, hogy a játékosok miket vesznek helyi szinten, akkor ahhoz a Mindfactory adatja van közelebb.
Ugyanez volt a kriptoőrületnél is. Ott is rengeteg eladott VGA-t mért a JPR, csak a játékosok nem láttak belőle egyet sem. -
Abu85
HÁZIGAZDA
válasz
Busterftw
#49611
üzenetére
Az nem számít. A gond az architektúrával van, ami még mindig dedikált regisztereket rak az ALU-khoz. Akármikor is hozod ki a lapkát, akkor is megvan az a hátrány, hogy a konkurens feleakkora GPU-ját célozza csak az adott dizájn teljesítményben. Egyszerűen a tranzisztorbüdzsé nagy részét elviszik a regiszterek. Emiatt a bruttó árrés nem tud egészséges szintet megütni, mert nem rakhatod rá például a B580-ra az 500+ dolláros árat, miközben a gyártás szintjén elhanyagolható mértékben drágább Radeon RX 9070-re az AMD rárakhatja.
Ezt kell megoldania az Intelnek, nem a startok ütemezését.
-
#49610
Abu85
HÁZIGAZDA
huskydog17
#49608
Abu85
HÁZIGAZDA
válasz
huskydog17
#49608
üzenetére
Az Intellel nem tudni, hogy mi lesz. Az új egyezmény az USA-val rákényszeríti őket, hogy tömjék a pénzt a foundry-ba, miközben nehezebb lesz majd eladni a Xeonokat az EU-s kormányzati projekteken. Szóval Lip-Bu Tannak új részlegeket kell bezárnia. Elvileg minden olyan terület veszélyben van, amelynek a bruttó árrése 10% alatti, és az Arc VGA-k alatta vannak. Valószínűleg nem akarják, de újabb áldozatok nélkül nem fogják kihúzni 2029-ig, amikor jön az első termék, ami versenyképes lesz a fő piacon.
-
Abu85
HÁZIGAZDA
válasz
solfilo
#49603
üzenetére
Pedig számítani lehetett rá, hiszen Kína csak GeForce-okat szed szét. Az mindegy, hogy az AMD vezeti a heti Mindfactory eladásokat, meg a hasonló kereskedői listákat, mert az csak a játékosoknak eladott VGA-kat nézi. Kína viszont ezzel szemben jóval több GeForce-ot vesz szétszedésre. Akkor lenne ez máshogy, ha Kína Radeont is szétszedne, és akkor az AMD sem csak a gamingre gyártaná a Radeonokat. Érdemes megnézni a GN videót erről. Három órás ugyan, de nagyon nagy mennyiségű GeForce el sem jut a kereskedőkhöz. A játékosok meg se tudják venni, mert Kína hamarabb elviszi, szétszedi, átdolgozza, majd bedobja valamelyik szerverbe. A VGA-gyártók oldalán ez is eladás. Mindegy, hogy nem játszanak majd vele.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#49539
üzenetére
Próbáltuk eléggé egyszerűen leírni. Nem az volt a gond, hogy nem volt backup, hanem az, hogy hibás lett az adatbázis struktúrája. És ez bármilyen hardverrel előfordulhatott volna, ilyenre előre nehéz készülni. És ilyenkor hiába van meg az adat, a struktúra maga a hibás. A nyers adatok amúgy jól vannak most is, azt kell megoldani, hogy ezeket be lehessen illeszteni más struktúrájú adatbázisba.
-
Abu85
HÁZIGAZDA
válasz
KAMELOT
#49531
üzenetére
Mert a szerver működik, és ami működik az fogyaszt, és a fogyasztásnak ára van. Itt ki lehet számolni, hogy a tipikus munkafolyamaton mekkora lesz ez a fogyasztás, így egységnyi szinten mekkora költség lesz üzemeltetni a szervert. Na most ez Xeonnal több pénz, nem is kicsit.
#49536 : Busterftw : Nem lehet összeomlásra számolni, mert nem várod, hogy megtörténik. Ez nem egy logikus költség. Arra lehet számolni, hogy üzemeltetés mellett mennyibe kerül a fenntartás.
Én PC-n bő fél évig GeForce-ot használtam. Szóval nem ezzel volt a gond. Bár ebben az időszakban többször láttam fekete képernyőt, mint pixelest.
#49532 b. : Én 300-at költöttem PS5-re eddig. És még nem is vettem játékot, mert a PS Pluson jönnek a címek. És még van fél évem a mostani éves előfizetésből. Te azzal a géppel még csak a gépet vetted meg, szoftvert még nem, és a vas maga drágább volt, mint nekem két évnyi szórakozás, miközben még nem szórakoztál semmit.
-
Abu85
HÁZIGAZDA
Ezt én máshogy tapasztalom. Én ugyanannyit játszok, mint régen, de a másfél éves mérlegemet tekintve kb. feleannyit költöttem eddig konzolra, mint anno PC-re. És ez nem csak az én tapasztalatom. Másnak is a konzolt ajánlom, aki csalódott a PC-ben, és ugyanazt mondják, hogy sokkal olcsóbban kijönnek most. Sőt, több játékon is játszanak, mert előfizetnek a PS Plus-ra, ahogy én is.
-
Abu85
HÁZIGAZDA
válasz
arabus
#49524
üzenetére
Az az Epyc nagyon drága volt. Elsődlegesen azért, mert abban a kategóriában egyszerűen nem volt ellenfele. Emiatt választási lehetőségünk sem volt igazán, mert szükségünk volt egy bizonyos teljesítményre, méghozzá amiatt, hogy csúcsidőben sok a látogató. Vagyis vettük azt a procit, ami el tudta viselni a terhelést. Hidd el, hogy mi örültünk volna a legjobban, ha van hasonló paraméterű Xeon, de nem volt, és ami volt az lassabb volt, és üzemeltetni is drágább lett volna. Ez a baj, amikor egy piacon nincs verseny. Csak egy lehetőséged van, az is elég drágán.
A nép játszani akar, és ott rengeteg lehetőség van. Én például rég váltottam már konzolra, mert egyszerűen sokkal-sokkal olcsóbb, miközben az élményt is jobbnak érzem, mert nem kapom meg a sok PC-s szívást a shader fordítással, stb.
-
Abu85
HÁZIGAZDA
Mondjuk a dolog abból a szempontból mindegy az NV-nek, hogy az eladás az eladás. Nekik aztán teljesen lényegtelen, hogy az eladott GeForce-ok 90, 50, vagy csak 10 százaléka jut a játékosokhoz. Sőt, alapvetően minél kevesebb jut a játékosokhoz, annál több jut AI-ra, amiért az emberek manapság többet fizetnek, tehát az NV anyagilag alapvetően azzal jár jól, ha a GeForce-ot nem játékra veszik.
-
Abu85
HÁZIGAZDA
Azt nem fogja tudni megmondani az NVIDIA. Valószínűleg ők sem tudják pontosan, hiszen nagyot nőttek a szingapúri eladások, ahonnan ugye történik a VGA-k csempészése Kínába. De arról az NVIDIA sem tud pontosan, hogy a szingapúri eladásoknak mekkora része került a játékosokhoz, és mekkora része lesz csempészárú Kínába.
Ugyanaz a probléma, mint a cryptomining esetében, ott sem tudták a cégek, hogy az eladások mekkora része gaming és mekkora cryptomining. De utólag kiderült, hogy volt olyan, amikor utóbbi a 90%-ot kitette.
#49488 bertapet11 : Éppenséggel a kettő nem feltétlenül zárja most ki egymást, mert valószínű, hogy a HUB, a MLID, a GN, meg a többiek az asztali sorozatról beszélnek, miközben több gyártó is mondta a nyáron, hogy az 5060-ból még gyártási szinten is 70%-ban Laptop modellek készültek, és az NV az asztali, illetve a Laptop verziókat egybeveszi. A notebookgyártók pedig rengeteg 5060-at vettek az iskolakezdési notidömpingre, hiszen másképp nem tudják összeszerelni a notikat. De valóban, pontosabban kellene fogalmazni, mert hajlamosak vagyunk mindannyian csak az asztalira koncentrálni, holott a mobil már nagyobb piac.
-
Abu85
HÁZIGAZDA
Ez játéktól függ, de az újabb driverekkel az AMD már nem csak az RT shaderekre alkalmazza például a dinamikus regiszterallokációt, hanem az egyes címekben bizonyos compute shaderekre is. Tehát amíg a többi hardvert limitálja a kihasználtságlimit a statikus regiszterallokáció által, addig az RDNA 4 képes úgy betölteni az adatokat a regiszterbe, hogy tényleg csak a használt adatok legyenek ott, így a nagyon gyilkos compute shaderek az RDNA 4-en sok konkurens wave mellett futnak. Ez egy shaderre lebontva akár +700-900%-ot is jelenthet, ami a teljes képkocka szintjén simán hozhat +10-20%-ot, ha a shader tényleg megterhelő volt. Erről az AMD nem sokat árul el, de elvileg tipikusan azokat a shadereket célozzák az egyes játékokban, amelyek a mai GPU-knál a minimális konkurens wave-re kényszerítik a multiprocesszort. Ez lehet akár azért, mert az adott shader nagyon terhel, vagy azért mert rosszul van megírva. Igazából mindegy miért van, a dinamikus regiszterallokáció mindkettőt hardveresen korrigálja. Ha pont ott van a teszthelyzet, ahol ez a shader lefut, ott sokat gyorsul az RDNA 4, mert a többi GPU-n ugyanaz a shader a memóriaelérésre vár, míg RDNA 4-en van konkurens wave, amit futtatni lehet. Viszont ezt nem minden címre engedélyezi az AMD a deadlock kockázat miatt, de nem kizárt, hogy egy-egy játékban egy-egy shadert kiválasztanak, hogy dynamic VGPR módban fusson.
A másik dolog, amit az AMD csinál az általánosabb, és nem kell specifikusan flaggelni rá a drivert, hogy bizonyos kiválasztott shaderek máshogyan fussanak. Az RDNA 4 GPU-k memóriaalrendszere lehetővé teszi, hogy a multiprocesszorok ne sorosan, hanem dinamikusan, az elérhetőség sorrendjében kapják meg a memóriából igényelt adatokat. Ezt az AMD RT-vel prezentálta, mert erre fejlesztették a képességet, de bizonyos szituációkban, RT nélkül is nagyok hasznos fícsőr az Unreal Engine 5-ben, különösen az extrém magas poligonszámú, nanite-os jelenetekben, illetve Lumen és Virtual Shadow Maps alkalmazásakor. Az ok pedig az, hogy szoftveres comute shader raszterizáló alapesetben nagyon sok cache miss-be futhat, de az OOO memóriaeléréssel ezek gyorsabban lesznek kezelve. A Lumen esetében a sok rengeteg ray tracing query-n segít, míg Virtual Shadow Maps során nagyon sok a memory fetch, ami általánosan stallt eredményez a shaderekben, de ezt is sokkal gyorsabban lekezeli az OOO memóriaelérés.
Nagyjából ezek azok a dolgok, amelyekbe egy UE5-ös játék esetlegesen belefuthat, és ilyenkor az RDNA 4 képességei sokkal hatékonyabban kezelik a helyzetet, mint bármelyik más GPU, mert más dizájn még nem rendelkezik hatékony dinamikus regiszterallokációval vagy OOO memóriaeléréssel.
Az valószínűleg puszta véletlen, hogy az UE5 pont olyan irányba fejlődik, ami az RDNA 4 képességeinek éppen optimális. Az AMD ezeket a funkciókat RT-re fejlesztette, de mázlijuk van azzal, hogy az Epic arra viszi a motort, hogy RT nélkül is hasznot hozzanak.
-
#49443
Abu85
HÁZIGAZDA
huskydog17
#49430
Abu85
HÁZIGAZDA
válasz
huskydog17
#49430
üzenetére
Nem minden játékra lehet ráengedni a path tracinget. Valaminek a részletessége annyira magas, hogy messze túlmutat annál, amit egy path tracinges játéktól kapsz. Erre sokkal gyorsabb a Lumen.
-
#49415
Abu85
HÁZIGAZDA
huskydog17
#49413
Abu85
HÁZIGAZDA
válasz
huskydog17
#49413
üzenetére
Nem, ez szimplán a driver miatt van így. A játék fejlesztői szerint nem tudnak vele mit kezdeni, mert abban a környezetben, ahogy használják az UE5-öt kisebb többletterheléssel működik az AMD drivere, tehát több a szabad CPU-idő, amin csinálhatnak valamit. Ezért gyorsabbak a tipikus UE5 erőviszonyhoz viszonyítva a Radeonok, és a kisebb felbontás felé haladva gyorsulnak, mert erősebb kezd lenni a CPU-limit. A Work Graphs segítene valamennyit, viszont annak az az ára, hogy nem indulna el a játék csak az elmúlt két generáció VGA-in. Ez most még nem éri meg. És a Work Graphs is inkább az AMD-nek kedvez, mert jobban gyorsulnak tőle, mint a többiek.
-
#49375
Abu85
HÁZIGAZDA
huskydog17
#49372
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. -
#49370
Abu85
HÁZIGAZDA
huskydog17
#49368
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.
-
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.
-
#49360
Abu85
HÁZIGAZDA
Alogonomus
#49359
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.
-
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á.
-
Abu85
HÁZIGAZDA
Ezzel arra akartam rávilágítani, hogy nem olyan extrém dolog ez, mert minden kormány csinálja.
Szerintem a Foundry-t nem hagyja az USA kinyúlni. Ha mást nem, akkor végső soron kérik a függetlenítést, majd vásárolnak benne 49,9%-os részesedést. Az Intel tervezői része nem fogja érdekelni az USA-t. Úgy lesznek vele, hogy adjanak el mindent, amit lehet a Foudnry-ért.
#48379 b. : Ez a Kína támadja Tajvant dolog még mindig képlékeny. Elszállhat az agya Miximackónak, de logikusan átgondolva, ha belemennek ebbe, akkor azon Kína is veszít, és annyira ingatag lábakon állnak, hogy be is tudnának csődölni egy ilyen támadástól.
Az USA szempontjából fontosak ezek az elvárások az Intel felé. Őket a Foundry érdekli, és az elvárás világos, az Intel adjon el mindent, hogy megmaradjon a Foundry. Még egyébként az sincs kizárva, hogy valakire rákényszeríti az USA az Intel tervezői részlegének felvásárlását. Van pár amcsi cég, amelyeknek van keresztlicencük az Intellel, például AMD, Microsoft, Marvell. Ha minden kötél szakad, akkor kormányzatilag kényszerítik az egyesülést, és cserébe kiírnak egy sok tízmilliárdos tendert, hogy legyen értelme a cégnek megvenni az Intelt. A Microsoft persze necces, mert túl nagy hatalma lenne, az AMD-nek nincs szüksége az Intelre, de a Marvell esélyes, mert nekik még hasznuk is lenne belőle. És itt fontos, hogy például a Marvellnek nem kellene tárgyalnia az AMD-vel a licencről, tehát az AMD sem tudná torpedózni az üzletet. A kisebb licencekről úgyis meg fognak egyezni, mert azok fontosak az AMD-nek is.
-
Abu85
HÁZIGAZDA
A Foudry-nak adnak adófizetői pénzt. Nagy különbség. Az Intel ezt a pénzt nem használhatja fel szabadon, meghatározott dolgokra kell költeni. Ilyet pedig egyébként minden kormány csinál. A TSMC-t is támogatják például Japánban a gyárépítést tekintve. Ebben az USA nem egyedi. És ez sokkal inkább reakció arra, hogy ha Kína is adófizetői pénzzel tömi ki a cégeit, akkor az USA is így játszik, csak átláthatóan és szabályozottan teszik.
-
Abu85
HÁZIGAZDA
Konkrétan követelményei vannak az USA-nak ebből az Intel felé. Tehát elvárják, hogy az építés során mennyi munkaerőt foglalkoztassanak, stb. Tehát ez nem csak szabadon felhasználható pénz, hanem van elvárás is.
A TSMC-nek is adnak így pénzt. Hasonló elvárásokkal. Ilyet csinál Japán is, az EU is, stb. Ez nem egyedi. Nyilván vannak elvárások, amiket a pénzért hozni kell.
-
#48321
Abu85
HÁZIGAZDA
huskydog17
#48319
Abu85
HÁZIGAZDA
válasz
huskydog17
#48319
üzenetére
Tudom, visszaportoltak képességeket, de nem portolták hozzá vissza az arra szabott RHI-t. És ez így tök jól hangzik, csak nem véletlen, hogy az Epic az egyes képességeket újabb verziókhoz köti.
-
#48315
Abu85
HÁZIGAZDA
huskydog17
#48314
Abu85
HÁZIGAZDA
válasz
huskydog17
#48314
üzenetére
Maga az UE5 régebbi verzió, ez nagyban akadályozza az egyes lehetőségeket. Azt update-elni pedig nem kis munka, hónapokig tarthat majd. Szóval sok dolgot úgy fognak hagyni, főleg grafikailag.
-
#48313
Abu85
HÁZIGAZDA
huskydog17
#48312
Abu85
HÁZIGAZDA
válasz
huskydog17
#48312
üzenetére
Inkább az adhatja a TSR előnyét, hogy azt nem kevés extra adattal etetik, és ezeket a többi felskálázó nem kapja meg. Nem tudni, hogy miért, annyira nem érezhették fontosnak a fejlesztők ezeket.
-
Abu85
HÁZIGAZDA
UE5-nek lehet köze hozzá. A traversal stutter jellemzően akkor jelentkezik, ha egy új zóna betöltése történik, és ebből a szempontból valamivel kedvezőbb, ha az eszközlokális memória egyetlen type-ban van benne, ahogy a Radeonon. Az NV-nél egy flag alatt az eszközlokális memória két type-ra van osztva, vagyis a kezelés szempontjából teszem azt egy 8 GB VRAM-os GeForce VGA-n két kisebb menory type-ot használhat az API-ban. Ez nagy különbséget nem okoz nyers teljesítményben, de az olyan motorokban, mint az UE5, ami eleve érzékeny ezekre a traversal stutter dolgokra a zónák betöltésénél, okozhat némileg több akadást, ami a frametime-ot valamelyest ronthatja.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#48292
üzenetére
Driverest. Ez úgy van, hogy az Intel kivette a fast path-okat a kontroll logikából, és ezzel azt is eldöntötték, hogy a DirectX 11-et emulálják, így nem készítenek rá támogatást. Na most ezzel az volt a baj, hogy iszonyatosan lassú volt. Konkrétan olyan címek nem futnak 30 fps-sel, amelyek amúgy mennek több éves IGP-ken. Erre hoztak egy korlátozottabb natív DirectX 11-es meghajtót, majd a fontosabb címeket elkezdték átrakni arra, de ott meg hiányzik a fast path a hardverből, így nem skálázódik jól a rendszer a legtöbb natívan támogatott játékban. Csak azok működnek jól, amelyek deferred contextre vannak írva, ebből meg ugye marha kevés van DirectX 11-en. Ezt viszont már sosem fogják másképp csinálni, mert a DX12 és a Vulkan felé megyünk, de a hardver és a szoftver hiányosságai miatt a retro gamingre nem ajánlott a rendszer, mert sosem tudhatod, hogy melyik emulált játékba futsz bele, és ott tényleg 3-6-9x lassabb lesz a sebesség, mint lehetne. Valahol viszont hasznos volt meglépni, mert rengeteg tranyót spórolnak vele, és mindössze kb. 100 játékra terveztek natív támogatást DirectX 11-hez, tehát sokkal olcsóbb karbantartani a meghajtót, mint például az AMD-nek és az NV-nek, akik minden DirectX 11-es játékot natívan futtatnak. Meg önmagában az emberek erről nem is tudnak, azt hiszik, hogy ha vesznek egy modern hardvert, akkor nem lesz majd baj a 2010-2015 környéki játékokkal. Hát lesz, ha emulálva fut éppen az adott régi cím.
-
Abu85
HÁZIGAZDA
válasz
paprobert
#48290
üzenetére
Az nem az összes cache.
Az Intel már az első Arcból kivette a fast path áramköröket a régi API-kra, ebből sokat spórolnak. Cserébe nagyon-nagyon lassan fut a DirectX 11-es játékok többsége. Ugyanezt az AMD és az NV is meg tudja majd tenni, de ennek ez az ára. Most még nem olyan gyorsak az IGP-k, hogy ez vállalható legyen. Ez egy nagyon paradox választás, mert azt hinnéd, hogy elég erős lesz a hardver a 10 éves játékokra, de azok azért gyorsak a GPU-kon, mert vannak különböző fast path áramkörök a kontroll logikában, plusz van rájuk natív támogatás.
-
Abu85
HÁZIGAZDA
válasz
paprobert
#48288
üzenetére
Nem számolják bele a 8+8 MB cache-t, ami kell a működéshez. Erre van tervezve a GPU, hogy azok a cache-ek ott vannak. Az RDNA 3-hoz nem kell ekkora cache. Elég 2 MB.
Ezen fog változtatni az Xe4, hogy nem kell óriási cache, és nem kell lokalitási elvre optimalizálás, hogy működjön a dizájn. Emiatt közelebb kerül az egész ahhoz, ahogy az AMD és az NV GPU-k működnek.
A másik jelentős különbség az a GPU-k etetése. Az AMD és az NV még ma is beépíti azokat a fast path módszereket a hardverbe, amelyek szükségesek a DirectX 11-es címek gyors futtatásához. Az Intel ezeket már teljesen kihagyja. Emiatt sokkal egyszerűbb az Arc kontroll logikája, mert el lehet távolítani a specifikusan DirectX 11-re szabott adatutakat. Ennek az előnye, hogy kb. 90%-ot spórolnak kontrol logika szintjén a tranzisztorokkal. A hátránya, hogy régebbi API-kkal nem versenyképes a dizájn, és nagyon sok teljesítmény marad benne bizonyos alkalmazásokban. Ez amúgy előnye az Intelnek, hogy nekik nincs összehasonlítási alapjuk az Arc előttről. Nem fogják felróni nekik, hogy egy régebbi DirectX 11-es cím az új IGP-ken 3-6x lassabb, mint a régin. Az AMD-nek és az NV-nek ezt felrónák. Mert kb. ennyi lassulással kell ezen áramkörök nélkül számolni. Nem véletlen, hogy az Arc meghajtónál 200-300%-os gyorsulásokról voltak hírek egy-egy játéknál, amire írtak direkt támogatást. De kb. van több ezer DirectX 11-es cím, és ebből fehérlistás úgy 100-200. Tehát a többség még mindig emulálva fut.
-
Abu85
HÁZIGAZDA
A cache-t a dizájn igényeihez tervezik. Szóval ez nem olyan egzakt dolog, hogy ha az egyikben ennyi van, akkor a másikba is kell. Az Intel azért épít sokkal több cache-t a dizájnba, mert sokkal kevesebb wave-vel dolgoznak, így nekik sokkal ritkább, hogy át tudják lapolni a memóriaelérés késleltetését. Az AMD dizájnja sokkal jobban reagál ezekre a helyzetekre.
Alapvetően ezért van az is, hogy bizonyos játékokban nagyon szar az Xe2, míg bizonyos játékokban nagyon jó. Általában ott jó, ahol a játék shaderei úgy vannak megírva, hogy van alkalmazva némi optimalizálás a lokalitási elvre. (szerencsére a legtöbb AAA cím már ilyen, mert van némi haszna mindegyik dizájnon) Ha nincs, akkor ott nagyon rosszul viselkedik az Xe2, mert hasztalanná válik benne a sok cache.
Az AMD-féle RDNA3 másképp működik, sokkal kevésbé érzékeny arra, hogy milyen optimalizálást alkalmaz egy shader, inkább csak az számít neki, hogy jó legyen a regiszternyomás, és ha az jó, akkor igazából a sebesség is jó. Az Xe2 legalább négy-öt külön tényezőre érzékeny még, és ha az egyik nem jó, akkor a sebesség sem lesz jó.Ez majd az Xe4-ben fog megváltozni, mert az már sokkal inkább hasonlítani fog azokhoz a GPU-dizájnokhoz, ahogyan tervez az AMD és az NVIDIA. Ezáltal nem kell sokkal nagyobb lapkaterületet használni egy adott teljesítményszint eléréséhez, ami az Intelnek egy elég nagy baja jelenleg, mert ki kell tömni a dizájnt cache-sel, hogy működjön, és akkor is csak akkor működik, ha a program erre van optimalizálva.
Pontosan ez volt például a gond a Starfield esetében. Annyira specifikusan csak a regiszternyomásra optimalizáltak, hogy az Arc sebességét máig nem tudták összerakni.
-
Abu85
HÁZIGAZDA
Nem kell. A gaming a teljes kliensnek csak egy picike szelete. Ráadásul folyamatosan egyre kisebb.
Hidd el, Pat Gelsinger nem azért alszik nehezen, mert nem veszik a gémerek az Intel procikat, hanem azért, mert a Foundry égeti a pénzt, és közben a nagyvállalati szférában nem mennek a cuccok. Ha utóbbi menne, minden rendben lenne, még a gémereket is magasról leszarná Pat, mert úgyis kevés pénz van bennük.
-
#48144
Abu85
HÁZIGAZDA
huskydog17
#48141
Abu85
HÁZIGAZDA
válasz
huskydog17
#48141
üzenetére
Mindhárom gyártó szponzorálta ezt a címet igen sok pézzel. AMD-n csak azért gyorsabb, mert a Call of Duty-n dolgozó stúdiók évek óta kizárólag AMD hardveren fejlesztenek. Ez önmagában nem lenne gond az Intel és az NVIDIA szempontjából, de annyira specifikus optimalizálást kapnak az AMD hardverek, hogy az a pár hétnyi optimalizálási munka az Intel és az NV hardvereken ezt nem tudja behozni.
-
#48138
Abu85
HÁZIGAZDA
huskydog17
#48134
Abu85
HÁZIGAZDA
válasz
huskydog17
#48134
üzenetére
De 67% nekik is a Quality, csak van valami bug, ami miatt nem skálázódik a sebesség. Nem tudják, hogy hol. Ők már a DirectSR implementációt használják, így gyanítják, hogy ott van valami gabesz. A Microsoft azt javasolta nekik, hogy használjanak újabb Agility verziót, hogy el tudják érni natívan az FSR-t, mert az garantáltan nem ront a sebességen, egyébként meg a driverek a ludasak, és nem tudják program oldalról megoldani. Viszont az Intel és az NV szerint a játék a hibás, és a driverek jók. Az AMD meg azt javasolja, hogy implementálják az új Agility-vel natívan az FSR-t, mert azzal nem is megy ki a program a driverig. Itt állunk most. Kb. mindenki egymásra mutogat, és mivel nincs elérhető profilozó az ilyen jellegű, új API-t használó munkafolyamatra, nem tudják eldönteni, hogy kinél van a hiba.
Valószínű egyébként, hogy valami az Agility betöltőmoduljában van, mert az azért eléggé durva lenne, hogy mindhárom cég drivere ugyanazt a hibát tartalmazza. Csak a Microsoft nem akar ennek a körmére nézni, mert nekik az lenne az érdekük, hogy a DLSS-t és az XeSS-t is natívan tudják implementálni, és ha elkezdenek jönni azok a játékok, amiknél az FSR skálázódik, de a DLSS és az XeSS nem, akkor az NV és az Intel esélyes, hogy ugyanúgy odaadja a kódot natív Agility implementációra. És akkor nem is kell a driver tovább. Szóval elképzelhető, hogy az MS tudja hol a gond, csak addig akarja taknyosra szopatni a renitenseket, amíg nem ugrálnak a kedvük szerint. És alapvetően az MS-nek haszna lenne a natív implementációból, mert akkor azokat tudnák majd szállítani Xboxra is.
-
Abu85
HÁZIGAZDA
Az tényleg létezik. Csak az a kérdés, hogy kell-e a gaming, és jelenleg úgy néz ki, hogy Pat elengedte, mert nem tartja fontos piacnak.
A Lunarral eleve nem mennek semmire, mert csak olcsón veszik meg a gyártók, és nem is készül belőle sok. Így nem hasznos fejlesztés. A Panther nagyobb mennyiségben készül majd, és nagyobb is lesz rajta a haszon.
-
Abu85
HÁZIGAZDA
A Pather Lake-ből eleve nem lesz nagyobb dizájn. A különbség annyi lesz, hogy visszamegy a Lunar Lake-ről a memória az alaplapra. A Lunar legnagyobb gondja, hogy alapvetően túl drágának tartják a gyártók a processzort, annak ellenére is, hogy a memória ott van a tokozáson. Egyszerűen a memóriagyártókkal kötött egyedi megállapodásaik így nem működnek. Az Intel pedig azon az áron nem tartja ezt kifizetődőnek, amennyiért a gyártók megveszik tőlük.
A Nova Lake inkább 2027-es fejlesztés. Addig az S és a HX vonalon Arrow Lake lesz.
Ami jöhet 2025-ben az a Bartlett Lake-S, de az nem biztos, hogy érkezik, mert az csak desktop, és csak LGA1700. De abban lenne 12 P-mag és nem lenne benne kis mag, illetve újra működne a Hyper-Threading is. Viszont ez nem tetszik a menedzsmentnek, mert azt az üzenetet közvetítené, hogy a hibrid téves irány, és már lengetik a kaszát. Jelen pillanatban sokkal hasznosabbnak tartják elengedni a gaminget, mint egyedi dizájnt fejleszteni ide.
-
Abu85
HÁZIGAZDA
válasz
gejala
#48060
üzenetére
A Lunar Lake az nagyon kis részben felel majd az eladásokért. Az egy prémium termék, ami kb. ha 5-10%-a lesz a teljes mobil eladásoknak. Ezért nem lesz közvetlenül utódja, mert már nem éri meg a piac törpe szeletéért külön dizájnt tervezni, mert a pénzt viszi, de kevés a direkten realizálható nyereség rajta. Sokkal inkább fog a mobil eladásokért fellelni az érkező Raptor Lake és Arrow Lake felhozatal, ami jön a Core 200 sorozatba.
Ugyanígy az AMD-nél is kisebb részben felel majd az eladásokért a Strix Point. Sokkal inkább a meglévő Hawk Point és az érkező Kraken Point adja majd az eladások zömét. Bár az valószínű, hogy a Strix Pointnak százalékosan nagyobb szerepe lesz az AMD-nél, mint a Lunar Lake-nek az Intelnél, de ez csak azért van, mert jóval nagyobb területet fed le a piacból.
-
Abu85
HÁZIGAZDA
A szoftver is egész jó, de van némi különbség az Intel és az AMD drivere között.
Explicit API-val az AMD egy PAL-on keresztül futtat mindent, tehát gyakorlatilag a teljesítménykritikus részei a drivernek nem különválasztottak, hanem minden PAL-on fut, és ahhoz van egy ICD rendelve, hogy kezeljék az eltérő explicit API-k eltéréseit. Ilyen formában a Vulkan és a DirectX12 ugyanazon a teljesítménykritikus kódbázison fut.
Az Intel nem így csinálja, hanem eleve van két teljesen eltérő implementáció a két explicit API-ra, továbbá még a DirectX 12-höz még vannak eltérő performance kódutak. Tehát effektíve az Intelnek nincs egységes implementációja, hanem DirectX 12-ben két-három performance layerből választják az adott játéknak megfelelőt. Ezért van az, hogy valamelyik játékban nagyon szar a teljesítmény, valamelyikben pedig nagyon jó. De ez nem igazán szoftverhiba, mert koncepcióból csinálják így, úgy van felépítve a driver, hogy több kódút legyen, és majd a készülő játékot elemezve döntik el, hogy mit fognak belőle használni. Ez is működőképes, csak kellene hozzá 3-4x nagyobb humánerőforrás, hogy ezt karban is tudják tartani, mert ugye van egy jó teljesítményű implementáció, és ha azzal egy adott cím nem jó, akkor vannak a fallbackek, amit viszont nem optimalizálnak, mert nincs rá elég emberük. De ettől a szoftver maga jó, csak nagyon kevés programozójuk van ahhoz, hogy egy ekkora kódbázist minden szempontból karbantartsanak.
Ugyanez van egyébként a DirectX 11-es implementációnál is, csak más okból. Ott van egy emulált kódút, és egy natív. A natív teljesítménye nagyon jó, de ha nincs fehérlistán a játék, hogy a natívon fusson, akkor az emulálton fog futni, és ott meg -150-250% teljesítmény vár. De ez nem klasszikusan a szoftver hibája, mert a ráengedett kódúton olyan gyorsan fut, amennyire csak lehet, csak egyszerűen nagyon masszív erőforráshiányban van az Intel, hogy minden kódút gyors legyen.
Lényegében ez egy koncepcionális eltérés. Az AMD-nek az összes támogatott grafikus API-ra van összesen 3 kódútja a driverben a teljesítménykritikus részt tekintve. Az Intelnek ugyanennyi API-ra van legalább 10. És ezzel nem lenne gond, ha háromszor több programozó dolgozna ezeken, de például az Intel driveres csapata kisebb az AMD csapatánál. Tehát a szoftver itt maga jó, csak nincs mögé rakva az a humánerőforrás, amivel minden kódút karbantartható lenne.
-
#47904
Abu85
HÁZIGAZDA
gainwardgs
#47896
Abu85
HÁZIGAZDA
válasz
gainwardgs
#47896
üzenetére
Azok a dolgok hiányoznak, amikre a PS-en ID Buffer van használva, mert ilyen megoldás nincs a PC-s API-kban. Ezek nem lettek átírva, hanem ki lettek vágva.
-
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#43575
üzenetére
A TSMC-nek csak baja lenne az AMD-ből. A TSMC üzleti modellje épül arra, hogy mindenkinek ugyanannyi esélye van gyártókapacitást szerezni. Aki többet fizet érte, az viszi. Ha megvennék az AMD-t, akkor a TSMC az ügyfelei konkurense lenne. Az egész üzleti modelljük felborulna azzal, hogy maguk versenyeznének a partnereikkel. Ezen sokkal többet veszíthetnek, mint amennyit nyerhetnek. Ráadásul tényleg marha sok pénzbe kerülne az AMD és a Xilinx együtt. Én nem hiszem, hogy 200 milliárd dollár alatti ajánlatot meghallgatnának.
-
Abu85
HÁZIGAZDA
Most veszik meg a Xilinxet, de el akarják adni magukat, világos.
Mellesleg, ha lenne sütnivalójuk a versenyhatóságoknak, akkor nem engednék az AMD-Xilinx üzletet.Egyébként megvehetik őket, de jelen pillanatban iszonyatosan komoly kiadás lenne. Az AMD-Xilinx kombinációra 200 milliárd dollár alatt nem hallgatnának meg ajánlatokat. Annyiért meg, hát... azért ez marha nagy költség ám.
-
Abu85
HÁZIGAZDA
Igen, de a GPU scalinget ide belekeveritek (jó nem pont te, hanem más
). Ez nem egy csodafícsőr a driverekben. Tényleg nem való annál többre, minthogy, ha a monitorban nincs saját skálázó, akkor nem lesz kurva szar a natív felbontás alatti kép. Szar lesz, de kurvára. Az, hogy valaki ezt akarja erőltetni driverből egészen szürreális, hiszen egyfajta vészmegoldásnak számít, nem egy általánosan alkalmazandó dolognak. Ha ez tényleg működne, akkor az AMD és az NV már rég teleplakátolta volna a médiát, hogy ezt használjátok a játékokba épített res. scale helyett.
-
Abu85
HÁZIGAZDA
Szerintem az a baj, hogy kicsit kevered a fogalmakat.
A GPU skálázás az a hardverben egy fixfunkciós blokk. Az Intelnek, az AMD-nek és az NV-nek is van ilyen, és mindegyik Lanczos skálázást alkalmaz. A filter az maga az élesítő. Ez is van az Intelnek, az AMD-nek és az NV-nek is. Persze különböző shaderek, de ezek alapvetően az ALU-n futnak, csak nem szabványos shader nyelvben vannak írva, hanem a driver absztrakciós nyelvén.Egyáltalán nem egyedi tehát a gyártóknál a GPU skálázás a hardveres blokkal, illetve az élesítés a driver specifikus shaderével. Mindenki tudja ezt, ami miatt nem reklámozzák, hogy irtó szar minőségű eredményt ad, ahhoz képest, mintha egy játékban kérnél mondjuk 70%-os resolution scale-t, és arra raknál élesítést akár a driverből, de inkább a játékból. Ettől függetlenül lehet használni, akármelyik gyártó driverével, csak tényleg marhára szar lesz a minőség, és kapsz egy rakás ringing képhibát.
Az FSR-nek a Lanczos egy töredéke. Nem emiatt működik, hanem az élrekonstrukció miatt.
A grafikai eljárások egyébként ritkán teljesen újak. Valamire épülnek, és azokat egészítik ki lényeges újításokkal. De ettől a gyártó nyugodtan mondhatja rá, hogy házon belül készült, mert vettek egy alapot, amin elindulnak, és csináltak egy házon belüli új eljárást. -
Abu85
HÁZIGAZDA
Alexander Battaglia írt hülyeséget. A Tom's Hardware csak kontroll nélkül átvette. Nyilván így sem valami jó döntés volt, hiszen megnézhették volna a forráskódot, de az ő részükről a hamis információ inkább lustaság, mintsem tudatos.
Az AMD-nek is van a GPU-jában Lanczos skálázója. Még az Intelnek is. Több évre visszamenőleg igaz az a megjelent GPU-kra. Az, hogy ezt 2021-ben fedezi fel valaki, hát külön vicces.
Az AMD ezt házon belül fejlesztette. A Lanczos az egy kiváló általános skálázó algoritmus, de van egy rakás olyan probléma vele, amiért nem optimális valós idejű számításra, és nem kevés képi hibát is generál. Az AMD vette az alapalgoritmust, és felgyorsították valós idejűre, emellett leszámoltak a képi hibákkal az élrekonstrukció által. Utóbbi a fontos eleme az FSR-nek. A Lanczos csak felskáláz, de a minőséget a élrekonstrukció hozza vissza, és az RCAS teszi teljessé az eredményt. Ezt nem tudod driverből alkalmazni, mert a GPU-k beépített skálázójában nincs semmi élrekonstrukció, az túl bonyolult lenne, illetve a külön aktiválható élesítés nem a tone mapping után történik meg, így olyan post-process effekteket is elkezd élesíteni, aminek ez árt. Arról nem is beszélve, hogy a LOD-bias sincs hozzáigazítva az eredményhez.
Be tudod kapcsolni az AMD és az NV driverekben is az élesítést, dobhatsz be GPU-s skálázást is, nem nagy kunszt az sem, ott van régóta a hardverekben és a driverben, de megközelíteni sem tudod ezekkel az FSR minőségét. Ha meglehetne tenni, akkor az AMD és az NVIDIA is ezt ajánlaná a külön játékokba építhető felskálázó eljárásaik helyett. Sőt, a GPU skálázás miatt egy rakás ringing képhibát is kapsz. Ezért nem hallod sem az AMD-től, sem az NV-től, hogy ilyet csinálj. Tudják ők, hogy rosszabb lesz a minőség, mintha a játékban kérnél skálázást és élesítést.
-
#43558
Abu85
HÁZIGAZDA
Petykemano
#43557
Abu85
HÁZIGAZDA
válasz
Petykemano
#43557
üzenetére
Nem volt bekészítve. Szeretem amikor valaki hülyeséget állít, és a média átveszi. Ezekre gyorsan meg lehet írni a cikkeket.
-
Abu85
HÁZIGAZDA
Egyáltalán nem használja az NVIDIA szűrőként a Lanczost. Mint írtam a GPU-k nagyon nem szeretik a gyökvonást és a trigonometrikus függvényeket. Ennek az az oka, hogy ezt a fő FP32-es ALU-k nem támogatják. Egy mai tipikus GPU egy gyökvonást 16-64-szer lassabban tud elvégezni, mint egy alapműveletet. Ezért tudta az AMD a Lanczost 20-30-szorosára gyorsítani a saját közelítésre használt egyenletükkel. Egyszerűen már nem a speciális ALU-kat használják, hanem a fő ALU-kat, amikből sokkal több van a GPU-kban. Ez nyilván architektúrafüggő, némelyik hardveren az AMD algoritmusa akár 70x gyorsabb is lehet, mint a tradicionális Lanczos.
Amiről a Lanczos szóba került az a GPU scaling a driverben. Ez sok-sok éve része a Radeon és a GeForce drivereknek is. Ez a beállítás egy fixfunkciós blokkot ér el a GPU-kban, ami Lanczos skálázást kínál, ezért nem lehet minden hardveren aktiválni. De ezzel a Lanczos tipikus képi hibái is megmaradnak, szemben az FSR-rel, ami nem csak Lanczos, így például FSR-nél a ringing errorral nem kell számolni.
Jó lenne, ha az FSR minősége és sebessége hozható lenne driverből, de sajnos ez a jelenlegi képfeldolgozási futószalagok mellett lehetetlen. Ezt muszáj játékba építeni, pont azért, hogy eltüntesd az alapeljárások tipikus képi hibáit.
-
#43540
Abu85
HÁZIGAZDA
Petykemano
#43538
Abu85
HÁZIGAZDA
válasz
Petykemano
#43538
üzenetére
Semmi. Ugyanonnan veszik a GDDR6-ot. Az a hír kamu, hogy drága a GDDR6.
-
Abu85
HÁZIGAZDA
Na most a leépítés nem valószínű, mert az ARM azért elég sok lábon áll. Nyilván a szervert nem feltétlenül kell annyira erőltetni, mert az sok pénzt visz, és gyakorlatilag semmit sem hoz vissza a 0% közeli részesedéssel. Ezt vagy elkezdik jól csinálni, vagy hagyni kell a fenébe. És a jól csinálás alatt azt értem, hogy elkezdenek alulról építkezni, hogy 10 év múlva legyen esély az első 1-2% megszerzésére az x86/AMD64 ellen. Enélkül ez pénzkemence. Az NVIDIA-nak is az lesz, de az ő pénzük, úgy égetik, ahogy akarják.
A brit székhelyet nem érdemes felszámolni, mert ott van az egyetemi háttér. Ha valamit érdemes bezárni akkor az pont az austini iroda, de csakis pénzszűkében. Ennek az oka, hogy irodát könnyebb máshova rakni, mint működő egyetemet építeni köré. Ez egyébként egy elég fontos tényező lehet a felvásárlás során, mert a SoftBanknak nincs lehetősége bezárni a brit székhelyet, nem tudja ugyanis helyettesíteni a Cambridge-i Egyetemet, míg az NVIDIA számára pont a brit székhely a nyűg, mert ők tudják más egyetemmel helyettesíteni a kutatásokat. Valahol szomorú, hogy annyira felhígult a szakma, hogy ezt már egy IT elemző sem látja, miközben az IT fejlesztések jó része egyetemi kutatásból származik.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#43533
üzenetére
Én arra hoztam fel, hogy Boris elkezdte nyomni politikai szinten a kritikus infrastruktúra védelmét. Egyszerűen túl sebezhetővé vált politikailag az ellenfelei által a korábbi üzletek révén, és erre minden politikus reagál valahogy. Ráadásul egyre inkább értékek az IT szabadalmak. Nem egy választónak imponálhat, hogy nem akarja az USA-nak adni az ARM-ot. Persze az okosabban át fognak látni rajta, de ilyen ez a politika.
-
Abu85
HÁZIGAZDA
Pont az a probléma, hogy a britek már túl sokszor engedtek, és már politikai nyomás van velük szemben, hogy többet ne engedjenek. Ezért csinálja most Boris azt a politikát, hogy újabban védik a kritikus infrastruktúrákat.
Azt tudnod kell, hogy Boris egy elképesztően populista politikus. És azt látva, hogy az embereknek számít, hogy ne szórják ki a britek a kritikus cégeiket, elkezdték Newport Wafer Fab üzletének felülvizsgálatát, de Kína nélkül csinálják a Sizewell C nukleáris projektet, és most az ARM-hoz is ragaszkodnának. Ez Borisnak most politikai tőke, ami jól jön abban az időszakban, amikor lassan kiderül, hogy a Brexiten durván rajtavesztettek. Most jobban eladható a híveiknek a kritikus infrastruktúra védelme, mint az, hogy ezeket eladják. Politikai szinten azt nem vizsgálják, hogy anyagilag vagy piaci alapon mi érné meg. Lásd Brexit.
-
#43483
Abu85
HÁZIGAZDA
Petykemano
#43474
Abu85
HÁZIGAZDA
válasz
Petykemano
#43474
üzenetére
Automotive. HPC.
#43477 gainwardgs : Nem a réjtrészing a probléma, hanem a DirectX 12 mód. Lassabb, mint a DirectX 11-es, ráadásul akadozgat is.
Ez szokásos Unreal Engine betegség, ha nem módosítják az alap leképezőt. Régóta az a probléma, hogy a motor a render targeteket mindenképpen üríti az új képkockák számításánál. Erre van beállítva, de igazából nem lenne szükség rá, ha lenne egy olyan kód a motorban, ami meghatározná, hogy egyáltalán ki kell-e üríteni az egyes render targeteket. Ha nem, akkor felesleges munka van velük, ráadásul értelmetlenül.
Külön vicc, hogy ez csak PC-n probléma még mindig. A konzolokra már olyan leképező van, ami tartalmazza ezeket az optimalizálásokat, és persze, hogy optimalizált kóddal sokkal jobban tudnak működni a gépek.
-
#43471
Abu85
HÁZIGAZDA
Petykemano
#43450
Abu85
HÁZIGAZDA
válasz
Petykemano
#43450
üzenetére
Nem igazán felvásárolták, hanem megvárták a csődöt, és megvették az IP-ket, illetve az egyes országokban a márkanév használati jogát, de ezek jórészt már lejártak, és nem hosszabbították meg.
#43469 b. : A PC gaming addig értékes az NV-nek, amíg pénzt keresnek rajta. Ha nem tudnak pénzt keresni, akkor értéktelen lesz. Tehát azért áraznak felfelé generációnként, hogy pénzt keressenek. Ennyire egyszerű. Alamizsnáért inkább nem csinálnák.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#43392
üzenetére
Mert ez nem ki-bekapcsolható fícsőr. Vagy aktív, és akkor 8 mag minimum, vagy nem aktív. Ez nem csak egy látványeffekt, ettől változik a játékmechanika. Esetleg tovább lehet optimalizálni, hogy kevesebb erőforrást igényeljen. Ez is realitás, de akkor sem idén, mert ahhoz már túl kevés idő van.
-
#43391
Abu85
HÁZIGAZDA
tisztelturam
#43390
Abu85
HÁZIGAZDA
válasz
tisztelturam
#43390
üzenetére
Persze. Ők azért látják, hogy milyen géppel játszották a Fifa 21-et a játékosok, és valószínűleg nem tenne jót az eladásoknak, ha a Fifa 22 a többségnek azt írná ki, hogy "nincs nyolc magod, nem nyertél belépőt".
-
#43389
Abu85
HÁZIGAZDA
tisztelturam
#43388
Abu85
HÁZIGAZDA
válasz
tisztelturam
#43388
üzenetére
A Stadiában csak egy beállítás a játékhoz sok procimagot rendelni. PC-n is meg tudnák oldani, csak be kellene írni minimum igénynek a 8 magot.
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.
Ú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.
- MacBook felvásárlás!! Macbook, Macbook Air, Macbook Pro
- ÁRGARANCIA!Épített KomPhone i5 14400F 32/64GB DDR5 RTX 5060 Ti 8GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! Apple iPhone 16, Apple iPhone 16e, Apple iPhone 16 Plus, Apple iPhone 16 Pro
- Samsung Galaxy S22 Ultra 5G 512GB, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! Dell Latitude 5420 - i5-1145G7 I 16GB I 256SSD I HDMI I 14" FHD I Cam I W11 I Garancia!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest