Új hozzászólás Aktív témák
-
Petykemano
veterán
Ezt akartam mondani.
1. Ha az amd Elindult abba a mozaikos renderelési metodikára, mint az nvidia
2. Ha jobb a dcc, mint a fijiben, v akár a polarisban volt,
3. És ha figyelembe vesszük, h a polarisnál 2304 shaderre jutott 256MB/s
Akkor lehet, hogy elég.Találgatunk, aztán majd úgyis kiderül..
-
nagyúr
és ez bypassolható, amennyiben a fejlesztőnek van rá ideje, hogy optimalizáljon? kicsit a reddites 'hello, i'm a compiler' c. történet jut eszembe róla.
@NandorHUN: már hogy ne tudnák. ne félj attól, hogy gombokért kapsz majd vegát.
[ Szerkesztve ]
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
Petykemano
veterán
Nem félő, hogy túlterpeszkedhet a program rendelkezésre álló nagysebességű memórián?
Mármint ha van 16GB HBM, meg 16GB Rendszermemória, meg még 100GB SSD, és én elkezdek olyan programot csinálni, hogy 18GB-t használna, nyilván hasznos, ha a nem, vagy kevésé használt részeket kiswappeli a rendszermemóriára. De ha 24-30gigát használna, belefuthat olyan szituba, hogy lassabb lesz, mintha valaki valamikor odafigyelt volna, hogy mennyi memória is áll rendelkezésre.
Tehát kisebb túlcsordulást tök hasznosan kezel, és biztos jobb, mintha a fejlesztőnek kéne odafigyelni, mit kukázzon ki, ha váratlanul elfogy a memória. De kétlem hogy nagymértékű túlcsordulás hasznos tudna lenni. Kivéve persze ha ezt eddig is megcsinálták a programok, csak innentől már nem kell, mert hardveresen kezelődik.A kérdés az, lesz-e azért egy soft cap, amit a szoftver azért figyelhet, hogy mennnyire érdemes terpeszkedni, vagy hogy hol várható teljesítmény esés?
Találgatunk, aztán majd úgyis kiderül..
-
#06658560
törölt tag
Ez így nagyon kitéríti a Bullshit-O-Meterem. A számítási kapacitás rohan a fenébe, de így sem tartják a lépést a memória hozzáférés oldalán. És pont az AMD beszélt pont most erről a problémáról. ami pláne nem csak a játékokat érinti, hanem minden GPGPU vonalat is. Ahol a DX12/Vulkan/Mantle soha meg sem nyikkant.
-
nagyúr
gb-s cache? olcsónak hangzik...
@Blax: rája elmondta, hogy kari előtt pár héttel tapeotolták az első vegákat.
[ Szerkesztve ]
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
#06658560
törölt tag
"A legnagyobb változás a memóriaarchitektúrát érinti, mivel az AMD szerint a jelenlegi dizájnok problémásak az új igények kiszolgálásánál az exponenciálisan növekedő az adatmennyiség miatt, amivel a rendszerek dolgoznak. Ezzel szemben a GPU-knak a számítási teljesítménye nő igazán, míg az adatok tárolásához használt memória lassan tartja a lépést."
Ezt akkor minek írtad le? A CPU-k pár MB-s Cache is problémás a sok adatmozgást igénylő HPC alkalmazásoknál, nem hiába gyúrsnak adott területen a memóriához hozzáférésre is ezerrel a piaci szereplők. egyébként mindenki a hajára kenheti a nagy számítási kapacitást, ha nem tudja etetni adattal.
-
Reggie0
félisten
Miert lenne az rossz? Pont azert van annyi regiszter egy core-hoz, hogy ne kelljen L1 cache. Gyakorlatilag ez az ami megkulonbozteti a CPU-tol. Pont az a lenyege, hogy a fejleszto el tudja donteni mit csinal es igy jobban tud optimalizalni. Persze az mar mas kerdes, hogy nem ez jellemzo a mai fejlesztesre, de ha a kacsa vizbefullad, akkor nem a viz a hulye.
[ Szerkesztve ]
-
sb
veterán
Úgy sem tudsz jobb munkát végezni a hardvernél, legalábbis az eddigi gyakorlat nem ezt mutatja.
A nem tudsz vagy nem akarsz eléggé különbözik. És az eddigi koncepció az volt, hogy tudsz és kell. Ez most ellentétes gondolat... akkor is ha a gyakorlatban ugyanaz lehet az eredmény (ha nem csinálod meg vagy szarul az kb. egyformán haszontalan)
[ Szerkesztve ]
-
félisten
Ez igazából azt igazolja, amit már sokan mondunk jó ideje, hogy sok dolog egy álomvilágban nagyon jól működhetne az AMD terveiből, de egy idő és pénzközpontú rendszerben ( játékkészítés manapság) nem működik.
Lehet, hogy mégis csak van abban valami, amit az Nv és Intel csinál jó ideje, hogy nem ad akkora szabadságot a programozók kezébe , mert tisztában vannak azzal, hogy a játékkészítők 90 % ka ( csak írtam egy számot, mert tisztelet a kivételnek) leszarja a lehetőségeket és nincs rá se pénz se idő, hogy kihasználják ezeket a dolgokat. Egyszerűbb egy kötött de gyorsabb hardveres úton nekik is haladni. valóban aza jó, ha a hardvergyártók bizonyos korlátok közé szorítják a dolgokat, mert így lehet, hogy csökken a hardver kihasználtsága, de optimáltabb lehet a grafikai motor futása adott hardveren. Én úgy gondolom, hogy ez a jó út a mai világban, így kellett volna ennek már működnie GCN 1 től. talán NV mégsem akkora hülye cég és nem véletlenül tart ott, ahol tart.[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Reggie0
félisten
Hogy ne tudnek jobb lenni, mint a hardver? A hardver nem okos, nem lat elore es nem tudja min dolgozom. Csak vegrehajtja. Lasd branch prediction. Josol valamit, de en sokkal jobban ralatok, hogy mikor merre ter ki a program, igy sokkal jobban tudom, hogy mit kell elore betolteni a hatekony mukodeshez.
-
namaste
tag
Kb. azt írod hogy az AMD egy NV-féle megoldást lecserélt egy NV-féle megoldásra.
Pedig feketén-fehéren ott van a "Legacy Architecture" nagyon sematikus ábrán: a Pixel Engine/L1 a memóriavezérlőhöz kapcsolódik, nem írja tovább az L2-be.Régebbi leírások is ezt írják (az ábrák is):
GCN_Architecture_whitepaper.pdf:
The color samples are blended using weights determined by the coverage samples to generate a final anti-aliased pixel color. The results are written out to the frame buffer, through the memory controllers.GS-4106 The AMD GCN Architecture:
Writes un-cached via memory controllersTechnikailag a crossbarból kijövő adatvezetékek a particionált L2/MC egységekhez kapcsolódnak, az L2-ben nem gyorsítótárazott adatokat egyből küldi az MC-hez, a gyorsítótárazott adatokat az L2 felé.
Szerintem ugyanúgy marad a particionált L2, annyi változik, hogy a ROP is ide ír."míg most az L2 gyorsítótár alkot egy nagy egészet, és ennek a részei lesznek a ROP blokkok"
Ez nem biztos, "Render back-ends are now clients of the L2 cache.", ez nem azt jelenti. -
namaste
tag
Csak kb. írod azt, és most is.
AMD-nél nincsenek a ROP-ok a L2 partíció/MC-khez rendelve, hanem a Shader Engine-hez; az NV-nél fordítva, a ROP-ok az L2/MC mellett vannak és nem a GPC-kben.
AMD esetén a Shader Engine-ben lévő CU-k csak a mellettük lévő 2-4 db ROP-hoz küldhetik a kiszámolt pixeleket és a ROP-ok bármely MC-hez küldhetik tovább a színeket.Az L2 particionálása azt jelenti, hogy a memóriavezérlőkhöz vannak rendelve az egyes L2 szeletek és nem azt, hogy a ROP-okhoz.
-
#25068288
törölt tag
Vedd már észre te is, hogy direkt trollkodnak, azt élvezik, ha más felhúzza magát.
Direkt kiforgatják minden szavad.
Teljesen felesleges egyáltalán ide írni, egy buta, öntelt, önfejű NV, meg intel -fan társaság.
Aki nem a kéket, meg a zöldet kedveli, azt kiutálják, megköpködik, stb.
Ezen díszes társaság Magyarország technikai szégyenfoltja, hát minden kisebb, de szakértőbb társaság már ezt az oldalt szidja-hordja, meg ezeken némbereken röhög! -
ukornel
aktív tag
Aha, dereng valami erről - újabb iteráció, nagyobb sebesség, nagyobb sűrűség, hurrá.
DE! A nagy kérdés, hogy az interposer kihozatalával és gyártási költségével sikerül-e valami áttörésfélét elérni?
Mert ha nem, akkor vagy valami EMIB-hez hasonlót kellene fejleszteni, vagy valami radikálisan újat kitalálni.KisDre #218
"A Scalability meg gondolom hogy ne legyen Polaris és Vega szerűen két architektúra egyszerre, hanem mint a Zen-t is eggyel akarják lefedni az egész palettát"Aha, lehet, hogy erről van szó. Bár én ezt a "Polaris-alsó / Vega-felső szegmens" felosztást nem érzem annyira tervszerűnek; a Polarisra inkább egy átmeneti, kísérleti sorozatként tekintek - a kísérletezésnek meg ugye nem a nagyvaddal kezdünk neki.
Szeretnék arra gondolni, hogy a "skálázhatóság" alatt már a 16384 számolóig azok darabszámával lineárisan növekvő teljesítményű architektúrát értik -
namaste
tag
A skálázást már a kezdetektől beletervezik az architektúrába, utána már csak paraméterezni kell a konkrét termékhez.
Azt írják, hogy egy SE tartalmaz:
- 1 Geometry Processor
- 1 Rasterizer
- 1-16 CUs
- 1-4 RBEs
Ezek nem csak logikailag alkotnak egy egységet, hanem fizikailag.
Annak nincs sok értelme, hogy ugyan a ROP bármely MC-t elérheti, de logikailag lekorlátozzák.
A különböző ROP - MC konfigurációkkal mi a helyzet?
Z az L2-ben. Forrás? -
namaste
tag
Vigyázz ezekkel a valaki mondta kijelentésekkel, nem biztos hogy igaz. Utoljára az R600-ban volt ring bus, miért mondanának mást, miért titkolnák?
Az, hogy fizikailag elérheti a ROP bármely MC-t, de logikailag nem, az korlátozást jelent.
Hogy hasznos, nem jelenti azt, hogy úgy is működik, szerintem is hasznos. MSAA esetén nem csak a Z értékeket, hanem a színinformációkat is nagyobb felbontáson tárolják, azt is hasznos lenne L2-be írni.
Van erre mérési eredményed, ami bizonyítja ezt a működést?(#231) ukornel
Nem azért írtam, mert valaki ezzel ellentéteset állított volna, hanem mert ez van a doksiban.Az ábrák se pontosak, össze-vissza vannak, pl. egyiken az L2 egy darabból áll, a másikon darabokban a memóriavezérlők mellett. De ez nem baj, mert különböző aspektusokat ábrázolnak és a szövegből ki lehet hámozni a lényeget.
"de az ábrán a memóriavezérlőkbe se közvetlen nyíl vezet..."
Az azt akarja szimbolizálni, hogy a ROP-ok bármely memória partícióba írhatnak egy crossbaron keresztül. És ahhoz a csíkhoz kapcsolódnak az egyéb részek egy hubon keresztül, azok se az L2-be dolgoznak, hanem a memóriába. -
namaste
tag
Ahhoz képest, hogy az AMD a legnyitottabb cég ezen a téren, elég jól titkolják, publikusan nem jelent meg semmi ilyesmi.
si_programming_guide_v2.pdf, 4. oldal:
Unified Cache. Most shader memory – vertex buffers, textures, constant buffers, UAVs, etc. – are
read/written through a shared cache. Draw indices and the CB and DB blocks do not use the shared cache.Ki lehet mérni, különböző méretű és formátumú shadow map segítségével. Amíg a cache-be dolgozik, addig gyors, ha kifut a cache-ből és a memóriába ír/olvas, akkor lassú.
(#234) ukornel
Amikor azt írtam, hogy közvetlenül, akkor az L2 kihagyására gondoltam, a szín és mélység adatokat a memóriába írja, illetve onnan olvassa. Az egész vita abból indult, hogy a Vega RBE az L2-be ment, a korábbiak nem. Abu azt írja, hogy a mélység adatokat az L2-be menti, a doksik meg azt, hogy a memóriába.
A GDS egy külön egység, azt a shadernek külön utasítással kell elérnie.
Új hozzászólás Aktív témák
- BESZÁMÍTÁS! GIGABYTE WindForce 2X GTX 960 4GB GDDR5 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!
- AMD Radeon Pro W7900 48GB GDDR6
- ASUS ROG STRIX RTX 3070 TI O8G GAMING OC - csúcskategória garanciával
- EVGA GeForce GTX 1080 Ti FTW3 GAMING 11GB GDDR5X 352bit (11G-P4-6696-KR) Videokártya