"H.265 HEVC dekódolás 8K @ 24 fps, 4K @ 90 fps és 1080p sebességgel 360 fps
Miért is ne lehetnének erre büszkék amúgy?"

Most arra kéne büszkének lenniük, hogy sikerült beérniük a 3 éves Pascal kártyákat multimédia fronton?
Én inkább ezt elvárható minimumnak mondanám.

Gameplay csatornám: https://www.youtube.com/channel/UCG_2-vD7BIJf56R14CU4iuQ

Nem az órajelek visznek most sok tranzisztort. Amit a TPU-n láttok diák, azok az architektúra kb. 20%-át fedik. Az konkrétan Wang előadása volt, ahol inkább magyarázás történt. Volt egy másik előadás Mika Mantortól, aki tervezte az architektúrát. Abban van leírva a lényeg, hogy mit miért változtattak. Nagyon röviden arról van szó, hogy azért az előző években igen dominánsok lettet a SIMT dizájnok. Ilyen a GCN1-2-3/Polaris/Vega, Fermi/Kepler/Maxwell/Pascal/Turing. Meg igazából az ARM-nak az új IGP-je, a PowerVR Rogue és újabb, szóval úgy az egész iparág megy ebbe az irányba már évek óta. Ki mennyire gyorsan lépdel.
Ezeknek a dizájnoknak az előnye a korábbi generációkhoz képest (például a Terascale 2-hoz viszonyítva) az egyszerűbb teljesítményorientált programozhatóság. Úgy fogalmaztak a mostani GPU dizájnok mindegyikére, hogy "easy to learn but hard to master". Ez nagyjából abban nyilvánul meg az egyik játékfejlesztő állítása szerint, aki ott volt, hogy viszonylag hamar van igen jó sebessége egy kódnak, de ahhoz, hogy tényleg hatékonyan is fusson a mai GPU-kon, már elég sokat kell dolgozni vele.
Az RDNA nem dobja el a SIMT dizájnt, de új megközelítést alkalmaz. Egy olyan rendszer kialakítása volt a lényeg, ahol nagyon könnyen jön a sebesség... "easy to master", ahogy ők fogalmaztak. Emellett a fordító két feldolgozói módból választhat: NOC (native one clock) vagy NTC (native two clock) feldolgozás. Előbbi a latency, míg utóbbi a throughput optimalizált, illetve a fordító számára sok új lehetőséget adtak az új gyorsítótárdizájnnal. A hardver ezek által sokkal toleránsabb lett bizonyos kódok felé, vagyis képes a kódhoz igazítani a működését. Ezt a megoldást ők ILP capable SIMT-nek hívják.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Ez papíron nagyon jól hangzik, pont ugyan úgy ahogy a Vegának is bizonyos képességei nagyon jól hangzottak, de hol van a gyakorlati eredménye?...

Annak kéne örülni hogy végre megvan nekik a 1080Ti teljesítménye (ha egyáltalán) úgy is, hogy nem kell hozzá HBM meg 300W TBP? Ez nem eredmény, a 1080Ti egy 2017 márciusi kártya, a Navi-ra meg még mindig csak várunk...

Persze valószínűleg nem rossz az 5700 XT, de ha melléállítod akár a konkurenciát akár az első Vegákat, annyira leromlik a Navi ár/érték aránya, hogy onnantól ész-érvekkel kb. lehetetlen megindokolni a vásárlását.

[ Szerkesztve ]

Turenkarn

Ez nem képesség. A képességeket támogatni kell. Ezt nem.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

"onnantól ész-érvekkel kb. lehetetlen megindokolni a vásárlását."

Hát a FidelityFX az smafu?!

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Nem kell ezen kínlódni. Amd saját magával szúr ki, másik meg, hogy a fő piac nem a közép eu hanem a többi ahol 100€ ide vagy oda nem gond. Nézd meg 2080ti 1100€. Szerinted aki megveszi érdekli őt mennyi a kártya?! Nem mert ő játszani akar és megfizeti.
Amd ha azt a politikát követné mint a 7xxx korszakban, hogy hasonló teljesítményt árult 50-100€ olcsóbban, akkor sokan áttérnének oda. Vga legyártása 100-200$ között mozog. Többi haszon, adó meg a többi!

V1200 - 18CORE - SUPRIMX

A FidelityFX működik más hardveren is. A Radeonon annyi a különbség, hogy nem szabványos HLSL 5.x, hanem HLSL Ext. kódot futtat.

A RIS, ami Radeont igényel (konkrétan RX 5700-at), mert az ugye a Radeon Software-be van építve.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

"Ez egy "elvileg" nagy tomegeknek szant Polaris-t valto nepkartya akart volna lenni, amit kemenyen arerzekeny vasarlok vesznek."

Én is erre számítottam, hogy lesz valami konkurenciája a 1660/1660Ti párosnak, aztán (eddig legalábbis) RTX 2060-2070 konkurencia lett belőle. Hivatalosan korábban ugye csak azt kommunikálták, hogy Radeon VII alá jönnek az új kártyák, de persze, ez kissé tág megfogalmazás.

Sajnálnám, ha nem lenne teljes line-up még az idén, de ez van. Azokat az RX 460/470/480/490-eket is le kéne váltani valamikor.

[ Szerkesztve ]

Majd ha kifogynak a raktárakból,akkor jön a Polarist leváltó Navi.

Amikor nincs remény! Jusson eszedbe nincs isten, csak én!

"Emellett a fordító két feldolgozói módból választhat: NOC (native one clock) vagy NTC (native two clock) feldolgozás."

Tehát ugye Wave32 1 clock alatt vagy Wave64 2 clock alatt, ezt tudja az RDNA. A GCN-nél meg csak Wave64 van, az is 4 clock alatt.

De ebben mi a fene a nagy innováció? Az NVidia már a Fermi (vagy még előbb?) óta Warp32-t használ, ha jól tudom azt a Feminél 2 clock alatt hajtja végre, de valamikor óta csak 1 clock, a Volta / Turing óta biztos, szóval az AMD inkább felzárkózott az NV-hez.

Persze, az jó, ha az AMD on-the-fly a Wave64-et szét tudja szedni két Wave32-re (gondolom ez akar lenni az ILP vagy VLIW jellegű működés), de ennél kicsit több kell.

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Érzékeltetendő hogy mi jön most ki és hova kell belőni.

Az AMD mit ígérget? Inkább csak a szokásos hype van, de arról nem az AMD tehet. Ha egy kétszereplős piacon az egyik gyártó 6 éve nem csinált igazán ütős terméket, akkor a nagyközönség minden évben várja tőle a csodát. De ezért ne az AMD-t hibáztasd, ha te is beállsz az R=1 userek sorába és csalódsz.

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Gondolkodtam, de látok buktatókat

Nagyon nagy jóindulattal vegyük 2080 teljesítményűnek a 40CU-s kártyát. Felezd meg (20CU) és az RX580/1060/RX590 magasságában találod magad. Extrém kihajtással (v 20 helyett 24CU-val) esetleg befogható egy 1660 ti/ 1070 (ámbátor azt talán praktikusabb lenne egy 32CUra vágott verzóval felülről befűgni)
Ha az 1660TI-t alulról akarod fogni, akkor azt olcsóbban is kéne adni.

De ha az eddigiek $380-450-500, akkor ennek a lapkának a felezettje a $200-300 ársávba fér el.
Tehát a $200-300 ársávba túlhúzott pici lapkákkal hozni a polaris szintjét nagy kunszt.

Hol tévedek?

Találgatunk, aztán majd úgyis kiderül..

Nem teljesen. A NOC és az NTC nem csak erre vonatkozik. Nyilván a része rendre a Wave32 és a Wave64, de például a Wave32 nem sokat ér akkor, ha nem tudod elfedni a memóriaelérés késleltetését. Ez tehát önmagában nem működik, kell hozzá egy másik képesség, ami részben szoftveres, de a lényege a gyorsítótár tartalmát figyelembe vevő ütemezés. És emiatt van az, hogy egyetlen korábbi SIMT GPU-nál sem éri el az 1-et az egy munkaelemre levetített IPC. Az, hogy a Navi erre képes legyen, durván ki van tömve cache-sel. Összesen 336 kB-nyi cache-ről beszélünk itt per multiprocesszor. Ezzel szemben a GCN-ben van 80 kB, a Turingban van 96 kB. Persze a multiprocesszor az eléggé laza megfogalmazás, hiszen ezt lehet egyszerűre és bitang komplexre is tervezni, de ha per-ALU-ra vetíted le ezt, akkor a Navi esetében 2,625 kB/ALU, míg a GCN és a Turing esetében ez az érték rendre 1,25 és 1,5. Gyakorlatilag a cache-rendszer az oka annak, amiért olyan magas IPC-t lehet elérni munkaelemekre levetítve. Emiatt nem csak a Wave32-ről van szó, mert az igazából nem ér semmit egy ilyen cache-rendszer nélkül. A GCN-en is lehetne Wave32-t csinálni, vagy a Turingon is Wave16-ot (ők warpnak hívják, de igazából mindegy), de szart sem érne, mert csak szopatnád az architektúrádat azzal, hogy nem lesz elég wave elfedni a memóriaelérést. Gyakorlatilag rosszabbul járnál a Wave64 és a Wave32 módokhoz képest. Nem is kínálja fel a GCN és a Turing a felezés lehetőségét. A hardver csak drámait lassulna tőle.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Csak pont nem az árérzékeny vásárlókat célozták meg. Ez itt a nagy baj.

V1200 - 18CORE - SUPRIMX

arerzekenyeknek ott a teljes NV paletta. +Super

[ Szerkesztve ]

Első AMD-m - a 65-ös - a seregben volt...

Arra a táblázatra gondolsz, ahol az RX5600 mellé ez volt írva?

A gond az, hogy szerintem ez marketingben megint csak egy kihagyott ziccer. Ha jönne RX5600, akkor én a helyükben már most kommunikálnám, hogy a népkártya készülőben van, közben meg szórnám ki a Polarisokat, ahogy csak tudom. (Mondjuk ezt az utóbbi időkben csinálták is a game bundle-ökkel.)

Itt megint csak a késlekedést (nem feltétlenül tökölést, hátha a háttérben mentik, ami menthető a desktop Navival) látom.

[ Szerkesztve ]

S akkor elértünk oda, hogy a GCN 4 ciklus késleltetése azért van, mert memória-alrendszer lassú, míg az NV 1-2 ciklusa azért mert náluk gyors, függetlenül attól hogy mekkora az egy ALU-ra jutó cache. Amiben nincs semmi új, de jó hír, hogy Navi / RDNA legalább irányban van.

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Ez jogos, az AMD nem ígérget semmit, figyel arra, hogy hivatalosan mit kommunikálnak. (Bár azért Koduri is nyomta a hype-ot olyan mondatokkal a Vega idejében, hogy "várjátok meg a gaming drivereket" és hasonlók.)

Viszont egy kompetens marketing csapat tudja kezelni ezt is, mert nem "szokásos hype" alakult ki, hanem a "1080 teljesítmény 250 dodóért" vagy "RX 590 teljesítmény 75W TDP-ből." Marketingből szerintem valamennyire lehetne kezelni az ilyen durva wishful thinking helyzetet. (Vagy nem kezelik, mert látják, hogy a Navi pl. túl drága lesz a 200 dolcsi alatti szegmensbe vagy valami. De akkor is, valamilyen kommunikáció jobb, mint a semmilyen.)

[ Szerkesztve ]

Ez még mindig túlegyszerűsített. Tehát a GCN-nél egy SIMD16 10 wave-et képes futtatni és egy wave lefuttatásához négy ciklus kell. De nem azért kell ennyi, mert 3 ciklusig pihizik, hanem azért, mert egy wave 64 lane széles, tehát egy wave-ből egy ciklusban csak 16 lane-t futtat. Most itt megjegyezném, hogy a Polaris esetében már 8 wave-re lett csökkentve az IB mérete, de ez igazából nem túl lényeges, 6 wave fölött elég jól le lehet fedni a memóriaelérést. Ha most minden klappol a GCN-ben, akkor a peak érték VALU szintjén 1 lane/clock.
És a munkakiosztás is számít, a GCN úgy működik, hogy megvan az adott erőforrásigénye a feladatnak, és arra futtat x wave-et. Tegyük fel, hogy ötöt. Ilyenkor az új wave-ek adagolása úgy történik, hogy mindegyik SIMD16 kap egy új wave-et, és ezek közül maximum egy lehet vertex shader wave, mert azok tipikusan eszik a regisztert és a cache-t. A compute egy picit bonyolultabb, mert ott az LDS is bejön a képbe, mint limit. De ugye asznkron compute-ban tudod mixelni a grafikai és a compute munkákat, csak legyen elég erőforrásod, hogy legalább 4 wave fusson per SIMD16. De persze van egyébként kiterjesztés is, ami a wave_limit, mert sokszor a cache-hit többet ér, mint a memóriaelérés átfedése. Nagyjából hasonlóan működik az összes többi modern GPU, az arányoknál van különbség, de ugyanúgy lehet egy kódnál fontosabb a cache-hit, mint a throughput, ugyanúgy limit lesz az LDS és a regiszter mindenhol, leginkább az LDS, stb. Ez az, amit értettek azon, hogy a mai architektúrákat könnyű megtanulni, de nehéz olyan kódot írni, ami igazán jól kihasználja a multiprocesszorok képességeit. Ha sok wave fut az is lehet baj, ha kevés, az is, aztán milyen feladatokat érdemes egymás mellett futtatni, hogy legyen elég regiszter+LDS ahhoz, hogy elég wave futhasson, stb.

A Navi ezeken annyit változtatott, hogy a multiprocesszor olyan robusztus, hogy lényegében egy "just works" típusú rendszer lett. Tele van cache-sel, képes a saját működését a munkafolyamathoz igazítani, az ütemezés a cache tartalmához igazodik. Ha a késleltetésből származik elő, akkor úgy működik, ha a throughputból, akkor úgy. Tehát lényegében írsz egy kódot, és minden olyan optimalizálás, amit ma azért csinálsz, hogy igazodj a hardverek limitjeihez, a munkacsoportok mérete ne hasson rosszul a vektorregiszter lokalitására, ne legyenek rossz hatékonysággal használva az I-cache-ek (ez explicit API-val kiemelten fontos), a wave-ek tényleg megfelelően legyenek kiosztva, azok a Navinál igazából már nem kritikusak. Lehet ezekre optimalizálni, de arányaiban nagyon gyorsan megvan az az optimális kihasználtság, amiért a GCN-en, illetve a Turingon sokat küzdesz, ráadásul sokszor eltérő optimalizálási stratégiával.

Érdemes megnézni, hogy a Navi mennyire teker olyan kódokban, amit tipikusan Turingra írtak. Például a BF5 egyes shaderei, ahol kifejezetten arra optimalizál a motor, hogy az L1 gyorsítótár aktívan használva legyen, mivel a vektorregiszterek újrahasznosítási lehetősége tipikusan rövid. A Navinak ez pont csemege, mert négyszer nagyobb L1 gyorsítótára van, mint a többi hardvernek, illetve még van egy extra alacsony késleltetésű L0 gyorsítótár is a két SIMD-re. Mindegy, hogy a shadert Turingra optimalizálták, hardverből le van kezelve az a probléma, amire a DICE optimalizált.

Ennek egyébként akkor lesz nagy hátránya, ha elkényelmesedik a piac, mert oké, hogy a Navira gyorsan megvan a sebesség (konzolon fut, a PC-s meg majd vesz gyorsabbat mentalitás), de például a GCN, a Turing, és lényegében az összes régebbi GPU nagyon is igényli ezeket az optimalizálásokat. És nyilván ezek azért még maradnak egy darabig, nem is kevés ideig. Tehát nem szabad átesni itt a ló túloldalára.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Persze én értem, hogy 4 ciklus azért kell, mert SIMD16-on ennyi ciklus alatt hajtódik végre a Wave64. Tehát nem büntetőciklusokról van szó. Azonban ebből a működésből az következik, hogy az architektúra sokkal jobban kihasználtságlimites, hisz a GCN-nél 64 ALU-t 4 Wave-vel kell etetni, míg Navi-nál 64 ALU-t akár 1 Wave64-gyel is megetethető (ami WGP-n belül két Wave32 lesz), de legrosszabb esetben is csak 2-vel kell etetni.

Na most a GCN mivel kihasználtságlimites, ergo sok minden fut rajta lassan, mert így vannak jól kihasználva az ALU-k. Viszont ebből következően több adatnak több ideig kell a cache-ben lennie, tehát cache és sávszéligényes. A Navi ezen ott javít, hogy kevesebb minden fut rajta gyorsan, így kevesebb adatnak, kevesebb ideig kell a cache-ben lennie. Nem ezt csinálja a Maxwell óta az NV?

Persze, amúgy eleve a GCN-nek nagyon robosztus a vezérlése, hát még a Navi / RDNA esetén... Ezt nem kell magyarázni, ez tényleg jó, az NV sehol sincs ebben. Csak én ugye a fentiről beszélek, mert a helyzet fordított, az AMD-nek kell beérnie az NV-t.

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Ez alapján tökre illik rá, hogy a gpu nem késleltetésérzékeny. Csak közben de.

De had értsem meg én is, hogy ha van egy wave64, ami a max 16 széles feldolgozótömbön 4 órajelciklus alatt tud lefutni csak és a 4x16-os CU-n 4 wavefrontnak kellene folyamatosan futnia a maximális kihasználtsághoz.

Akkor miért kell 64 hosszú (?) Wavefrontot futtatni? Ez minek a hülye ötlete volt?
Vagy miért kell 16-os tömbökre bontani a CU-kat, miért nem 64, amit szükség esetén Lehetne bontani 2/4 felé?

Találgatunk, aztán majd úgyis kiderül..

Nem azzal van gond, hogy 64 elemes a Wave, hanem azzal, hogy lassan hajtódik végre. GCN vs RDNA konyhanyelven, mindig 64 ALU-ra vetítve:

GCN:
- 4 sávos sima út (4x SIMD16)
- kamionnal 50 km/ó (64 szál @ 4 ciklus)

RDNA:
- 2 sávos autópálya (2x SIMD32)
- kamionnal 100 km/ó (64 szál @ 2 ciklus)

A jármű-áteresztő képessége ugye mindkettőnek ugyanakkora. A szabály az, hogy egy sávon egyszerre csak egy jármű tartózkodhat. Tanulságok:

1. A késleltetés eltérő, tehát ha csak 1 kamion van, akkor az RDNA kétszer gyorsabb.

2. Maximális kihasználtsághoz a GCN-nél mindig kell 4 kamionnak mennie az úton, míg az RDNA-nál elég 2 is.

3. Ha a kamionosok fizetési igényét nézzük (cache igény ), akkor adott mennyiségű áru leszálllítási költsége feleannyiba kerül az RDNA-val, hiszen ugyanúgy 4 kamion kell, de kétszer gyorsabbak a kamionok, így egyszerre csak 2 van úton, nem 4.

Ugye kamion = Wave64. Nem volt szó viszont a Wave32-ről: az egy speciális furgon, ami 200 km/ó-val képes haladni, de csak a kamion kapacitásának felét tudja. De csak indokolt esetben hatékonyabb, amikor késleltetés-érzékeny feladatról van szó. Szóval valójában:

RDNA:
- 2 sávos autópálya (2x SIMD32)
- kamionnal 100 km/ó (64 szál @ 2 ciklus)
- furgonnal 200 km/ó (32 szál @ 1 ciklus)

Egyébként az NV legutóbbi architektúrái 64 ALU-ra vetíve így néznek ki:
- 4 sávos sima út (4x SIMD16)
- furgonnal 100 km/ó (32 szál @ 2 ciklus)

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

N1 hozzászólás, ezt így tanítani kellene

"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)

Engedd meg, hogy lefordítsam egy számomra autentikusabb példára. Mindamellett, hogy persze érthető és most hallgattam meg Steve Burke és David KAnter beszélgetését, ami szintén tisztított a képen.

Hasznos volt a magyarázatod, de nem haragszol, úgy vélem, pont az maradt ki, amire rákérdeztem:
- miért kamion = Wave64 (ami ha jól értem egy 64 darabos adatcsomagot jelent)
- miért olyan áteresztőképességű utakat használunk, ami az RDNA-ban már kétszeres?

Utak helyett folyóval illusztrálnám, amin kompok viszik át az autókat.
Az autók az adatok.

GCN:
- 4db 16 férőhelyes komp (4x SIMD16)
- maximum 64 autó átvitelére lehet egyszerre jegyet váltani.

RDNA:
- 2db 32 férőhelyes komp (2x SIMD32)
- lehet 64, de már akár csak 32 autó átvitelére is jegyet váltani.

Az a szabály, hogy akik együtt váltanak jegyet, azok kénytelenek mind ugyanazon a kompon menni. Hiába tűnik úgy, hogy a 64 autó átszállítására a 4db 16 férőhelyes komp ideális. Valójában 64 autó átszállítására a GCN esetében 1 kompnak 4x kell fordulnia, akkor is, ha egyébként a másik 3 komp sajnálatos módon nem csinál semmit. És sajnálatos módon akik már átjutottak a túloldalra, nem távozhatnak, amíg mind a 64-en biztonságosan át nem értek.

A GCN maximális kihasználtságához 4 csoportra lenne szükség, akik együtt váltanak jegyet.

Az RDNA abban segít, hogy ha 64-en állnak össze és váltanak jegyet, akkor azok még mindig csak egy komppal utazhatnak, de a 32 férőhelyes kompnak elég csak kétszer fordulnia. Míg ha történetesen 32 autós áll össze, akkor akár egy fuvarral átérhet az egész csoport a túloldalra és mehet dolgára.

Tehát a kérdés:
- Miért szabály az, hogy 64-en válthatnak csak egyszerre jegyet? Ha tudjuk, hogy a kompunk 16 férőhelyes és egy csoportot csak egy komp tud szállítani, akkor miért nem 16 engedjük, hogy 16 fős csoportokban váltsák meg a jegyet?
- Vagy ha tudjuk, hogy 64-es csoportokban jönnek/jöhetnek csak a kocsik, akkor miért szarakodunk 16 férhelyes kompokkal, miért nem dolgozunk 64 férőhelyesekkel?
Lehet olyan, hogy több nem 64 fős csoport akar átutazni? Abban az esetben pont hasznos, ha több kisebb komp van.

Szóval ha tudjuk, hogy egy Wave64 csak egy SIMD csoporton tud tudni, akkor miért nem Wave16-ok vannak? A wave64 mindig 64 adatot jelent, vagy csak maximum 64-et? Miben jelentene hátrányt ha 16 hosszú lenne a max?

Találgatunk, aztán majd úgyis kiderül..

Meg a perf/W-ról jutott eszembe, meg hogy mit tud a navi, meg ilyenek.
Hogy vajon hogy fog ez belemenni egy mobil GPU-ba?

40 CU ~1700MHz-en ~ 2070, 150W
10 CU ~1700Mhz ~1050, 35W
10 CU ~1000Mhz ~ RX 550 ~ 15W

Így?

Ehhez képest hol tart egy adreno?

Találgatunk, aztán majd úgyis kiderül..

A kompos példád azért nem jó, mert az alapján értelmetlen kérdések merülnek fel.

Ha mindenképp komppal szeretnél analógiát, akkor a komp sebessége lényeges, nem a fordulásszáma. Mert a te példádban a 16 fős kompnak mindenképp 4x kell fordulnia ami real life értelmetlen. De ha az időt nézzük, akkor értelmesebb, érthetőbb. Szóval kompos példa:

GCN:
- 4db 64 férőhelyes komp
- egy komp megfordul 20 perc alatt

RDNA:
- 2db 64 férőhelyes komp
- egy komp megfordul 10 perc alatt

De most ugyanott vagyunk, mint az én kamionosommal.

Annak az oka, hogy nem Wave16, hanem Wave64 van, eléggé prózai: throughput. Azaz egy utasítással minél több művelet végrehajtása. Különben GCN-nél egy CU-ba 4x annyi ütemező meg minden kéne.

Az NV anno a Warp32 mellett tette le a voksát, de az ugye jóval régebben volt (G80, 4 évvel a GCN előtt), de ma is 32 szálas egy Warp az NV-nél. Az NV egyébként SIMD8-cal kezdte a G80-nal, a Ferminél jött a SIMD16, ami azóta se változott. A GCN is ugye SIMD16-ot használt. Gondolom rohadt nehéz mérnöki munka lehet szélesebb SIMD-et csinálni, most jött el csak az ideje.

Így utólag belegondolva lehet az AMD tévedett a 64 szállal kapcsolatban, legalábbis grafika terén, mert ugye compute-ban meg igencsak jó. Az elmúlt 7 évből legalábbis ez derült ki. És plusz bizonyíték, hogy a Navi pont ezen változtatott és behozta a Wave32-t, amihez ugye duplázni kellett az ütemezést, stb. Az meg már csak extra, hogy egy Wave32 egy SIMD32-n fut egy ciklusig.

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Alacsonyabb fogyasztási kategóriában is neveztek 10 CU-nál nagyob lapkákat, csak még Vegából s Intel/Apple exkluzív formában 4 GB HBM2-vel
Vega M GH - 24 CU (1536:96:64) -> Navi M ? "XT" ~ 1660 Ti
Radeon Pro Vega 20 - 20 CU (1280:80:32) >= 1050 Ti -> Navi M ? "Pro" ~ 1650 Ti
Kétlem, hogy ALU mennyiségben Nv alá igérnének, esetleg egálban hoznák ki az adott GPU-t.
Itt én a nagyobbik Navit esetleg 256 a kísebbet 128 bit GDDR6-tal tudnám elképzelni.

[ Szerkesztve ]

Hozzátéve, hogy elvileg még egy Navi 12 lenne a csőben, amit én Navi 10 alá gondolnék és mobil szegmensben érdekelt. De mobil vonalon érdekes lehet, hogy készül-e Navi 10-ből (kezdetben csak mobil vonalra) még alacsonyabb CU számú (a la 470D) variáns, amit 1660Ti ellen szánnak.

[ Szerkesztve ]

10 CU biztos nem lesz. A Navi-ban 40 CU van, ami igazából 20 WGP, 2 SE x 2 PU x 5 WGP csoportban. Szóval 20 CU-s (1 SE x 2 PU x 5 WGP) Navira számítok, 128 biten. Az kb hozna egy Polaris szintet 100 wattból, feltéve ha az órajelet nem nyirbálják meg. Utóbbi esetben simán lehetne < 75 wattból egy RX 570 szint.

Ennél kisebb talán egy 12 CU-s (1 SE x 2 PU x 3 WGP) 64 bites mininavi lehetne, de szerintem értemetlen, mert jövőre elvileg jönnie kéne a Navi-alapú Zen 2 APU-nak.

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Szeretem mikor példákkal beszélgettek itt mert az széleskörben érthető
PH Popular Hardver
csak aztán óvatosan a kompkkal kényes téma ez most még a végén Clark Ádám kell a futószalagba is.
Igen a sebesség egyértelműen hiányzott a kompokból.
lehet a dual Cu-ra is kellett volna mondanod egy példát egy építkezésen pakoló két munkással akik az ablakon adják be a cserepet (cache) és emiatt nem kell két munkásnak fel le szaladgálni a lépcsőn dupla ideig.
Így talán azt a vitát is megúsztuk volna és "a DCU az más" ennyi.

"így utólag belegondolva lehet az AMD tévedett a 64 szállal kapcsolatban, legalábbis grafika terén, mert ugye compute-ban meg igencsak jó."
Nem tévedett csupán közös tervezés...
Eddig is beszélte a reddit népe hogy a Rdna játék arhtektúra és szétválik a computesúlyos GCN-től.
és nocsak a MAC 4 Vegával (2*2) azaz GCN-el erősít (sok ember meghökkenésére) a compute force-os területen.

Amire nem harapott rá fura módon senki mint téma az a RNDA2 fix funkciós működése
"2020-21 will pack some fixed-function hardware for certain real-time ray-tracing effects."

[ Szerkesztve ]

A kompos példámban egy forduló egy órajelciklus. Így nem kell belékeverni az adhoc választott sebességet.

Mert valójában is amikor jön egy 64 adatos wave, az bekerül a CU egyik SIMD16-os csövébe, ami 4 órajelciklus alatt (4 fordulóval) tud végezni a csomaggal.

A kompos példában csak az a kérdés merül föl (ami a kamionosnál soha nem merülhetne fel), hogy miért is kell 64 autónak.összeállnia egy jegyhez.

Ezt válaszoltad: Wave64 - throughput. Ha nem így lenne, akkor a csoportok (wavek) kezelése több adminisztrációs erőforrást igényelne. (Mondjuk több rajzolási parancsot? Több regisztert, buffert, azélesebb ütemezőt)

Rendben. De amikor eljut egy wave (64) a CU-ba akkor ott miért nem lehet azt egy helyett egyszerre 4 SIMD16-ra ráküldeni - hisz ugyanaz az utasítás. Egy CU miért nem tudja a neki leküldött wave-eket a saját erőforrásain optimálisan vágrehajtani a wave tényleges elemszámától függően?

A másik kérdést, hogy miért nem szélesebb a SIMD feldolgozó megválaszoltad. Köszi

Találgatunk, aztán majd úgyis kiderül..

+stratova

Ja persze, én se gondolnám, hogy az aMD gyártana 10CU-s lapkát, csak IGPben.
(A navi14 lesz elvileg még. Elvileg kisebb. Navi12-ről még nincs írásos bizonyíték)

De igazából a Samsung dealen ábrándoztam. Hogy ezekkel a számokkal az RDNA-ból hogy jön ki egy versenyképes mobil gpu?

David Kanter azt Mondta, eddig annyira nem volt szempont a tényleg alacsony fogyasztás- függetlenül attól, hogy normális órajelen normális fogyasztása volt a gcnnek, de innentől az amdnek nagyon rá kell gyúrnia az energiahatékonyságra

Találgatunk, aztán majd úgyis kiderül..

Én értettem, hogy egy forduló az egy órajelciklus, csak nem realisztikus a példád. Szerintem az én kamionos meg furgonos példám a 64 meg 32 migránsos kapacitással sokkal jobb. De ezen ne vesszünk össze.

A Wave64-et egy SIMD végrehajtón kell átpörgetni, nem lehet többfelé bontani. Vagyis lehet, a Navi ezt csinálja, de ez láthatóan nem egyszerű, ha csak most sikerült megcsinálni. Az NV-nél is egy SM-en belül hiába látsz 32 ALU-t, az valójában 2x16, szóval egyszerre két Warp32 fut, aminek ugye 2 órajel kell.

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Kérdés "mainstream standard" lesz e most a 2SE, 2x2PU, 2x2xX DCU felállás.

Mert a Hawaii-nál bemutatkozó 4 SE izmosabb frontend backend, felállás évek alatt Tongán át egészen Vega 12-ig (Radeon Pro Vega 16/20) szivárgott le.

A sokat (átnevezést) megélt Cape Verde után pedig Polaris 12 1 SE-ről 2-re hízott. Ez utóbbi lapka korábbi driveres morzsák alapján, egy ideig még velünk lehet az OEM-eknek (esetleg notebookgyártóknak) "hála" RX 630, 640 néven.

A fentiekből én afelé hajlok, hogy a korábbi standard 2 SE-hez hasonlóan (Tahiti, Pitcairn, Bonaire), a mostani 2SE, 2x2PU több lapkát is érinthetne, "csak" a CU-k mennyiségét backendet és memóriabuszt variálná AMD.

Beszélgetnek itt a Wave-ekről meg mindenről, ha már úgy is ez a téma, hátha segít...

Turenkarn

NV összekakilta magát a Navi-tól, mert veri az RTX2070-et. Legalább lesz verseny.

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

fú de fasza áron lesz a sima 2060!