Új hozzászólás Aktív témák
-
#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.
-
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.
-
Abu85
HÁZIGAZDA
Nem madártávlatra tervezik ezeket, hanem játékmenetre. A Cyberpunk 2077 nagy részében nem látsz el messzire, vagy zárt térben vagy, vagy megakadályozzák az épületek. A Godfall esetében nincsenek épületek, ott sűrűbben nagy a látótávolság. Más dolog az eltérő dizájnra effekteket tervezni. A Cyberpunk 2077 esetében tök reális lekorlátozni a sugárkövetés távolságát, mert a játékmenet nagy részében ezt nem veszed majd észre. A Godfall esetében nehezebb ügy. Alapvetően minden fejlesztő a korlátozást választaná, mert az csak egy napnyi munka. Senki sem szeret egy effektért fél évet dolgozni, de ritkán megteszik, ha nagyon fontos az effekt minősége. Ettől persze le lehet őket hurrogni, hogy miért optimalizálnak, de a saját idejüket lövik el erre.
-
Abu85
HÁZIGAZDA
A kép jól mutatja a dizájnt. Körül vagy véve az épületekkel, tehát nem kell túl messzire lőni a sugarakat. A Godfallban nem tudod körülvenni a játékteret épületekkel, nem a modern korban játszódik. Nem tudsz ilyen hatékonyan trükközni.
Nem számít a memória terhelésénél, hogy hány effektet futtatsz, mert mindegyik ugyanazokat a sugarakat használja. Nem fognak minden effekthez külön sugarakat kilőni. A memóriahasználat kizárólag attól függ, hogy mennyire messzire lövöd a sugarakat. És itt jön képbe a pályadizájn. A Godfall esetében is könnyebb lenne, ha nagy házakkal vehetnék körbe a játékteret, dehát...
És a Godfall is használhatna több effektet lényegében extra memóriaigény nélkül, de Unreal Engine 4-en fut, aminek a gyári SSR-je és SSAO-ja eleve nagyon jó.
-
Abu85
HÁZIGAZDA
Közel sem a végtelenbe számolnak. Egy játék három kategóriába eshet a pályadizájn tekintetében. Lehet a pályatervezés zárt, nyíltnak imitált zárt és nyílt. Az első kettő esetében reális dolog korlátoznia sugárkövetés távolságát, mert már maga a pályadizájn korlátozott. A Godfall esetében ez azért nem működne, mert a pályadizájn egészen nyílt, túl sokszor túl nagy terek vannak benne ahhoz, hogy jól működjön a jellemző limitálás. Emiatt választottak más módot, és nyilván nem jószántukból döntöttek így, mert nekik is sokkal egyszerűbb lett volna azt mondani, hogy a sugárkövetést tart 4 virtuális méterig és kész, mint konkrétan kidolgozni kétféle algoritmust, és elverni az egész probléma megoldáásra kb. fél évet. Ez tehát egy pályadizájnból eredő döntés. Más játékban, például a Cyberpunk 2077-ben nem feltétlenül ez a jó döntés, mert ott a városi nyílt terek is úgy vannak felépítve, hogy a lehető legtöbb oldalról körül vannak zárva. Természetesen ez egyszerűbbé tesz bizonyos fejlesztői döntéseket, csak egy Godfallban nem tudsz felhőkarcolókat felhúzni a játéktérbe.
Az RT teljesítmény játékfüggő.
Az optimalizáció azt jelenti, hogy egy problémára kitalálsz valami olyan megoldást, ami segít az erőforrás optimális használatában. Ezt tette a Godfall is. Az nem optimalizálás, hogy négy virtuális méterre korlátozod a sugarak távolságát, ilyenkor pont elkerülöd az optimalizálást, hiszen meghúzol egy olyan mesterséges limitet, amivel szükségtelenné válik az optimalizáció. Természetesen sokszor ennek is van értelme, de ahogy fentebb írtam, nehéz a nagyon nyílt dizájnú játékokra ezt ráhúzni, de persze nem mindegy, hogy fél évig optimalizálsz, vagy egy nap alatt limitálod a számítást. Ez is a fejlesztői döntések része.
Mindenki annyi VRAM-mal rendelkező VGA-t vesz, amennyit akar, de az világosan látszik, hogy ezek az új technológiák VRAM-zabálók.
Semmi gond nem volt az NV-nek a tesszellációs megoldásaival. Saját vásárlóikat szopatták meg vele, miután az AMD a meghajtóban kezelte a problémát. De a kettő nem ugyanaz. A tesszelláció esetében a problémát az jelentette, hogy felesleges volt egy pixelnél kisebb háromszögeket generálni, mert ugye a pixel a legkisebb elem, amit a monitor meg tud jeleníteni. Itt nem felesleges a sugárkövetés távolságát kitolni, mert észreveszed a 10-15 virtuális méterre lévő dolgokat is. De ugye akinek ez nem annyira fontos természetesen kikapcsolhatja az effektet.
-
Abu85
HÁZIGAZDA
A Godfall fejlesztőit lehet bántani, de tény, hogy ők az egyetlenek, akik szabványos kóddal raktak sztochasztikus LOD-ot a játékukba. Más erre sem veszi a fáradtságot, mert egyszerűen túl soknak tartják az ezzel járó bő négy hónapnyi munkát. Inkább lekorlátozzák a sugárkövetés távolságát, mert azzal is vissza lehet fogni a memóriahasználatot. Jelen pillanatban éppen azokat a fejlesztőket trágyázod, akik a piacon egyedüliként nem az egyszerű megoldást választották, nem a sugárkövetés távolságát limitálták, hanem igenis belefektettek egy rakás erőforrást, hogy más módon csökkentsék a memóriahasználatot. De eközben mindenki azért sír, hogy a PC-be nem fektetnek a fejlesztők semmi energiát. Hát persze, hogy nem. Beleölsz valamibe négy hónapot, és csak trágyázzák a megoldásod, amikor egy nap alatt meg tudnád oldani az effekt minőségének jelentős korlátozásával, amiért a userek simogatnak.
Hardveresen nincsenek igazán problémáin. Szoftveres tényezők hiányoznak. A traversal shader igazból bármilyen compute shadert támogató hardveren üzemképes. Az összes hardveres RT-t támogató rendszerrel kompatibilis, mert csak annyi történik, hogy a futószalag bejárás lépcsője nem egy specifikus hardveren fog működni, hanem a multiprocesszorokon, ugyanis programozhatóvá válik. Erre az AMD és az NV is tud meghajtókat írni, hiszen csak a futószalagot kell a multiprocesszoron futtatni, és kész, a shader fordítót kell kiegészíteni az új shader lépcsővel. Nem egy megoldhatatlan probléma, csak ki kell dolgozni a specifikációt.
-
Abu85
HÁZIGAZDA
Amíg nincs itt a traversal shader, addig az RT egy memóriazabáló technológia. Korábban leírtam, hogy miért. Egy sugár kilövésekor ki kell választani a LOD szintet, de előre nem tudod, hogy mennyire távoli lesz a metszés, tehát nem tudod meghatározni, hogy mi az optimális LOD szint. Ergo egyszerű megoldásként mindenre kiválasztod a LOD0-t, ami jókora extra információt jelent a VRAM-on belül. Egyedül a GodFall működik másképp, és jól jelzi, hogy mekkora nehézség ezt szabványosan megoldani, mert több hónapig csak ezt fejlesztették, hogy működjön a GeForce-okon. A Radeonokon ugye egy zárt kiterjesztést használnak, ami megengedi azt, hogy a sugár kilövése után LOD-ot válts. Ez lesz majd a traversal shader haszna szabványosan.
Amíg a játékok csak elsődleges sugarakat használnak, addig van koherencia, így a memória-sávszélesség nem akkora probléma, mert a memóriaelérések nem annyira véletlenszerűek. Ezek onnantól kezdenek el gondot okozni, ha vannak másodlagos sugarak is, azok már nem koherensek, és például a DXR 1.1 egyik visszalépése, hogy nem is tudod ezeket koherens csoportokba gyűjteni. De a Microosft mégis a DXR 1.1-re állt át, mert figyelembe vette, hogy ma még a másodlagos sugarakat nem igazán fontolják meg a fejlesztők, így a DXR 1.0 előnye hasztalan, és van egy rakás hátránya, amit a DXR 1.1-gyel megoldottak. Valószínű, hogy sem a DXR 1.0, sem a DXR 1.1 nem jelenti a jövőt, hiszen hosszabb távon azért erősen korlátozzák a lehetőségeket, de egyelőre nincs jobb megoldás.
Számítási kapacitás kell az RT-hez, de nem ez jelenti az erős limitet. Sokkal nagyobb baj, hogy nem tudsz LOD-ot váltani egy sugár kilövése után, így pedig akármilyen RT effektet írsz, az mindenképpen zabálni fogja a VRAM-ot.
A Resident Evilben többféle RT lesz. Pont emiatt lő ki a memória terhelése. Maga a motor eleve egy VRAM-zabáló szörnyeteg volt, ezt már a korábbi RE címekben is lehetett látni. 4K-ban RT nélkül is megette a 13 GB-ot. Ugyanez a motor lesz most is, csak átrakják a memóriakezelést az AMD-féle D3D12MA-ra, ezzel nyernek némi hatékonyságot, de nagyobbak lesznek a textúrák, amivel buknak is. Plusz mostantól az RT effektek jellemző +2 GB-ja is hozzájön. Értik, hogy kevés VGA-n van ennyi memória, de most ezzel mit kezdjenek? Annyit tudnak tenni, mint a korábbi RE címekben, lesz benne egy dinamikus textúraskálázás, hogy ha nem fér bele a VRAM-ba a highres textúra, akkor a motor azt érzékeli, és legközelebb már a medium vagy low részletességet tölti be, hogy spóroljon. Jelen pillanatban ez a reális megoldása a problémának, aztán idővel lesznek több VRAM-mal rendelkező VGA-k.
#42770 do3om : A memóriasávszél gond, ha egy játék másodlagos sugarakat is használ, hiszen ott véletlenszerű az elérés, tehát nem jól cache-elhető az információ. De ehhez muszáj másodlagos sugarakat is használni. Elsődleges sugarakkal marad a koherencia, tehát jól cache-selhető adatról van szó. Ezt korábban is leírtam. Az AMD számára az elsődleges sugarak megfelelőek, hiszen van a GPU-kban egy rakás cache, és úgy a sávszélesség 1,6+ TB/s. A másodlagos sugarakkal van gondban az RDNA2, de ezek pusztán a koherencia hiánya miatt eleve nem elterjedtek manapság a játékokban, mert a nagyon véletlenszerű adateléréshez nincs meg a kellő sávszél egyik mai hardveren sem.
-
Abu85
HÁZIGAZDA
Nem kell ennyire parázni. Ez az AMD javaslata, ami marketing. A játék RT effektje bármilyen VGA-val jól fog futni, amin legalább van 12 GB VRAM. Persze nem biztos, hogy 4K-ban, ott 12 GB-nál több VRAM kell, de 1440p-ben bele lehet férni 11 GB-ba.
RT nélkül a VRAM-igény is 10 GB alá csökken.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#42740
üzenetére
Ez egy időbeli probléma csak, a funkció működik, de be kell paraméterezni. Azért lát az NV lassulást, mert ez még hiányzik az egyes játékokra. A gond az, hogy az AMD a SAM-et 2019 elején kezdte el fejleszteni. Az NVIDIA 2020 nyarán. Egyszerűen hiányzik az a másfél év, ami alatt az AMD kitesztelte az összes játékot. 2022 közepére az NV is el fog érni az összes címig, addig fokozatosan hozzáadják az egyes címeket. Sajnos a paraméterezés az pepecselős meló. Le kell ülni, és egyenként be kell lőni az egyes játékokra a működést. Ezt nem lehet siettetni. Amint kész lesznek ezzel a melóval, az NV sem fog lassulást látni a játékokban. Minimális eltérés egyébként bármikor előfordul, de ha 3%-on elül van az mérési hiba is lehet.
#42739 AsakuraDave : A 3060-ra fel van rakva a VBIOS. A többi hardverre még nem készült el, de nem ez a prioritás jelenleg, hanem növelni kell a támogatott játékok számát.
-
#42738
Abu85
HÁZIGAZDA
AsakuraDave
#42737
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#42737
üzenetére
Ha Founders Edition, akkor március végén jön hozzá a VBIOS, ha nem referencia, akkor Q2-ben hozzák a gyártók. De ha nem azon a nyolc játékon éppen nem játszol, amit az NV támogat, akkor felesleges vele foglalkoznod még. Az NV megoldása egyelőre nem olyan, amilyen az AMD-é, hogy minden szoftveren működik. Fokozatosan kerül hozzáadásra a szoftverek támogatása. Egyelőre erre a nyolc játékra van korlátozva: Assassin's Creed Valhalla, Battlefield V, Borderlands 3, Forza Horizon 4, Gears 5, Metro Exodus, Red Dead Redemption 2 és Watch Dogs: Legion
-
Abu85
HÁZIGAZDA
válasz
Locutus
#42716
üzenetére
Nekem volna. A GeForce mikrokódból vágják ki a lop3 utasítást. Ezzel a bányászat melletti tempó jelentősen mérséklődik, de ami ennél is fontosabb, hogy maga a hatékonyság is óriásit esik vissza a hash algoritmusok futtatásakor, hiszen ezt igazából a lop3 lapátolja össze. És ez a változás megkerülhetetlen. Az eredménye ennek az lenne, hogy az EtHash nagyjából a mostani számok tizedét hozná csak, miközben a hardverek fogyasztása igen magas maradna. A problémát valószínűleg az jelenti, hogy nem csak bányászatra használnak hash algoritmust, és a lop3 kilövésével kilőnék az alternatív felhasználást is.
#42717 Valdez : Ez is opció.
-
#42709
Abu85
HÁZIGAZDA
huskydog17
#42708
Abu85
HÁZIGAZDA
válasz
huskydog17
#42708
üzenetére
Mit számít ez? A valóságon nem változtat, ha elrejtik egy függöny mögé.
-
Abu85
HÁZIGAZDA
A másik topikban belinkelt videódban látszik az eltérés több helyen is. [link]
A részletek a lényegesek, mert az árnyékok raszterizálás mellett az apró részletekben csúsznak el. Egyszerűen mag a raszterizálás nem igazán alkalmas a jó minőségű megvalósításra, a frustrum tracing pedig drágább eljárás, és konzervatív raszterizálást igényel.A videóban ezeket érdemes nézni:
- 1:20-21-nél a növény a két kép közepein. RT-vel a finom geometriákon is van árnyék. Ez általánosan is látható a fákon is. A háttérben látszódó kis épület is jobban van árnyékolva.
- 1:38-nál van a jelenetben egy rakás árnyék, és nagyon jól látszik, hogy RT nélkül mennyire erősen kell alkalmazni a lágy szélű árnyékolást. A valóságban ennyire gyorsan nem vesznek el a részletek, csak sokkal messzebb vetülő árnyéknál. Az RT-s megoldás megőrzi a részleteket, de mégis lágy szélű. Ez szintén megfigyelhető több helyen is.Ezek azok az apró problémák, amelyekre raszterizálással egyszerűen képtelenség reagálni. Trükközheted napestig, de sosem éred el azt a minőségi szintet, amit az RT shadows tud adni. Ráadásul utóbbit nagyságrendekkel egyszerűbb implementálni.
Ha messzire lövöd a sugarakat, akkor az kellemetlen a LOD számára. Az RT a jelenlegi specifikációban egy memóriazabáló dolog, hacsak nem maradsz nagyon a kamera közelében, de ezt a játékot nem úgy tervezték, hogy szűk terek legyenek benne, tehát nincs különösebb választás, muszáj sokáig lőni a sugarakat. Az más kérdés, hogy lehetne low szint is, ahova elég lehetne 1 GB VRAM is, azzal nem enne az effekt 3 GB-ot, de sokkal rosszabb is lenne a minősége, hiszen előtted jelenne meg pár méterre minden árnyék. Effektíve úgyis visszakapcsolnád a raszterizált verziót, mert az lehet, hogy nem kezeli jól az árnyékokat, de legalább nem csak a virtuálisan 4-5 méteres körzetedben lesznek láthatók.
Van a Godfallban teljesen dinamikus GI, a Sony-val közösen dolgozták ki az alapul szolgáló effektet. Az RT esetében az a lényeges kérdés, hogy meg tudod-e oldani a jó minőséget nélküle. Sok eljárásra meglehet, például GI-ra height field vagy distance field GI, visszaverődésre hibrid SSSR. De árnyékra sajnos nincs semmi értelmes megoldás.
-
#42702
Abu85
HÁZIGAZDA
AsakuraDave
#42701
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#42701
üzenetére
Nem más szögből süt, hiszen ez egy fejlesztői kép, ahol direkt pont ugyanúgy vannak beállítva a fényforrások. De pont ez a lényeg, hogy az árnyékoknál RT nélkül az apró részleteket nem tudod normálisan megvalósítani. Egyszerűen a kapott eredmény torz lesz, és raszterizálásnál esélyed sincs, hogy ezen reális körülmények szintjén javíts. Vannak persze bizonyos trükkök, mint például a frustum tracing, de az az RT-nél is nagyobb teljesítményigénnyel rendelkezik.
Emiatt repült rá sok fejlesztő az RT árnyékokra, mert a problémát ezeknél az effekteknél csak RT-vel lehet kezelni. Más effekteknél vannak nagyon jó alternatívák, de az árnyékok túl nehezen alkalmazhatók. -
#42700
Abu85
HÁZIGAZDA
AsakuraDave
#42698
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#42698
üzenetére
A Hitman 3 az nem szimpla SSR, hanem egy hibrid megoldás, aminek az alapja SSR, de ezt kiegészíti még render to texture, illetve némelyik felületre elég a cube map, és az is van rajta. Használhattak volna RT-t is, csak lassabb sokkal, és nem ad többet.
Itt van a Godfall RT:
On:
Off:
Az RT a tipikus gondokra tud reagálni. Képesek vagyunk alapvető árnyékot kreálni nélküle, de nem tudunk pontosat. Egy csomó hiba lesz az árnyékok szélével, sokszor ez nem elég éles, vagy nem elég lágy, nem elég erős az átmenet, stb. Ezeket nagyon nehéz RT nélkül kezelni. És azt is, ahova kellene árnyék, de az istenért se tudod beműteni. RT-vel ezek egyszerűen mennek.
Ugyanez van a Dirt 5-ben is RT-vel:
On:
Off:
Ezek mind olyan apró problémák, amelyekre a raszterizáláson belül nincs válasz. A visszaverődéssel még lehet jól trükközni, ahogy a GI effektekkel is, de az árnyékoknál a raszterizálásának egészen durva határai vannak.
-
#42697
Abu85
HÁZIGAZDA
AsakuraDave
#42696
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#42696
üzenetére
Cyberpunk lelépezője nem valami jó. Sok, nagyon régi technológiát használ, amelyeket a mai motorok már bőven leléptek. Ezért számít a visszaverődés. De ha olyan SSR-t használna, amilyet mondjuk a Godfall, akkor messze nem vennéd észre a különbséget.
A Godfall az árnyékoknál azokat a dolgokat számolja RT-ben, amit nehéz raszterizálással megoldani. Szinte lehetetlen. Nagyon sok munkával közel lehet kerülni, de egyszerűbb leimplementálni RT-vel.
Ú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 T480s,14",FHD,i5-7300U,8GB DDR4,256GB SSD,WIN11,TOUCH
- AKCIÓ! AMD Ryzen 9 7950X 16 mag 32 szál processzor garanciával hibátlan működéssel
- Apple iPhone 16e 128 GB White 100% Akkumulátor 12 hónap Garancia Beszámítás Házhozszállítás
- Dell Latitude 5420 14" Touchscreen i5-1135G7 16GB 512GB 1 év garancia
- BESZÁMÍTÁS! ASUS B150M i5 7500 8GB DDR4 256GB SSD GTX 1050Ti 4GB Nbase Black Midi DeepCool 400W
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest