Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Gondoltatok már userként arra, hogy ne fizessetek olyan játékért, ami UE5-ön akadozik? Mert van egy rakás olyan játék, ami UE5-ön nem akadozik. Vagy az esetleg oda vezetne, hogy a fejlesztők megoldják az akadozást a játék kiadása előtt, mert félnek attól, hogy nem veszik meg a userek?
-
Abu85
HÁZIGAZDA
válasz
Yutani
#48876
üzenetére
Ez nem lehetséges a mostani API-kkal. A hardverek alkalmasak lennének, de az API limitál.
Talán a Sony tudna dolgozni a GNM-en, mert nekik csak egy hardverhez kell igazodni, és tudnának valami nagyot dobni, de nem hiszem, hogy ez fontos számukra a PS5 Pro konzolon. Túl kevesen veszik ezt a gépet, hogy ebbe ennyi energiát fektessenek.
-
#48870
Abu85
HÁZIGAZDA
gainwardgs
#48868
Abu85
HÁZIGAZDA
válasz
gainwardgs
#48868
üzenetére
Az azért jön külön, mert az egy nagyon-nagyon lassú kód. Direkt úgy van megírva, hogy ne is fusson jól, lásd az Indiana Jonesban. Nem azért, mert ennyire lassúak a hardverek, hanem azért, mert így van megírva. Ezért adják ki azt külön, mert az nem az ID kódja.
Hasonló a helyzet, mint anno a PhysX esetén. Hiába telt el 10+ év, azért nem gyorsult semmit, mert szándékosan volt lassúra megírva, így miután kihúzták a talajt alóla, itt maradt a rosszul megírt CPU-s kód, ami sosem fog futni semmin, mert koncepcióból van lassúra írva.
-
Abu85
HÁZIGAZDA
Driver ezen nem igazán fog segíteni. A játékban át lehet mondjuk írni a shadereket, de az azért majdnem 500 ezer sornyi kód. Nem egy hét alatt fogják átdolgozni, ha átdolgozzák egyáltalán. Nem is hiszem, hogy az ID-t érdekli ez, mert számukra nem az a kritikus, hogy az GF 50 a 40 sorozat előtt legyen, hanem az, hogy minden VGA-n a lehető legjobban fusson a játék.
A jövőben ez lehet, hogy kisebb probléma lesz, mert a legtöbb shadert azért úgy tervezik, hogy az elérhető hardverek tipikus occupancy limitjéhez igazodjon. Ebből a szempontból nem rossz most a helyzet, mert az RDNA 3-4 és az Ada nagyon hasonlóan viselkedik ugyanazzal a shaderrel. Tehát effektíve bármelyikre is optimalizálják, az jó lesz a másikon. A Blackwell occupancy limitje változott. Tehát ha nem arra optimalizálnak, akkor egy RDNA 3-4 és Ada dizájnokra optimalizált shader nem annyira jó a Blackwellen.
Valószínűbb egyébként, hogy itt a shadereket eleve az RDNA "2"-re írják a konzolok miatt, és a PC-s verzióra csak finomhangolnak. Ez nagyon kellemes irány az RDNA 1-2-3-4 és a Pascal-Turing-Ampere-Ada dizájnoknak, mert nagyon keveset kell változtatni a shaderen, ha kell egyáltalán, és minden elég jól szokott futni. Viszont a Blackwell nem annyira bírja az RDNA 2-re optimalizált shadereket, mások a limitek hardverben. A Blackwell inkább a Maxwellhez hasonlít a limitek szempontjából, de Maxwellre már nem optimalizál senki, mert nagyon specifikusan kell vele bánni, és kevés ilyen hardver van már a felhasználóknál.
-
Abu85
HÁZIGAZDA
Más játékban is volt erre példa. Minél inkább számít egy multiprocesszor bájt/FLOPS tempója, annál inkább limitálja ez a mutató a Blackwellt. Ezzel nem lehet mit kezdeni, ez koncepcióból van így tervezve. Az AI volt a dizájn fókusza és nem a grafika. Csak amíg nem nyúlnak a tensorhoz a játékok, addig az AI része a dizájnnak hasztalan, és a grafikai rész limitjeit nincs minek ellensúlyoznia.
Ezért reklámozza az NV nagyon a felskálázást meg a többképkockás generálást, mert tudják jól, hogy a klasszikus feldolgozási módszerek mellett csonkítottak egy nagyot a dizájnon. Cserébe máshol erősebb lett sokkal a dizájn, csak amíg ahhoz nem nyúlnak hozzá, addig ez nem sokat számít.
-
Abu85
HÁZIGAZDA
Nem csak a Doomban tapasztalható ez. Más játékban is van, hogy az Ada úgy átlagos hatékonyságban jobb, mint a Blackwell.
Ez itt a lényeg. Látod, hogy a feldolgozók nem változtak. Szám szerint ugyanannyi van. Viszont az adatút változott. Az a nagyobb FP32 tömb ugyanakkora buszon van bekötve, mint az a kisebbik Ada-féle FP32 tömb. Természetes, hogy nem tudja úgy etetni, mint régen, mert a megmaradt, egységnyi szélességű busz, most kétszer annyi feldolgozót lát el.
Ezzel rohadt nehéz mit kezdeni a szoftver oldaláról, mert a FLOPS ugyan megmaradt, de a bájt/FLOPS feleződött.
-
Abu85
HÁZIGAZDA
Ez nem a szoftveren múlik. Az Ada esetében úgy lehetett etetni a feldolgozókat, hogy volt két szád és két kezed hozzá. Most a Blackwellben egy dupla akkora szájad van, de elvették az egyik kezét. Tehát a Blackwell szájba ugyan befér ugyanannyi kaja, mint két kisebb Ada szájba, viszont a Blackwell már csak egy kézzel lapátolhatja az ételt. Tehát hiába maradt benne ugyanannyi feldolgozó, maga az etetésük sokkal lassabb lett. Ezzel az NV szoftveres csapata nem fog tudni mit kezdeni, mert már nem tudnak rakni még egy kezet a hardverbe, hogy ugyanolyan gyorsan egyen a Blackwell, mint az Ada.
A Blackwell egy más jellegű dizájn, nagyon sok tranzisztort áldoztak olyan dolgokra, amiket a mai játékok nem is tudnak használni. Nem is biztos, hogy a játékok valaha használni fogják, mert nem igazán grafikai fókuszú dolgokról van szó.
Ez a jelenség egyébként nem csak a Doomot érinti, számos játékban látható. Tipikusan azokban a játékokban, amelyek erősebben terhelik a multiprocesszoron belüli adatutak áteresztőképességét, mert ott lett megfelezve a Blackwell az Adához viszonyítva. Ezzel nagyon sok tranzisztort tudott spórolni az NV, csak eltűnt a teljesítmény is vele. Érdekessék, hogy például az RDNA 4-nél pont fordítva dolgozott az AMD. A multiprocesszoron belüli adatutak áteresztőképességét megduplázták, ezért tudja a 7900 XTX-et sokszor megverni a 9070 XT, annak ellenére, hogy számszerűen kevesebb feldolgozó van benne. A szájas példával élve az RDNA 4-nek nem változott a szája, de az RDNA 3-ból örökölt keze mellé kapott még egy extra kezet, hogy lapátolja gyorsabban az ételt.
Ez egy nagyon érdekes és nagyon jelentős döntés volt az AMD és az NV részéről, mert az NV elvett egy kezet a korábbi hardverdizájnból, míg az AMD hozzáadott. Valószínűleg azért döntöttek eltérően, mert az AMD inkább grafikai fókuszú dizájnt akart még mindig, míg az NV inkább AI fókuszút.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#48778
üzenetére
Ha 10+ éve mindenki ugyanúgy félreérti az adatokat, attól az még nem lesz érvényes módszertan. Az csak azt jelenti, hogy az emberek következetesen lusták utánanézni, hogyan működik a statisztika, mint tudomány. Olyan ez, mint amikor valaki antibiotikumot szed vírusra. Csak azért, mert mindenki ezt csinálja, még nem lesz okos dolog, csak következetesen tévednek az emberek.
#48790 atok666 : Nem, nem válogat a hardverek között. És ettől torzít, mint a szar.
-
Abu85
HÁZIGAZDA
válasz
TakiNándi
#48770
üzenetére
Senki sem tekinti mérvadónak, aki tanult statisztikát.
#48772 Busterftw : A statisztikai módszertan minden statisztika alapja. Anélkül csak haszontalan és értelmezhetetlen adatdömpingről van szó, és nem statisztikáról. És itt fontos, hogy nem az adat mennyisége a fontos, mert ha csinálsz egy olyan statisztikát, ahol egy gépet egymilliószor rögzítesz, akkor rögtön nagyobb lesz az adatmennyiséged a Steamnél. De ugyanott fogsz elbukni, ahol a Steam. A statisztikai módszertan be nem tartásánál, tehát ugyanúgy csak haszontalan adathalmazod lesz.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#48765
üzenetére
Azért nem jön ki a matekod, mert a Steam statisztika nem alkalmaz tudományos megközelítést. Van úgy, hogy 100x felkerül egy gép. Hogy lehetne egy olyan statisztika valid, aminél 100x szavazhatsz?
Segítek. Zárt ki a Steam statisztikát, és akkor nem csak nézel, hanem látni is fogsz.
A Steamen pedig azért nem jelennek meg dolgok, mert nem mindig kér adatot a rendszer. És ez nagyon kritikus. Az nem egy automatikus statisztika, engedélyezned kell, sőt, fel kell, hogy dobja, hogy a te adatod ott legyen benne. Tudod, hogy én még mindig a négy évvel korábbi gépemmel vagyok jelen? Rég nincs meg az a gép, de még mindig úgy van a statisztikában, hogy itt van nálam. Hogy lenne bármilyen statisztika hiteles ilyen design flaw mellett...
-
Abu85
HÁZIGAZDA
válasz
TakiNándi
#48752
üzenetére
A Steam statisztika azért nem jó, mert nem tudományos, ugyanis nem alkalmaz statisztikai módszertant.
Az AMD-nek jelenleg még mindig 3:1 arányban van előnye az eladásokban az RDNA 4 és Blackwell start óta. Egyszerűen sokkal többet gyártottak az elején. Sőt, még most is többet gyártanak, de már nem sokkal.
#48757 Busterftw : Nem, nem tudja a piaci trendeket mutatni egy tudományos módszertant nélkülöző statisztika. Azért tud olyan hülyeséget kihozni, amilyet kihoz úgy, hogy az AMD lényegesen több Radeont gyártott az elmúlt három hónapban.
A Steam alapvető problémája az, amit már ezerszer felróttak neki, hogy egy gépről bejelentkezhet 100 ember, és akkor 100x lesz az az egy gép regisztrálva. Ezt a Valve próbálja kiszűrni, ezért változott időnként extrém nagyot a statisztika, mert a Valve elkezdte kidobálni azokat a konfigurációkat, amelyeket 100-1000-szer rögzítettek eltérő felhasználónév alatt. Ez mellőzi a teljes tudományos statisztikai módszertant. Elfogadhatod, hogy jó, ha egy gép 100x szerepel a statisztikában, csak ettől még nem lesz jó.
Az NV április végéig összesen 490 ezer Blackwell GeFroce-ot gyártott. Az AMD ~1,2 millió Radeont. Ha 6-8 millió GeForce-ot gyártanának, akkor nem lenne gond, de kell a wafer az AI gyorsítóra.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#48738
üzenetére
A Steam statisztika semmire nem jó, mert nem alkalmaz statisztikai módszertant.
Nem a pontossággal van a baj, hanem azzal, hogy a statisztikát mint tudományágat telibeszarja. Konkrétan kibasznának mindenkit az egyetemről, aki ilyen statisztikát csinálna.
#48747 Busterftw : Nem, nem csak az volt a gond. Az a gond, hogy ugyanazt a node-ot használják az AI cuccok, és mivel abban több pénz van, így az NV csak az abszolút minimum mennyiséggel viszi a gaminget, hogy a legkisebb mértékben rontsák a pénzügyi eredményeiket. Emiatt voltak a Radeonok az eladási toplisták élén az üzleteknél. Nem azért, mert az NV nem tud eleget gyártani. Nem is akarnak.
Meg számít az is, hogy a gaming piacon a játékosok eltűrik, hogy mélytorkosra szopatják őket. Szinte tátott szájjal kérik még az alázást. Az AI-piac nem ilyen. Ott egy hosszabb szállítási határidőt azért lemondanak. Nyilván, ha a játékosok eszesek lennének, és nem nyelnék azt, amit kapnak, akkor nagyon gyorsan megváltozna ez, mert rájönne az NV, hogy nem lehet mindent a szátokba tenni.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#48729
üzenetére
Ez jelzi nektek, amiről annyiszor írtak már a hozzáértők, hogy mennyire extrém torzító a Steam statisztika statisztikai módszertan nélkül. És amíg a Valve nem kezeli ezt tudományként, és nem alkalmaznak tudományos módszereket, addig a Steam statisztika extrémen torzítani fog a jövőben is. Sajnos nagyon drága lenne alkalmazni egy szakembert erre, hogy összerakja a statisztikájukat, így hát marad a tudománytalanság és az amatőrködés.
-
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.
-
Abu85
HÁZIGAZDA
Tudom miről beszélek. Arra próbálsz koncentrálni, hogy a játékmenet bizonyos százalékában találsz nyílt terepet, de nem ez a döntő tényező az effektek dizájnjának kialakításakor. Okkal néz ki a CP2077 zárt térben sokkal jobban, mint nyílt térben. Egyszerűen az effektek dizájnját zárt térre tervezték, és ez nem működik olyan jól nyílt térben. De ettől még vannak nyílt terek benne, csak nem ez volt a fókusz. A Godfall esetében pont ezek voltak fókuszban, mert arányaiban több nyílt térrel találkozik a játékos, mint zárttal. Emiatt a Godfall inkább zárt térben nem működik olyan jól.
Mellesleg, ha lenne sütnivalójuk a versenyhatóságoknak, akkor nem engednék az AMD-Xilinx üzletet.
Új hozzászólás Aktív témák
Hirdetés
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.
- HiFi műszaki szemmel - sztereó hangrendszerek
- Elektromos cigaretta 🔞
- Bluetooth hangszórók
- Elder Scrolls IV - Oblivion - Olvasd el az összefoglalót, mielőtt írsz!
- iPhone topik
- 3DMark (2013) eredmények
- Teljes verziós játékok letöltése ingyen
- Tőzsde és gazdaság
- Hálózati / IP kamera
- Xbox Series X|S
- További aktív témák...
- iKing.Hu - Samsung S25 Ultra - Használt, karcmentes
- 0% THM részletfizetés, beszámítás! Gamer PC, notebook, konzol, Apple termék, hardver KAMATMENTESEN!
- LG OLED Televíziók: FRISS SZÁLLÍTMÁNY -30%
- BESZÁMÍTÁS! AMD FX-8320 8 mag 8 szál processzor garanciával hibátlan működéssel
- Eladó Apple iPhone Xr 64GB fekete / ÚJ KIJELZŐ / 100% AKKU / 12 hónap jótállással!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged