Új hozzászólás Aktív témák
-
#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
#69452517
#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.
-
Abu85
HÁZIGAZDA
Ettől még működni fog az RT a mostani RT-s kártyákon, csak nem úgy ahogy most. De az igaz, hogy a DXR 1.0 és 1.1 egy zsákutca. A DXR 1.0 azért, mert túl sok dinamikus bekötést igényel, és emiatt lassú, míg a DXR 1.1 azért, mert nem kompatibilis a működési elve olyan potenciális jövőbeli hardveres fejlesztésekkel, mint a másodlagos sugarak koherenciájának biztosítása. A traversal shader egyébként egyik zsákutcára sem megoldás. Ez abban segít, hogy ha RT-t raknak a játékba, és nem csak marhára limitált távolságig lövik a sugarakat, akkor az RT VRAM-igénye ne legyen 2-3 GB, ami ma is előfordul a távolra számolós RT-s játékokban, mint például a Godfall. Ha azt átrakják traversal shaderre, akkor ez a VRAM-igény 0,5-1 GB közé csökken, ami azért nem mindegy. Ez most a legégetőbb probléma. De a DXR 1.0 és 1.1 problémáit ez sem kezeli, ahhoz egy harmadikféle irány kell. Na most a Microsoft dönthet úgy, hogy csinál egy új irányt, vagy megpróbálja erősen kombinálhatóra módosítani a DXR 1.0-t és 1.1-et. Utóbbi esetben nem kell új specifikáció, és úgy működhetne a dolog, hogy a másodlagos sugarakkal dolgozó lövéseket DXR 1.0-ban, míg a csak elsődlegessel dolgozókat DXR 1.1-ben alkalmaznák. Itt kihasználnák, hogy az elsődleges sugarak alapból koherensek.
Szerintem amúgy ez még évekig útkeresés lesz, de ettől tesztelni lehet.Érdemes amúgy az Intelnek megnézni ezt a konstrukcióját: [link] - nem megoldás mindenre, de a DXR legégetőbb bajait kezeli. Oldalt van egy videó, amiben az előadás megtekinthető, és nagyon jól érthetően elmagyarázzák. Erre lesz jó amúgy a traversal shader.
#43298 b. : Az EVGA-nak az a gondja, hogy az Intel már nem az elsődleges gaming választás a prociban. Ezt le kell reagálni, mert ha megnézed a DIY eladásokat a procinál, akkor azt gaming szinten a Zen 3 uralja le, nem a rakétató. Ez az EVGA-nak azért baj, mert kevesebb lesz az igény az inteles alaplapjaira, hiszen ha már eleve nem veszik meg a szükséges procit, akkor hova adnák el a legyártott termékeiket ugye...
-
Abu85
HÁZIGAZDA
A Microsoft-féle API szabványos, de még nincs kész PC-re. Amíg nem véglegesítik a specifikációt, addig nem fogják használni a programok. Erre azért jó oka van az iparágnak... better safe than sorry.
[link] - itt alul lehet olvasni készülő fejlesztéseket. A három felsorolt újítás közül kettő már nem potenciális, hanem konkrétan benne van az Xbox Series S/X mono API-jában. Konkrétan a traversal shader és a beam tracing. Új hardvert sem igényelnek, sőt igazából a meglévő hardverekből is kevesebb részegység lesz kihasználva, mert a traversal shader egy programozható lépcső, így a fixfunkciós traversal unit hiába van ott az egyes GPU-kban, azokat nem lehet majd ezzel használni.
Az AMD-nek van nem szabványos rendszere erre, de igazából ezt sokan csak a fejlesztéshez használták. Igazából ahogy lesz szabvány, nincs értelme az AMD-féle nem szabványos csomagnak. A fejlesztésben segíthet, de másban nem.
-
-
Abu85
HÁZIGAZDA
A WoW a Shadowlands óta inkább csak Radeonra van optimalizálva. GeForce-okat a Blizzard elképesztően elhanyagolja. Meg is látszik a teljesítményen. Mi fel akartuk venni a WoW-ot a tesztcsomagba, de 1080p-ben DX12-ben, bekapcsolt RT-vel, quality 10 beállítással egy Radeon 6700 XT 145 fps-t tudott, míg egy GeForce RTX 3090 109 fps-t. Itt kérdezősködtünk, hogy ez miért van, lesz-e patch, vagy mi a tosz, és annyit tudtunk meg, hogy a Blizzard fejlesztői gépeiben már nincsenek GeForce-ok. Az NVIDIA is mostanra oldotta meg azt a bugot a driverben, ami miatt a játékosok már hónapok óta képi hibákkal küzdenek. Valamin összekaphattak, és most rohadtul nem néznek egymás felé, de az AMD sem beszél arról, hogy mi a probléma. Az a pletyka járja, hogy eléggé komoly a mosolyszünet, mert a Blizzard még mindig nagyon zabos azért, hogy az egyes játékaik elérhetők voltak a GeForce Now szolgáltatáson, és ezért nem kaptak licencdíjat. De kifelé mindenki kommunikálja, hogy minden fasza, csak nem látszik a programon. Így a Shadowlands ki lett ütve a tesztcsomagból, mert így nagyon egyoldalú lenne ez a cím. Emiatt nem is túl jó összehasonlítási alap még réjtrészinggel sem, a kód elképesztően szarul fut GeForce-on, és így fél évvel a megjelenés után láthatóan az akarat is hiányzik, hogy ezen javítsanak.
-
Abu85
HÁZIGAZDA
Ha tudod, hogy mit keress, akkor feltűnő lehet. Ez az átka a szakmának, tudni fogod, hogy az egyes eljárások hol hibázhatnak, míg mások nem, és esetleg elnézik a hibát.
Mindkettő célja ugyanaz, csak másképp jutnak el az eredményhez.
Egyébként a DLSS nem igazán hardverfüggő. Az NV erőlteti rá a tensor magokra, de lényegesen jobban járnának, ha nem tennék, mert igazából a tensor magok nem igazán a DLSS-hez lettek kitalálva, így a hatékonyságuk elég sokat esik alatta. Jó példa volt erre a DLSS 1.9, ami nem a tensor magokon futott, és micsoda minőségi ugrás volt a korábbi DLSS verziókhoz viszonyítva. Azt nehéz megérteni, hogy az NV miért szopatja magát a tensor magokkal, nélkülük jobb minőséget lehetne előállítani, ráadásul gyorsabban. Elképzelhető, hogy ebbe beleszól a marketing, amely nagyon erőlteti, hogy használják a DLSS-hez a tensort, még ha nem is erre tervezték a hardvert.
-
Abu85
HÁZIGAZDA
Több dolog okozhat hibát a felskálázási eljárás során.
A shimmering általános jelenség, az FSR-t és a DLSS-t is érinti, mert a működésből keletkezik a probléma, de valamennyire kezelhető, viszont nem szüntethető meg.A szellemképes hatás a mozgásvektor-alapú algoritmusok sajátja, egyszerűen a temporális adat miatt nem szűrhető ki teljesen, de lehet segíteni rajta, hogy ne legyen annyira zavaró, viszont nem szüntethető meg. [link]
Az egyéb grafikai hibákba sorolandó az, ha egy effekt nem működik jól temporális rekonstrukcióval. Ez abból ered, hogy a szükséges adatok temporális rekonstrukcióval hiányozhatnak Az ide kategorizálható grafikai bugok sem szüntethetők meg, de talán minimalizálhatók. [link]
Amiért az AMD az FSR-rel kerüli a temporális megoldást az pont az, hogy a szellemképes hatással és az egyéb grafikai hibákkal nem tudnak mit kezdeni, ezeket maga a mozgásvektor generálja. És mivel jelenleg láthatóan leszarják a fejlesztők az efféle bugok javítását a DLSS 2-nél (mert ezzel egyébként per program alapon kellene valamit kezdeni), jobbnak látták, ha olyan felskálázási eljárást választanak, amely eleve nem generál ilyen hibákat.
-
Abu85
HÁZIGAZDA
Nem szükséges a temporális megoldás. Pont ma bizonyította be az AMD. Az az NVIDIA döntése, hogy ők így csinálják, de egyértelműen látszik, hogy nem ez az egyetlen megoldás.
Az AMD egyelőre eléggé távol van a mozgásvektor-alapú algoritmustól. Ezt azzal indokolták, hogy egy rakás olyan problémát hoz be egy ilyen rendszer a képletbe, amelyet a fejlesztőknek direkten kellene kezelni, de láthatóan nem teszik. Amíg nem látják a fejlesztői akaratot a DLSS 2-nél, hogy a mozgásvektor által generált hibákat direkten kezeljék, addig jobbnak látják, ha ezeket a hibákat a felskálázó eljárás elő sem hozza. Ezért nem dolgozik temporális adatokkal az FSR, a fejlesztők egyszerűen tesznek arra, hogy a temporális adatok által behozott problémákat kezeljék.
Sok dolgot lehet fejleszteni a felskálázó megoldásokon, de nem az a kérdés, hogy elméletben mit lehetne megtenni, hanem az, hogy a fejlesztők számára mi lenne az optimális. És itt ezen azt kell érteni, hogy a megoldás rendelkezzen olyan nagy kompatibilitással, hogy a fejlesztőknek ne kelljen a felskálázás beépítése miatt semmit sem átírniuk.
-
Abu85
HÁZIGAZDA
Attól, hogy az NV áttért mozgásvektorra még nem kell követnie őket az AMD-nek. Miért is lenne jó a piacnak ugyanarra a problémára ugyanaz megoldás? Gondolj arra, hogy ha például egy adott effekttel nem kompatibilis a DLSS 2, akkor nem kell az effektet áttervezni, hanem könnyebb beépíteni az FSR-t. Ez volt a koncepció az AMD döntése mögött.
Mindkét cég járja a saját útját, és ha ez az út eltérő, akkor az hasznos, mert mások az előnyök és a hátrányok.
-
Abu85
HÁZIGAZDA
Szándékosan ilyen. A temporális adatok korlátozzák a kompatibilitást és kisebb-nagyobb grafikai hibákat generálhatnak. Ezt a tényezőt az FSR-ből direkt vették ki, hogy minden effekttel kompatibilis legyen, és ne kelljen grafikai hibákkal számolnia a fejlesztőknek, mert az eddigi tapasztalatok alapján sajnos nem írnak csak a felskáláz miatt temporális eljárásokkal kompatibilis effekteket.
-
#43156
Abu85
HÁZIGAZDA
gainwardgs
#43150
Abu85
HÁZIGAZDA
válasz
gainwardgs
#43150
üzenetére
Én se nagyon, de az Intel nagyon ígérgeti a partnereknek, hogy lesznek kompatibilis szoftverek az Alder Lake startjára. Már amúgy van olyan profilozójuk, amivel az alkalmazás működése hozzáigazítható az eltérő magokhoz, tehát ez jó jel. Innen már csak a fejlesztőkön múlik, hogy megcsinálják-e, vagy inkább kijelölik az egyik magcsoportot oszt jóvan.
-
Abu85
HÁZIGAZDA
A CCX-es megoldás abból a szempontból nem nagy gond, hogy ott mindegyik mag ugyanolyan késleltetéssel éri el a gyorsítótárait. A hibrid dizájnoknál az kavar be, hogy a két magcsoporton belül is eltérők a magok. Ezeket alkalmazás szintjén tudni kell kezelni, vagy meg kell mondani az OS-nek, hogy erre az applikáció nincs felkészítve, így ne is ossza a másik magcsoportra a programszálakat.
Igen. A BIOS-ban ki lehet kapcsolni a kisebb teljesítményű magcsoportot.
-
#43144
Abu85
HÁZIGAZDA
gainwardgs
#43143
Abu85
HÁZIGAZDA
válasz
gainwardgs
#43143
üzenetére
A Windows ennek csak az egyik eleme. Az új OS-t a Microsoft felkészítette arra, hogy jobban tudjon dönteni a hibrid dizájnokban. De ez az ütemező jórészt a Qualcomm kódjára épül. A problémás terület nem ez, hanem az alkalmazások helyzete, hogy lekezeljék az eltérő magok jelentősen eltérő késleltetését a gyorsítótárakra nézve. Ebben valamennyire segít az, hogy az új ütemező felé egy alkalmazás jelezheti, hogy hibrid dizájn esetén tudja-e kezelni a magok különbségeit, vagy nem, és ha nem, akkor melyik magcsoporton akar futni, és melyiket hagyja munka nélkül. Default beállításon az Edge böngésző például eleve az Atom magokon fut, és a nagy mag(ok)hoz hozzá sem nyúl. Azt még nem tudni, hogy ebbe a user belenyúlhat-e, vagy el kell fogadni az alkalmazás/OS döntését. Androidon ugye úgy van, hogy nem lehet megszabni felhasználói szinten, hogy egy alkalmazás melyik magcsoporton fusson, ha a leglassabb magokon akar futni, akkor lófaszt se tehet a user.
-
Abu85
HÁZIGAZDA
A Samsung 7 nm-es node-ja is jó, csak ugyanúgy drága, mint a TSMC-é.
5 nm-en inkább a TSMC tűnik kiemelkedően jónak. A többiek azzal küzdenek, hogy ilyen csíkszélességen már erőteljesebben kell alkalmazni az EUV-t, és erre egyszerűen nem készültek fel. A TSMC ott nyert baromira sokat, hogy nem várta meg az ASML pelluláit, hanem csinált magának, és ezzel hatalmas előnyre tett szert az EUV node-ok tekintetében. A Samsung itt hibázott, mert nem terveztek maguknak pellulát, hanem vártak az ASML-ét. A TSMC-vel most az ipar legalább 3-4 évig nem tud majd mit kezdeni, mert ugyan a gyártási problémákat lassan megoldja mindenki, de a TSMC már meg is oldotta, és így már nagy mennyiségben rendelhetik az EUV-s eszközöket. Az Intel itt a futottak még kategória, mert ők még egyetlen EUV-s gyártósort sem üzemeltetnek tömeggyártás szintjén, ellentétben a Samsunggal és a TSMC-vel. Tehát lesz egy rakás munkájuk a problémák megoldásával, de ezen a TSMC és a Samsung akkorra már rég túl lesz. Ettől függetlenül az Intel az IDM 2.0 miatt olcsón adhatja a wafert, amit az NV ki is használhat, de ez annyit is ér, mert ettől még 1-2 évvel lesznek a Samsung és a TSMC gyártási eljárásai mögött.
Az a gond az Intelnél, hogy nagyon jó dolgokat beszélnek magukról, de valójában meg sem közelítik jelenleg azt, amit a TSMC vagy éppen a Samsung tud biztosítani tömeggyártás szintjén. És a kulcsszó itt a tömeggyártás. Azért nyeri a TSMC és a Samsung a megrendelőket, mert nekik nem csak papíron működik a legmodernebb gyártástechnológiájuk. Nézd csak meg mit tud az Intel 10 nm-es node-ja az Ice Lake-SP-ben. Alig van megvásárolható új Xeon. Nem azért, mert nem gyártják, hanem azért, mert akkora lapkaméretben iszonyatosan sok selejtjük lesz. Pont ezért viszik a GPU-s projekteket bérgyártóhoz, pontosan tudják, hogy nagyon messze vannak a TSMC és a Samsung 7 nm-es node-jaitól. Ha nem így lenne, akkor házon belül gyártanának. Emiatt sem nagyon látom reálisnak, hogy az NV-t ez érdekelheti. Lehet, hogy van olyan olcsón kínált wafer, ami mellett megéri, de a technológiai előny a Samsungnál és a TSMC-nél van, és egy darabig még ott is marad. Az Intel is leghamarabb 5 nm-re ígérte a versenyképességet, ami a szokásos optimizmussal van kirántva.
-
-
#42952
Abu85
HÁZIGAZDA
FollowTheORI
#42950
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#42950
üzenetére
De a PS5-ön ez GNM-en fut, ami azért sokszor jobb API, mint a DirectX 11.
-
Abu85
HÁZIGAZDA
A VRS-t többféleképpen lehet használni. Van neki egy Tier_1-es és egy Tier_2-es szintje. Ebben a játékban a Tier_1 van csak kihasználva, abban nincs sok lehetőség, ellenben fut az Intel IGP-in. És ez azoknál fontos, mert sokat jelent ám az előny. A Tier_2-es szint viszont nem fut az Intel IGP-ken (ilyen van egyébként a Gears 5-ben). Na most a Tier_2-es szintre lehet olyan megoldást csinálni, ami úgy növeli a teljesítményt, hogy nem csökkenti a képminőséget, de a Tier_1-es szint túl limitált ehhez. Az új RE-ben az lehetett a döntő, hogy a motor eleve marha gyors, ergo sokkal jobban számított, hogy az Intel IGP-i kapjanak egy kis boostot, minthogy a VGA-k 100 fps helyett 110-zel menjenek. Véleményem szerinte teljesen érthető döntés ez most.
-
#42924
Abu85
HÁZIGAZDA
AsakuraDave
#42916
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#42916
üzenetére
Sok játékban ma borzasztóan korlátozva van a sugarak távolsága. Egyszerűen csak a szemed elé lövi ki, pár virtuális méterre. Ennek az oka, hogy ha olyan messzire lőné, mint mondjuk a Godfall, akkor borzasztóan zabálná a VRAM-ot az effekt. Erre a megoldása programozhatóság.
[link] - ez az előadás nagyon részletesen bemutatja, hogy mi a probléma. Felvázol rá egy potenciális megoldást, és azt is prezentálja, hogy az miért megoldás.
#42917 b. : A probléma általános. Elég sok dolognak nem úgy kellene, hogy kinézzen RT-ben, ahogy kinéz. Azért olyan az eredmény, mert 2-3 méterig vannak sugarak. Esélye sincs az RT-nek, hogy igazán jól működjön. De ugye a fejlesztők is be vannak szorítva, mert ha tovább lövik a sugarakat, akkor azért gigabájtokban fizetnek. Olyan VRAM terhelést raknak a VGA-kra, amire nincsenek felkészítve. Nincs elég VRAM rajtuk. De a megoldás nem az, hogy raksz rájuk sok GB-ot, hanem az, hogy azt a memória- és erőforrás-pazarló működést megszünteted. Ez már csak azért is fontos, mert ugye a nextgen konzolról jönnek át majd az új portok, azokban extrém geometriai terhelés lesz, és eközben akkor is számolni kell egy rakás tartalmat, ha a kamera rá sem néz. Ez butaság. Ha a rendszert erre építjük, akkor a nextgen RT-t alkalmazó portokhoz 50-60 GB-os VGA-k fognak kelleni, mert a PC-s szabványos rendszer nem tud kivágni és LOD-ot változtatni. Ezért nem alkalmaz egyik konzol sem fixfunkciós bejárási lépcsőt. Ha így tennének, akkor ott is gyűlnének ám a felesleges gigabájtok a memóriában, de ugye van a hülye brute force megoldás, és az okos. És a fixfunkciós egység ugyan jóval gyorsabb lehet, de a programozhatósággal meghatározhatod, hogy csak a szükséges dolgokat számold. Ami a teljes számítás egy töredéke lesz, mert a kamera nem lát mindent, és amit nem lát azt nyugodtan ki lehet vágni (kinek számolod, ha nem látszik?), vagy ami messze van, arra nyugodtan mehet egy alacsonyabb LOD szint, amit akár a sugár kilövése után is lehet változtatni.
-
Abu85
HÁZIGAZDA
Érdekes. A Godfall esetében nem voltál ennyire kibékülve azzal, hogy messzire lőtték a sugarakat. Akkor baj volt vele. Most már megbékéltél ezzel is? Mert őszintén szólva szerintem, és tényleg csak szerintem, a Godfall pont elképesztően sokat profitálnak az Intel megoldásából. Gigabájtokban mérhető memóriát spórolnának vele, miközben a képminőség semmit sem romlana.
-
Abu85
HÁZIGAZDA
Tehát teljesen jó, hogy egy eljárás 3-7 GB VRAM-ot el tud pazarolni a semmiért? Oké, nincs több kérdésem.
Az a baj, hogy ez nem gyártói vita. Minden VGA be tudja szopni a 3-7 GB-os extra VRAM használatot, és az ezzel járó extra terhelést, méghozzá csak azért, mert szar a rendszer. És ha megnéznéd azt az előadást, akkor meg is értenéd, hogy miért. De ha azért nem vagy hajlandó megnézni, mert az Intel csinálta, akkor úgy alakítasz ki véleményt, hogy az API problémáit nem ismered.
Megjegyzem, az NV-nek is pont ugyanaz a véleménye, mint az Intelnek és az AMD-nek. A DXR aktuális állapota híg fos, mert őket is pont ugyanúgy érinti az extrém pazarló memóriahasználata, mint az Intelt és az AMD-t. Sőt, a GDDR6X miatt őket jobban érinti.
-
Abu85
HÁZIGAZDA
Sokkal olcsóbban lehet jobb GI-t csinálni. Lásd az Unreal Engine 5 Lumen megoldását. Annak van szüksége RT-s GI-ra, aki nem elég okos, hogy ezt a problémát az erőforrások töredékéből megoldja. Nem viccből nem használnak ilyet a modern motorok. Sokat zabál, és az alternatíváknál nem jobb. De persze, ha az erőforrásokat akarod pazarolni, akkor hajrá.
Pedig érdekelhetne, mert egészen jól elmondja az Intel, hogy miért fos most az RT. Csak egyszer nézd meg, és meg fogod érteni, hogy nem a hardver az oka, hanem az a pazarló munkavégzés, amire az API rákényszeríti a hardvert. Az Intel fel is vázolja, sőt, be is mutatja működés közben a megoldását.
-
Abu85
HÁZIGAZDA
Teljes körű RT van azokban is. A különbség, hogy a programozhatóságra van tervezve. Már elmondtam, hogy a traversal unit, ami hiányzik koncepció. Azért nincs benne, mert a traversal shaderrel használhatatlan. Nem lehet majd elérni a hardverben, ott fog porosodni a tranzisztorok között, egy hardveres /dev/null lesz.
Ugyanígy az Intelnek sem lesz fixfunkciós traversal unitja. Érdemes megnézni ezt az előadást. Nagyon jól bemutatja azt a gigantikus pazarlást, ami a gondot jelenti, ha a traversal lépcső nem programozható. Ha a pazarlást kilövöd a programozhatósággal, akkor sokkal több sebességet nyersz, mintha egy külön hardvert építenél a pazarlásra. [link]
-
-
Abu85
HÁZIGAZDA
válasz
awexco
#42886
üzenetére
Csak az EU nem akar architektúrákhoz kötődni. Pont az a lényege a stratégiánknak, hogy legyen architektúráktól független. Az egyes piacokra más dizájnnal fognak dolgozni. A szerverre ARM és RISC-V, míg a beágyazott piacra RISC-V. Az EU-s stratégia kulcsa eleve a gyártástechnológia, arra megy a nagy lóvé.
#42883 Busterftw : Az ARM székhelye az Egyesült Királyságban maradt. Valószínűleg az lesz, hogy adnak az NV elé egy szerződést, hogy milyen feltételekkel engedik meg. Két lényeges tényező van az UK-nak:
- Maradjon az ARM székhelye az Egyesült Királyságban, és az NV-nek csak a leányvállalata legyen.
- Az NVIDIA nem vihet be saját technológiát az ARM-ba, hogy az ARM-ot továbbra is csak az Egyesült Királyságon belül fejlesszék, így pedig az USA-nak sose lesz joga szabályozni a birtokolt IP-ket.Ha ezt a két tényezőt elfogadja az NV, akkor szerintem az UK is megadja az engedélyt a felvásárlásra. Ez egyébként még Kína szempontjából is hasznos lenne, mert ők nem éreznék fenyegetve magukat, ha az NVIDIA-nak az UK szerződésben tiltaná meg, hogy hatalma legyen az ARM felett. Kérdés, hogy így minek kiadni 40 milliárd dollárt...
-
Abu85
HÁZIGAZDA
Az NV erre nem apellál. Ők a médiapistikkel ellentétben felfogják, hogy a Google számára a Stadia elképesztően kis költség. Ki vannak építve a peremhálózatra a szervereik, amikbe csak GPU-t raknak, és a szabad kapacitást használják a Stadiához. Az egésznek a lényege az, hogy elképesztően kevés extra fenntartási költséggel tudnak több pénzt visszatermelni a Stadia store-on keresztül. A Stadiának akkor lesz baja, ha a Google keresőszolgáltatása leáll, ugyanis akkor nem fognak kelleni a Stadiát működtető szerverek.
Ugyanez van a Microsoftnál és az Amazonnál is. A cloud gaming irányuk egy kiegészítés a meglévő szerverek szabad kapacitásának kihasználására. Költségben nem sok extrát visz, miközben a saját store-ral sokat hoz. -
Abu85
HÁZIGAZDA
válasz
Raggie
#42808
üzenetére
Igazából ez nem driver overhead. Ezek DirectX 12-es címek. Van a meghajtónak némi többletterhelése, de megközelítőleg sem annyi, mint DirectX 11-ben. Az alkalmazás gondoskodik egy rakás olyan feladatról, amit korábbi API-knál a driver csinált. Ergo a többletterhelés igazából az alkalmazáson belül keletkezik, nem a driverből. Ezt is meg lehet magyarázni, főleg amiatt fordulhat elő ilyen, hogy egy játékot Radeonokon fejlesztenek le, és nem ellenőrzik a Radeonnal detektált problémákra adott válaszokat, hogy azok mennyire működnek optimálisan GeForce-on. Ez is gond, de nem a driver az oka. Ezt leginkább per alkalmazás szinten kell leprofilozni és javítani. Az más kérdés, hogy egy fejlesztő a problémát tényleg akkora jelentőségűnek tartja-e, hogy foglalkozzon vele. Elvégre maga az alkalmazás hibátlanul fut, csak nem olyan gyorsan, mint elvileg futhatna.
-
Abu85
HÁZIGAZDA
Akkor nézd meg. Attól még nem lesz valami külső tér, mert a szabad ég alatt játszódik. Ezernyi trükk van, hogy épületekkel körbevedd a területet, és ezzel megteremted magadnak a zárt tér hatását.
#42790 tisztelturam : Attól függ, hogy szabványosan lesz-e implementálva bele a sugárkövetés. A legtöbb játékban a DXR-rel van ez megoldva, de az AMD-nek van egy zárt kiterjesztése a DXR-hez, amivel olyan dolgokat is elérhetnek a fejlesztők, amelyek még nem részei a szabványnak. Minden esetben a Radeon Rays 4.0-t lehet meghívni, ez egészíti ki a szabványt. Ennek két külön módja van, amiről itt egy rövid leírás:
Ha utóbbi kerül egy játékba akkor kap egy külön dll-t, lásd a Godfallban az "amdrtshadow.dll", ebben vannak a szabványból hiányzó részek, például egyedi BVH bejárás. Ha így lesz implementálva a Resident Evil is, akkor azt az NV nem tudja majd futtatni, tehát kell nekik egy külön szabványos implementáció, ami megkerüli a binárisan szállított dll részét a játéknak.Szimpla API interop valószínűleg alkalmazva lesz, de az a jobbik eset, mert az csak intrinsic lehetőség, tehát maga a shader nagymértékben szabványos, csak vannak olyan részei, amelyek az AMD dizájnján meghívnak egy beépített függvényt, és akkor gyorsabban fut. Így van alkalmazva az RT a Dirt 5-ben és az új WoW: Shadowlands frissítésben. Ezeknél a kódoknál a beépített függvényeket az NV ugyan nem éri el, de elég könnyű kezelni ezt a problémát, mert csak írni kell rá pár extra shadert. Emiatt az RR 4.0 szimpla API interoppal nem akkora gond, mintha tényleg egyedi BVH bejárásra használná a Radeon Rays 4.0-t egy játék. Intrinsic lehetőségnél csak kismértékben kell módosítani a kódot, hogy szabványos szinten is fusson. A Godfall esetében azért marha sok munka volt teljesen eltérő LOD kezelést implementálni, mert a flexibilis LOD-ot a DXR nem kezeli, tehát kidolgoztak helyette egy DXR-rel kompatibilis sztochasztikus LOD eljárást. Ennek hasonló az eredménye a memória terhelésére vonatkozóan, csak többet számol, mint a flexibilis LOD.
#42791 huskydog17 : Semmiféle exkluzív szerződés nem volt. A Godfallba egy olyan algoritmus került eredetileg a bejárásra, amit a szabványos DirectX Raytracing nem támogat. Nem megvalósítható az aktuális specifikációkkal a flexibilis LOD. E mellé implementáltak a szabványos kódba egy sztochasztikus LOD eljárást, amit már megenged a DXR. A memóriaigény tekintetében a flexibilis és a sztochasztikus LOD hasonló, csak utóbbi eljárás elvégzéséhez többet kell számolni.
#42796 Locutus : Nem véletlen. A 8 GB-os VRAM igényt már nem egy játék meghaladta az Ampere kiadása előtt. Azóta csak nőttek a lehetőségek, így lassan meghaladtuk a 10 GB-ot is. Ezzel pokoli nehéz mit kezdeni, de ezért vannak a grafikai beállítások. Ha elfogy a memória, akkor lejjebb kell venni a grafikai részletességet. Régen is ez volt a megoldás, és ma is.
-
Abu85
HÁZIGAZDA
Nem a kizárólagosság a lényeg, hanem a pályadizájn kialakítása. Ezt leírtam neked először, hogy külső tereknél külön lehet arra dizájnolni, hogy belső tereknek megfelelő legyen a kialakítás. A CP2077 tipikusan ilyen játék. Egyedül akkor vannak dizájn szinten külső terek, amikor elhagyod a várost. Itt látszik is rajta, hogy az effektek nem működnek olyan jól.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#42783
üzenetére
Semmi, a játékdizájn részei az effektek. Alapvetően a fejlesztők döntenek arról, hogy mire paramétereznek. Az optimális az lenne, ha lenne külön dizájn a belső terekre, illetve egy teljesen eltérő a külső terekre. Csak ennek a megvalósítása aránytalanul sok befektetést igényelne, így az effekteket alapvetően egy dizájnra alakítják ki, arra amelyikkel a játékos arányaiban a legtöbbször fog találkozni. A CP2077 esetében a belső terek, míg a Godfall esetében a külső terek. Ennek megvannak a hátrányai az ellentétes pályadizájn esetében, de nem éri meg vele törődni, mert túl drága lenne a problémák megoldása. Emellett a minőségi ugrás nem feltétlenül lenne arányban a befektetett munkával.
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.
- LENOVO ThinkPad 13 - i7-7500U, 8GB RAM, 256GB SSD, új akku, számla, 6 hó gar
- GYÖNYÖRŰ iPhone 14 Pro 128GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, MS4619, 100% Akksi
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max/
- darkFlash ZR12 Darkstorm
- HP 150W töltők (19.5V 7.7A) kis kék, kerek, 4.5x3.0mm
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest