Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Igazából nem. A Fiji esetében kevés volt az 512 GB/s-os sávszél. De a Vega például már tartalmaz egy rakás olyan funkciót, amit a Fiji még nem tartalmazott. Például primitive discard accelerator, draw space binning rasterizer, második generációs Delta Color Compression. Ezek lényegesen csökkentik a memória elérések számát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De írtam neked erre, hogy a Vegának az uncore része a nagy előrelépés. A core része a GCN4-nek nagyobb volt a GCN3-hoz viszonyítva, mint amit hoz a GCN4-hez képest a Vega. Az utasítás-előbetöltés lényegesen nagyobb extra, mint a VRR. Ellenben az uncore rész már a Vegán nagyobb előrelépés.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#59
üzenetére
Benne van a cikk első oldalának legvégén a megoldás. Az AMD lényegében azzal jött elő, hogy a fejlesztők buták, és nem tudják jól menedzselni az erőforrásokat. Tisztelet a kivételnek, nyilván az AMD egy átlagos mintát tekint. A dedikált VRAM-ot, mint modellt felváltja a HBC, ami azt teszi lehetővé, hogy a fejlesztő ne is törődjön azzal, hogy melyik erőforrás melyik memóriába menjen, egyszerűen csak hagyják, hogy a hardver automatikusan megoldja magától. Ehhez építették ezt a memóriaarchitektúrát.
Valószínű, hogy rájöttek már, hogy a DX12/Vulkan alatt picit túltolták a fejlesztői szabadságot, amit most hardveresen korrigálnak.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Elméletben igen. Lényegében a fejlesztők azt kérték, hogy explicit kontrollt kapjanak a VRAM felett. Na most ez a gyakorlatban nem olyan egyszerű, mint azt sokan várták. Például a Metal API-hoz épített modell jóval barátibb, és nem sokkal kínál rosszabb lehetőségeket. Tehát a kontroll hiánya és a teljes kontroll között az Apple talált egy arany középutat. De a DX12 és a Vulkan már létezik, azok specifikációját nem lehet ennyire extrém módon átírni, ez legalább egy 5-6 éves procedúra lenne ismét. Addig pedig az AMD szerint jobb, ha olyan memóriaarchitektúra dolgozik a hardverekben, amely automatikusan el tudja intézni az erőforrások menedzselését a fejlesztők helyett.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pedig a Vega pont neked készült. Te írod mindig, hogy félsz a DX12/Vulkan játékoknál attól, hogy a fejlesztők nem tudják jól kezelni az explicit kontrollt, különösen a memória felhasználása tekintetében. Na most a Vega memóriaarchitektúrája pont azt hozza be, hogy nem is kell kezelni az erőforrásokat, mert a hardver automatikusan megoldja. Pont azoknak az embereknek való ez a rendszer, akik félnek a low-level irány hátrányaitól, ez az architektúra immunis ezekre.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#116
üzenetére
Nem kell tartani a lépést, rossz a modell, amit alkalmaznak a GPU-k. Gondolj a CPU-kban a cache-re. Ott is csak pár MB-os a tár, és elég jól elbánnak a nagy mennyiségű memóriába töltött adattal. A GPU-knál a sok szál miatt persze GB-os méretű cache kell, de ugyanaz a modell működhet, mint a CPU-knál.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az AMD pedig akar adni egy mentőmellényt a kacsára, hogy akármit is csinál mindig a víz felett maradjon. Nincs azzal gond egyébként, hogy a mai GPU-k esetében a memóriakihasználás nagyrészt a szoftvertől függ. Csak a gyakorlat azt mutatja, hogy hiába vannak meg az elméleti lehetőségek a megfelelő optimalizáláshoz, ez nem történik meg. Tehát célszerű lenne a GPU-khoz is egy ahhoz hasonló memóriaarchitektúrát kialakítani, amilyet a CPU-k használnak. Végtére is nem volt okuk feltételezni a mérnököknek, hogy nem oldja meg a GPU-s problémákat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Miért kellene cipelni? Akinek nem kell, nem használja ezt a lehetőséget az API-ban. De miért ne kellene? Úgy sem tudsz jobb munkát végezni a hardvernél, legalábbis az eddigi gyakorlat nem ezt mutatja.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#135
üzenetére
Ez akkor ér valamit, ha tud vele bánni a fejlesztő. Számos megoldás van ezekre, de senki sem tudja igazán, hogy mi a jó. Azt látjuk, hogy a gyakorlatban léteznek különböző koncepciók és mindegyiknek van valami nyűgje. Ugyanakkor komplex hardveres megoldással még nem próbálkoztak a GPU-k, lehet, hogy ez lesz a megoldás.
Nem idegen egyébként maga az irány. A Tesla P100-ban van egy hasonló konstrukció, ha a rendszer NVLINK-en keresztül van bekötve. Nem ugyanez, nem ugyanígy működik, például korlátozottabb a támogatott memóriákhoz való hozzáférés (nem tud hálózati adattárolót címezni). De az alapelv, hogy a HBM2 legyen cache megvan benne.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
És hozzájuk van rendelve egy L2 partíció a memóriavezérlőn keresztül, amibe dolgozhatnak még. Mostantól nem így lesz. Lesz egy nagy megosztott L2, és annak a kliense lesz az összes ROP blokk.
(#137) sb: Itt a gyakorlatot kell nézni, mert elméletben minden olyan megoldás, amit kidolgoztak az egyes API-kba/OS-ekbe jó. De a gyakorlatban mégsem olyan jók. Mindegyiknek megvan a maga kis hibája, amitől végeredményben kisebb-nagyobb mértékben csökken a kihasználhatóság hatékonysága. A különbség leginkább annyi, hogy ez mennyire múlik a programozón, mert nyilván az explicit API-knál nagyrészt a program felelőssége ez. De attól, hogy elméletben lehet jót írni, a gyakorlatban nem biztos, hogy mindenki jót ír. Most gondolom titeket a játékok érdekelnek, és nagyon beszédes adat, hogy itt vagyunk 27 darab valamilyen explicit API-t használó játékkal, és ezek közül a Sniper Elite 3 az egyetlen olyan cím, amelyben tényleg jól van megoldva a VRAM menedzselése. Ez nyilván jelzi, hogy persze, meg lehet csinálni, thumbs up Kevinnek, csak hát az arányok ugye.
(#145) Reggie0: Nagyon sokat kell befektetni abba, hogy jobb munkát csinálj, mint a hardver. Megteheted a Vegával is, de kicsi az esélye, hogy a mai rohanó világban, amikor nagyon időre fejlesztesz, manuálisan jobb munkát fogsz csinálni. Ha nem időre mennének a fejlesztések, akkor a gyakorlatban is sokkal jobb lenne az optimalizálás.
(#138) b. : Pontosan a pénzközpontúság vezetett oda, hogy legyen egy ilyen megoldási út az aktuális gondokra. A világ mindig változik. Amikor API-kat cserél az ipar, akkor gondokat old meg, de ez nem jelenti azt, hogy nem lesznek új gondok. Ez van. Valószínűleg sokkal jobban járnánk, ha a fejlesztők kapnának mindenhez plusz egy évet, de nem fognak kapni.
Az aktuális API-knál ugye az a kellemetlen, hogy a kernel drivert kivégezték, tehát onnan már nincs lehetőség javítani rajtuk. Marad a hardver. Egyébként nagy általánosságban a Metal sikerült a legjobban az új API-k közül. Pont megtalálta az arany középutat a régi elavult modellek és a fejlesztői szabadság között. Erre lehet a leghatékonyabban dolgozni.(#147) polgi803: Már régóta az. Sőt, a jelenlegi kiadások között most a Radeon Software kódminősége a legjobb. Ezen már nem nagyon van mit javítani, csak tartani kell a szintet.,
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nagyon nem azt írom. Az AMD-nél és az NV-nél is a ROP blokkhoz voltak rendelve bizonyos L2 partíciók. Annyi volt a különbség, hogy az NV-nél ezek össze voltak kapcsolva, míg az AMD-nél egy logikai hozzárendelés volt, tehát nem mindegyik L2 partíciónak volt ROP blokkja, de minden ROP blokknak volt L2 partíciója. A működés tekintetében az AMD és az NV sem mindent mentett az L2 partícióba. Az AMD főleg Z adatokat mentett ide, míg a blending egység közvetlenül írt a fedélzeti tárba. Olvasni meg bármit olvashatott innen.
A Vega rendszere teljesen más. Lesz egy nagy és megosztott L2 és nem is lesz particionálva a ROP blokkok között, illetve koherensé válnak a memóriaelérések. Ilyennek korábban semelyik architektúra nem rendelkezett.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mindkét gyártónál különállók a ROP blokkok fizikailag. Ennek főleg skálázhatósági oka, hogy ne kelljen csupán a ROP-blokkok számának növelése miatt újratervezni az L2 és a multiprocesszorok belső buszrendszerét. Az AMD-nél a shader engine is inkább egy logikai csoportosítás, mintsem egy eszközszinten megjelenő fizikai bedrótozás.
Annyi a különbség, hogy az NV-nél a ROP blokk fizikailag is rákapcsolódnak egy L2 partícióhoz, míg az AMD-nél ez logikailag van kijelölve. Így kap minden ROP blokk egy saját L2 partíciót úgy, hogy közben az L2 és a ROP rendszer függetlenül skálázható.
De persze a belső működésben is különbségek vannak. Az AMD-nél a ROP blokkok főleg a Z adatok írására használják a logikailag kapcsolódó L2 partíciót. Ennek nagyon prózai oka van, az MSAA így gyorsabban hajtható végre.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Természetesen a skálázás már az ISA oldalán kialakításra kerül.
Nem teljesen úgy épül fel belül a termék, ahogy a logikai diagramm mutatja. Régebben elmondta nekem az egyik tervező, hogy a GCN-nél van egy marhára széles belső gyűrűs busz és minden fel van rá húzva. Ezek pedig logikailag egymáshoz vannak csoportosítva, de semmiképp sem fizikailag. Ennek a fő oka az, hogy a logikai csoportosítás ugyan nehezebb tervezés szintjén, de végeredményben kisebb lapkát lehet kialakítani. Ennek a járulékos előnye még, hogy aszimmetrikusan tervezhetnek, lásd eltérő ROP:MC arány.
Semmit nem korlátoznak le. Annyi történik, hogy az egyes ROP-okhoz hozzárendelnek logikailag egy L2 partíciót, hogy a Z egységek oda írhassanak, így gyorsítva az MSAA-t. Ennyi történik. Hogy miért? Mert ez hasznos.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez senki sem állította, hogy nincs a ROP-oknak saját gyorsítótáruk. Itt igazából arról van szó, hogy az MSAA eltérő terhelés a Z egységek számára. Nem éri meg a legrosszabb eshetőségre gyorsítótárat tervezni, mert sokszor nagyon kihasználatlan lenne. Emiatt terveznek az általános eshetőségre, és a legrosszabb esetek lefedése érdekében minden ROP blokknak lesz egy logikailag hozzárendelt L2 partíciója, hogy az erős MSAA terhelés sem végezze ki a teljesítményt. Ezzel tulajdonképpen spóroltak a Z-cache gyorsítótár méretén, amivel kisebb lesz a lapka, de mégse lesz hátrányos annyira, mert ott az L2 partíció.
A Vega egyrészt már mindent az L2-be ment, illetve a bejelentés lényege a koherencia megjelenése, ami eddig nem volt része a hardvereknek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem titkolják. Megkérdeztem még a GCN3-nál, hogy miképp vannak ezek belül összekötve, ha már azt magyarázták, hogy minden elem függetlenül skálázható, mert eszközszinten fizikailag nem egymás elválaszthatatlan részeni, és mondták az AMD-től, hogy egy nagyon széles gyűrűs busz van belül. A memóriaalrendszer ehhez egy HUB-on kapcsolódik.
Fizikailag és logikailag is elérheti bármelyik ROP bármelyik MC-t. Csak a Z adatokat egy ROP blokk egy hozzárendelt L2 partícióba is menti, mert a dedikált gyorsítótár nem akkora, hogy erős MSAA terhelés mellett is kibírja a terhelést.
A szín gyorsítótár az nagyméretű, 16 kB-os. A Z gyorsítótár a pici, csak 4 kB-os.
Gondolom nem viccből csinálják így, de mivel ez kikapcsolhatatlan, így az eredményét megmérni mi nem tudjuk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A programozók ezekkel az információkkal nem tudnak mit kezdeni. Nincs rá ugyanis befolyásuk. A dokumentáció ott hasznos, amire befolyásod van.
Nem hiszem, hogy az működne, mivel ez a trükk specifikusan az MSAA-ra szabott. Csak az a célja, hogy az MSAA maradjon gyors, és ne lassuljon be, ha 8x-re állítod, vagy fölé.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A felfűzött egységek tömbösítve vannak. Azokban van/lehet crossbar. Például a ROP blokkok nem egyenként kapcsolódnak a gyűrűs buszhoz, hanem összevonva. Fizikailag az összes blokk együtt van rákapcsolva a belső buszra. Ettől függetlenül logikailag már szét vannak osztva. Ezek a trükkök a tranyóspórolást teszik lehetővé.
Az AMD régóta csak logikai vázlatot ad meg a lapkáról, és elsődlegesen azért, mert eszközszinten az egész teljesen másképp néz ki. Például még a Terascale 2 idején az eszközszint és a logikai vázlat igencsak hasonlított. Ma már nem.
Persze, hogy be, és az történik, hogy az MSAA-ra vonatkozó adatokat menti az L2-be. A többi megy a memóriába, vagy a dedikált Z cache-be.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
ph Az új Radeonok alapja az általános előrelépés mellett évek óta létező problémákra is reflektál.
- Gainward Phoenix RTX3080
- GIGABYTE RX 6700 XT 12GB GDDR6 AORUS ELITE Eladó! 100.000.-
- Rog 4070 Ti //KERESEM!!//
- BESZÁMÍTÁS! Gigabyte AORUS MASTER RX 6800XT 16GB GDDR6 videokártya garanciával hibátlan működéssel
- PowerColor RX 6800 XT Red Dragon 16GB GDDR6 256bit - Számla + Garancia, Ár alatt! BeszámítOK!