AMD/ATI - RDNA3 (Navi 3X, Radeon RX 7000 Serie, tlw. Chiplets, 5/6 nm, 2022) [Archiv] - Seite 11

BlacKi

2022-06-27, 17:58:08

boing, da haste recht. aber ich komme auf 1.8 (80% Mehrleistung) weil AMD selbst gesagt hat das sie die TDP nicht so stark anheben werden, also eher nur um 20%. Das heißt 1.5*1.2
naja, den neuen stecker bringt man nicht mit nur 360w. ich denke schon das es 400w sein werden. vl auch 420-430, je nach dem welche ziele man hat. könnte mir denken, das man die 4090 kassieren will, und zur not reizt man das dann aus. auch wenn dann kurze zeit danach eine 600w 4090ti mit fullfat chip bringt:biggrin:

Die gesamte Folie ist doch schon kompletter Witz. Hat NV bei der Betrachtung vergessen, dass Ampere wesentlich mehr säuft? Zudem verbraucht weder Turing 240W noch Ampere 320W. Selbst wenn ich die 240W als Bezugslinie nehme komme ich bei Ampere auf eine Effizienzsteigerung von 50%, und dann höchstwahrscheinlich im Bestcase (eventuell RT+DLSS). 60fps vs 90fps.

das diagramm ist schon richtig und du kannst 125w bei 60fps ablesen.

ausserdem ist das nicht auf ein modell bezogen, sondern architekturbezogen. das hat halt nichts mit dem zu tun was wir nachstellen könnten.

dargo

2022-06-27, 18:02:23

naja, den neuen stecker bringt man nicht mit nur 360w.
Und warum nicht? Vielleicht hat man einfach keinen Bock 3x 8Pin zu liefern. Zudem legen die ganzen AIBs eh wieder xWatt drauf für fast nichts. Eine hypothetische 375W (Referenz)Karte schließt nicht aus, dass da noch 450W Dinger oder gar mehr kommen.

Linmoum

2022-06-27, 18:05:53

naja, den neuen stecker bringt man nicht mit nur 360w.Es ergibt keinen Sinn, 3x8-Pin statt den 12VHPWR zu nutzen. Davon ab gehe ich fest davon aus, dass der Standard wird und das gilt dann auch für 200W Karten. Vielleicht noch nicht diese Gen, aber spätestens danach. Ein einheitlicher Anschluss für alles und fertig.

BlacKi

2022-06-27, 18:44:09

absolut richtig, für 375w bräuchte man nur 2x 8pin. deshalb gehe ich von mehr watt aus. und bei den günstigeren sparsameren modellen, wird man bei 1x und 2x 8 pinbleiben, weil billiger. lizenzen und so, und die leute haben noch keine passenden netzteile, und adapter sind scheiße.

ich weiß, irgendwann muss man anfangen, aber das drückt man am besten von oben durch, und stellt nicht alle auf einmal um.

bei dem interview hat man ja gesagt, da der neue stecker kommt, weil man mehr verbrauchen wird. diese korrelation scheint mir nicht willkürlich.

dargo

2022-06-27, 19:23:34

absolut richtig, für 375w bräuchte man nur 2x 8pin. deshalb gehe ich von mehr watt aus.
:rolleyes:
https://www.igorslab.de/wp-content/uploads/2021/03/Intro-3-1024x787.jpg
Bei 344W.
https://www.igorslab.de/powercolor-rx-6900xt-liquid-devil-im-test-gut-gekuehlt-ist-halb-gewonnen/4/

Linmoum

2022-06-27, 19:29:09

Eine GPU mit 210W stattet doch auch niemand mit nur 1x8-Pin aus. Ist halt Quatsch, sowas auf Kante genäht zu machen. Und den Stinkefinger zeigst du den Kunden damit auch, weil das effektiv OC unterbindet.

basix

2022-06-27, 20:31:20

Höhere Wattagen sind nur ein Aspekt. Vorteil des neuen Steckers ist ja auch, dass er deutlich kleiner ist und man nur noch 1x Stecker braucht. Kostenreduktion (1x Stecker anstatt 2-3x), Platzersparnis auf dem PCB, einfacheres PWR-Layout. Ich erwarte, dass zukünftig alle Karten >150W mit dem neuen Anschluss daherkommen werden. Langfristig evtl. sogar alle >75W (alle Karten mit zusätzlicher PCIe Power).

- Ein PCIe 8p Stecker misst 18.0 x 18.1 x 10.0mm
- 12VHPWR 12p Stecker misst 18.9 x 12.2 x 8.9mm

https://hexus.net/media/uploaded/2021/10/d936bf03-9332-4fb2-abd0-73cda52b7b23.jpg
https://m.hexus.net/tech/news/graphics/148492-diagrams-12vhpwr-600w-connectors-gpus-spotted/

Hier die entsprechende News von Igor dazu:
https://www.igorslab.de/bis-zu-600-watt-power-fuer-grafikkarten-mit-dem-neuen-pcie-5-0-adapter-nvidias-rtx-3090-ti-macht-den-anfang-exklusiv/
Was bedeutet das Ganze für die Grafikarten? Der Aufwand für die Buchsen und Stecker reduziert sich enorm, hier reicht in Zukunft ein einziger, standardisierter Stecker für alle Karten, solange sie einen zusätzlichen Versorgungsanschluss benötigen und eine Leistungsaufnahme von 600 Watt nicht überschreiten. Es wird das Platinenlayout und die mechanische Gestaltung deutlich vereinfachen und dieser Schritt ist auch seit Langem überfällig.

Zusätzlicher Aspekt: Man benötigt 1x Kabel für alles bis 600W. Weniger Kabelsalat im Gehäuse, weniger E-Schrott und Ressourcenverbrauch in Form von PCIe Kabeln. Ich finde den neuen Stecker top! Ja, mittelfristig müssen viele noch mit einem Adapterkabel hantieren (solange man sein Netzteil nicht ersetzt) und 600W sind jenseits von gut und böse. Ein Stecker für alles ist aber langfristig dennoch sinnvoll.

BlacKi

2022-06-27, 21:53:51

:rolleyes:
https://www.igorslab.de/wp-content/uploads/2021/03/Intro-3-1024x787.jpg
Bei 344W.
https://www.igorslab.de/powercolor-rx-6900xt-liquid-devil-im-test-gut-gekuehlt-ist-halb-gewonnen/4/klar custom, aber ich bezog das auf referenzmodelle. hat amd auch ne geschichte dazu.

Linmoum

2022-06-27, 22:14:37

Ja und gerade auch deswegen ist es Quatsch. Die 6700XT hat ja auch nicht nur 1x8-Pin bekommen.

Vielleicht macht Koduri das aber noch mal, diesmal mit Intel. Who knows.

BlacKi

2022-06-27, 23:09:42

sry, ich halte das für blödsinn. man spricht in verbindung mit dem kommenden mehrverbrauch den neuen kommenden neuen 600w stecker an, und bleibt dann bei 350-360w?

klar. macht einfach nur keinen sinn. ich sage, der neue stecker wird auch gebraucht werden und auf 3x8pin wollte man nicht setzen.

iamthebear

2022-06-28, 08:41:01

Die gesamte Folie ist doch schon kompletter Witz. Hat NV bei der Betrachtung vergessen, dass Ampere wesentlich mehr säuft? ;D Zudem verbraucht weder Turing 240W noch Ampere 320W. Selbst wenn ich die 240W als Bezugslinie nehme komme ich bei Ampere auf eine Effizienzsteigerung von 50%, und dann höchstwahrscheinlich im Bestcase (eventuell RT+DLSS). 60fps vs 90fps.

Der Vergleich war bei gleicher Performance. Damit kann man wunderbar manipulieren, da dann eine hoch getriebene 2080 Ti gegen eine runter getaktete 3080 antritt.

Eine GPU mit 210W stattet doch auch niemand mit nur 1x8-Pin aus. Ist halt Quatsch, sowas auf Kante genäht zu machen. Und den Stinkefinger zeigst du den Kunden damit auch, weil das effektiv OC unterbindet.

Wenn man sowieso schon übertaktet und die Hardware außerhalb der Spezifikationen betreibt warum nicht auch den 8 Pin Stecker. Der ist von allem die Komponente mit der größten Reserve. Nur übertreiben sollte man es nicht.

Ich habe vor Jahren aus Unwissenheit ein kleines Experiment gemacht:
Eine 300W Karte (GTX 295) mit 2x8 Pin, mit Adapter dann 4x6 Pin, mit noch mehr Adaptern dann 8x4 Pin. Und dann mit einer Menge Y Kabel (30 Cent Billigware) alles auf einen 4 Pin Anschluss zusammengeführt und den dann zu einer Festplatte dazu gehängt.

Das Ganze lief ganze 3 Jahre allerdings mit leicht angeschmortem 4 Pin Kabel.

Aus Brandschutzgründen muss ich von so Aktionen natürlich stark abraten aber nur weil man einmal 10W über der Spec ist muss man nicht gleich ganz aus dem Häuschen sein. Die Kabeln haben einiges an Reserve.

Linmoum

2022-06-28, 09:24:57

HOT

2022-06-28, 10:11:45

Man muss sich nur die 6x50-Serie anschauen, denn die ist der Testlauf für die N3x-Serie. Das sind halt im Backdrill-Verfahren hergestellte Platinen, die 18GT/s erlauben (wahrscheinlich auch 20) und ansonsten dürfte sich für N3x nur wenig ändern. Also werden wir wohl 3x PCIe 8 Pin sehen.

prinz_valium_2

2022-06-28, 14:04:24

Wenn ich daran denke, dass meine Karte einen 6 Pin hat^^^
Und die 1070 war damals keine lahme Krücke (ist sie ja immer noch nicht)

Für AMD wäre es das erste mal die Nutzung des 12Pin, oder?

iamthebear

2022-06-28, 14:21:27

Es gab zurecht damals für AMD den Shitstorm bei der 480 und da waren das auch nur ~10W drüber.

Kann man für Benchzwecke auch deutlich überfahren, mach ich auch in solchen Fällen. Für den Alltag aber Quatsch und die Hersteller sollten es auch nicht darauf anlegen.

Dass ein GPU Hersteller die Spezifikation nicht überschreiten darf sollte klar sein. Aber was OCer privat in Eigenverantwortung tun sollte klar sein.

BlacKi

2022-06-28, 15:14:18

Dass ein GPU Hersteller die Spezifikation nicht überschreiten darf sollte klar sein. Aber was OCer privat in Eigenverantwortung tun sollte klar sein.
das schlimme war ja, das der pcie slot überfahren wurde. und nicht zu knapp. 82w avg sind 16 zuviel, fast 25%. ohne OC:biggrin: mit torture tests sogar 19w avg drüber.

https://cdn.mos.cms.futurecdn.net/q26MsTqCAJDcVrLntGcApK-970-80.png

turricanm3 s 3090ti hat auch schon fehlermeldungen bekommen, wegen pcie slot überpower. mit OC.

nochmal zum mitschreiben, 12v dürfen über der pcie slot laut spec nur 66w und nicht 75. 75 gilt zusammengerechnet mit 3,3v.

HOT

2022-06-28, 15:40:42

Wenn ich daran denke, dass meine Karte einen 6 Pin hat^^^
Und die 1070 war damals keine lahme Krücke (ist sie ja immer noch nicht)

Für AMD wäre es das erste mal die Nutzung des 12Pin, oder?

Aber es sieht halt nicht so aus, als wenn man den Stecker nutzen würde. Wie gesagt, die 6x50er sind schon Platinen, die dazu fähig sein drüften, N3x zu befeuern. Da diese weiterhin PCIe2-Specs folgen, dürfte das bei N3x auch nicht anders sein. Ich würde sagen, dieses Generation ist NV mit dem neuen PCIe-Stecker konform aber hat kein PCIe5-Port und AMD dürfte noch die alten PCIe-Stecker konform sein und hat PCIe5 :freak:. Battlemage macht dann sicherlich beides ... (irgendwann 2024 ;D).

Gipsel

2022-06-28, 15:46:26

absolut richtig, für 375w bräuchte man nur 2x 8pin. deshalb gehe ich von mehr watt aus.
das schlimme war ja, das der pcie slot überfahren wurde. und nicht zu knapp. 82w avg sind 16 zuviel, fast 25%. ohne OC:biggrin: mit torture tests sogar 19w avg drüber.Und genau deswegen verbaut keiner nur 2x8pin bei einer 375W-Karte (schon bei 350W wird es zweifelhaft). Denn die 12V-Versorgung von PCIe-Slot + 2x 8Pin ist nur für 366W gut und die Balancierung der Lastverteilung über die Anschlüsse Aufwand, den kaum einer treiben will.
Man hat diesen tollen neuen Stromstecker, der weniger Platz benötigt und erstmal ermöglicht, daß man in der Spec quasi nichts (bzw. nur wenig) über PCIe ziehen muß. Warum den also nicht nutzen? Adapter kann man ja beilegen.

HOT

2022-06-28, 15:48:51

AMD hat schonmal bei einer 450W-Karte 2x 8-Pin verbaut, bei der 295X2 :D.
Aber nein, heute macht das keiner mehr. 2x 8 Pin wird man bis maximal 300W Limit sein und 3x 8 Pin bis 450W (mit Ausnahmen natürlich).

Gipsel

2022-06-28, 15:59:12

AMD hat schonmal bei einer 450W-Karte 2x 8-Pin verbaut, bei der 295X2 :D.
Aber nein, heute macht das keiner mehr. 2x 8 Pin wird man bis maximal 300W Limit sein335W hat AMD gerade noch kürzlich gemacht. Aber <40W über PCIe ist eben schon noch okay.

vinacis_vivids

2022-06-28, 16:15:38

Ich schätze das mal so ein:
Die 6950XT Sapphire Toxic Edition beansprucht 420W Leistungsaufnahme und verlangt mind. 850W NT.
Die 6950XT Power Color Liquid Devil hat 3x8Pin Stecker und verlangt 1000W NT.
3x8Pin ~ max. 450W
PCIe ~ max. 75W
Summe: ~max. 525W
Das ist weit weit weg vom optimalen Betriebspunkt und eben auf OC ausgerichtet.

In diesem Rahmen solle man N31 Referenz + OC auch einsortieren : ~ 525W.
Und da ne PCIe5 Option dran kommt, kann es bei 12Pin 450W oder 600W Stromversorgung für das Board sein. Ein Sparsamer N31 ~ max. 525W und ein Custom OC N31 ~ max. 675W
Mit diesem PowerBudged kann man die Taktraten dann auch sehr gut ausreizen (3,3Ghz?)

Bei 12288SP und 3,2-3,3Ghz sind 600-675W durchaus angemessen. Die 525W würden den Takt deutlich drücken auf 2,8-3,0Ghz und das kann schon etwas zu langsam sein gegen die Konkurrenz. Dazu kommt ja bei N31 noch das relativ breite 384bit SI und 24GB VRAM, die auch versorgt werden wollen. Da sind 600-675W dann doch sinnvoll um viele Bremsen zu lösen.

Klimawandel ist zwar gerade in Deutschland Modethema, aber der Rest der Welt ist da noch nicht ganz so weit, da wird ganz oben lieber doch zum Luxusmodell gegriffen wenn die Stromrechnung gezahlt ist.

Im unteren Sektor wie N33 wird AMD sicherlich eher sparsam rangehen, also 175-200W Referenz und 225-250W für Custom OC. Am Chip für die 80-95% Masse ändert sich also nichts. Die Top 5% werden durchaus auch Richtung BruteForce 675W gehen für N31.

HOT

2022-06-28, 16:17:35

335W hat AMD gerade noch kürzlich gemacht. Aber <40W über PCIe ist eben schon noch okay.
Jo das stimmt auch, hatte vergessen, dass AMD das Speichersubsystem über den PCIe befeuert. Das war nur bei HBM anders.
Das könnte bei RDNA3 auch so sein, wenn man sich auf 256Bit beschränkt. Bei NV ist das grundsätzlich anders, da die ganzen "Gedönsspannungen" bei Lovalace wegfallen, dürften die Lovelace 100% über den PCIe-Stecker laufen. Bei AMD wären also weiterhin bis maximal ca. 350W mit 2 Steckern möglich, da die verschiedenen Spannungen (auch 5V und 3,3V) auch bei RDNA3 noch genutzt werden könnten.

Nazar

2022-06-28, 16:18:33

und damit kann man auch ausrechnen das der Topdog maximal 100% schneller wird als N21

denn wie wir wissen wird AMD nicht auf 450 Watt hoch gehen, aber gehen wir einfach mal von 450watt aus. 50% durch effizienz und 50% durch höheren verbrauch (300 -> 450 watt) also wird N31 wohl eher bei 75-80% Mehrleistung raus kommen

Ich bin immer erstaunt, woher du dein "Wissen" hernimmst. :freak:
Mehrere Postings vorher zeigen sehr gut auf, dass wir im Grunde rein gar nichts wissen, außer das, was von den offiziellen Kanälen gestreut wurde.
Und da möchte ich auch gleich mit einem Zeichen für dich aufwarten, dass du eventuell vergessen hast zu deuten und welches oft genug auf den Folien zu sehen war:

>

Falls ich mich irre und du mehr "Wissen" als wir anderen hast, dann bitte immer her mit den Links. Belehre uns eines Besseren. ;)

Linmoum

2022-06-29, 00:29:01

WMMA-Instructions für RDNA3.

https://reviews.llvm.org/D128756

Ggf. als TC-Äquivalent?

Neurosphere

2022-06-29, 00:31:38

WMMA-Instructions für RDNA3.

https://reviews.llvm.org/D128756

Ggf. als TC-Äquivalent?

Habs auch grad auf Twitter entdeckt, warst schneller:biggrin:

Gefunden hats Kepler:
https://twitter.com/Kepler_L2/status/1541905092395388933

basix

2022-06-29, 01:01:00

Gott1337

2022-06-29, 02:38:43

Ich bin immer erstaunt, woher du dein "Wissen" hernimmst. :freak:
Mehrere Postings vorher zeigen sehr gut auf, dass wir im Grunde rein gar nichts wissen, außer das, was von den offiziellen Kanälen gestreut wurde.
Und da möchte ich auch gleich mit einem Zeichen für dich aufwarten, dass du eventuell vergessen hast zu deuten und welches oft genug auf den Folien zu sehen war:

>

Falls ich mich irre und du mehr "Wissen" als wir anderen hast, dann bitte immer her mit den Links. Belehre uns eines Besseren. ;)
Ich habe NUR Aussagen von AMD genommen, was quatscht du da für ein Bullshit? DAS HIER IST EIN SPEKULATIONS FORUM, verstehst wohl die Bedeutung davon nicht... traurig.

Gipsel

2022-06-29, 07:52:19

Wenn ich das richtig verstehe (bin da absoluter Laie), dann sind die hier gezeigten WMMA Instructions immer in der selben Shape, egal ob FP16 int INT4 als Input:
- bspw. f32.16x16x16.f16 --> Accumulator = FP32; Shape = m16n16k16; Input Multiplicands = FP16

Das würde zumindest auch zu dem passen, wass CDNA2 bietet: FP16 und INT8 mit dem selben Durchsatz, keine Verdopplung für INT8. RDNA3 allerdings noch mit zusätzlich INT4, aber ebenfalls ohne gesteigerten Durchsatz.Es sieht bisher danach aus, daß nur 16x16 Matrizen verarbeiten werden können. Die Werte z.B. für einen F32 Akkumulator stehen in 8 Vektorregistern (8x32 = 256 32bit-Werte), kleinere Operanden werden in weniger Vektorregister gepackt, belegen also weniger Registerbandbreite zur Ausführung. Dies läßt theoretisch noch die Option, daß der Durchsatz je nach Typ der Operanden unterschiedlich ausfällt.
Aber stimmt, es sieht vom Funktionsumfang/Flexibilität schon abgespeckt gegenüber nVs TCs (und auch AMDs eigenen Matrixcores in CDNA) aus.

Edit:
Nur 8bit und 4 bit Operanden nutzen weniger Registerspace (4 bzw. 2 Vektorregister, 16bit-Operanden belegen 8 Vektorregister, also 1kB wo gepackt 512 Einzelwerte [16x32 bzw. 32x16] reinpassen, genau wie 4 Vektorregister für 8Bit-Operanden und 2 Vektorregister für 4bit-Operanden). Da 16bit-Werte sicher auch gepackt sind, multipliziert man also vermutlich 16x32 mit 32x16 Matrizen (Ergebnis ist dann 16x16, genau wie der zu addierende Operand, wo man dann als i32 oder f32 ebenfalls mit 8 Vektorregistern auskommt).

Gipsel

2022-06-29, 11:20:00

Das Co-Issuing ist höchstwahrscheinlich kein generelles Feature. Sonst würde der damit verbundene Verweis auf das VOPD-Instruktionsencoding unsinnig sein. GCN/RDNA haben alle mehrere mögliche Klassen an Instruktionsencodings für die Vektoroperationen: VOP1, VOP2, VOP3 (mit VOP3a, VOP3b und später VOP3p [packed math] Untervarianten, VOPC und mit RDNA3 dann offenbar noch VOPD). VOP3 Befehle können (bis zu) 3 Quell- und 1 Zieloperanden nutzen, VOP2 haben 2 Quelloperanden VOP1 nur maximal einen, VOPC, sind Vergleiche (die Skalaroperationen haben auch mehrere mögliche Encodings, welche logischerweise alle mit SOP anfangen ;)). VOP3-Befehle sind 64Bit groß (und erlauben noch weitere Dinge wie input und output modifier [Negation, Clamping, Multiplikation mit 0.5, 2.0 oder 4.0 und so), die anderen nur 32bit (die meisten Befehle, der nur 2 Quelloperanden benutzen, können trotzdem das VOP3-Format nutzen, um an die input/ouput modifier zu kommen [sinnvoll, wenn damit ein zusätzlicher Befehl gespart wird]).

VOPD wird wahrscheinlich auch 64Bits messen und quasi 2 VOP2-Befehle aneinanderhängen (mit ein paar umdefinierten Bits). Eine gewisse Auswahl an Instruktionen wird so abgesetzt werden können, aber längst nicht alle.
Wer weiß, vielleicht spekuliert man ja bald wieder über bridged FMAs, wo über die VOPD-Befehle voneinander unabhängige Multiplikationen und Additionen gleichzeitig an die FMA-Einheit rausgehen können (also die "Brücke" zwischen Multiplikations- und Additionsteil auch getrennt werden kann). Wenn dann noch bestimmte andere Sachen halbwegs gleichmäßig zwischen den beiden Teilpipelines aufgeteilt werden (Vergleiche, Formatkonversionen, whatever; duplizieren wird man vermutlich eher nichts [vielleicht mit RDNA4?]), dann ergeben sich eventuell ausreichend viele mögliche Befehlskombinationen, mit denen dual issue sinnvoll nutzbar wird.
Der Charme ist, daß die Scheduler-Ressourcen nicht groß aufgebläht werden müssen, da die Abhängigkeiten nur pro VOPD-Befehlspaket geprüft werden. Dafür muß aber der Compiler sicherstellen, daß nur unabhängige Operationen in so ein VOPD-Befehl gepackt werden (ist bei zweien aber wohl noch überschaubar). Wäre zumindest meine Idee.
War wohl ein guter Tipp. VOPD packen quasi eine kleine Auswahl (es geht wohl erstmal nur mit 13 bzw. 16 verschiedenen Instruktionen, längst nicht Alle) zweier unabhängiger VOP2-Befehle in ein 64bit-Paket, wobei Restriktionen bezüglich der verwendeten Register (es gehen nur Kombinationen, wo es keine Kollisionen bei den Registerbänken gibt) gelten. Mit der Umsetzung eines letztens hier angeführten Patents (dual issue mit Operand/Registerfile Cache) könnte man diese Registerbankrestriktionen in Zukunft eventuell lockern.
Ach ja, FMACs (die VOP2-Version mit Zerstörung eines Quelloperanden) gehen als VOPD, die allgemeinen VOP3-FMAs erwartungsgemäß nicht. Integer und Packed math (also 16bit RPM) geht auch nicht (Korrektur: als einzige Ausnahme geht wohl v_dot2c_f32_f16 auch als VOPD).
Dot product of packed FP16 values, accumulate with destination.
D.f32 =
S0.f16[0] * S1.f16[0] +
S0.f16[1] * S1.f16[1] + D.f32.

Thunderburne

2022-06-29, 13:02:49

https://wccftech.com/amd-fsr-3-0-gfx11-rdna-3-gpus-hardware-acceleration-wmma-instructions/

Gipsel

2022-06-29, 13:08:26

https://wccftech.com/amd-fsr-3-0-gfx11-rdna-3-gpus-hardware-acceleration-wmma-instructions/Neue Erkenntnisse gibt es da nicht. Die käuen auch nur die Tweets wieder und reichern das mit ein paar Spekulationen an.

Neurosphere

2022-07-01, 09:52:06

But ad102 seems to be higher than expected, so it's likely that n31<ad102.

https://twitter.com/greymon55/status/1542553359340535808

And the AD102 has a very high upper limit in terms of specs and power consumption, so I'm worried that the gap between the 31 and 102 might be a bit wide.

https://twitter.com/greymon55/status/1542554641509916672

basix

2022-07-01, 09:52:17

WMMA anscheinend ohne dedizierte Einheiten, läuft über die Shader-ALUs:
https://forum.beyond3d.com/threads/amd-rdna-3-speculation-rumours-and-discussion.62092/page-69#post-2257037

robbitop

2022-07-01, 10:25:17

Dann wird der speedup sehr limitiert sein.

Gipsel

2022-07-01, 10:28:41

WMMA anscheinend ohne dedizierte Einheiten, läuft über die Shader-ALUs:
https://forum.beyond3d.com/threads/amd-rdna-3-speculation-rumours-and-discussion.62092/page-69#post-2257037
Während das sehr wohl stimmen könnte, gibt das dort angeführte Zitat aus RoCm das überhaupt nicht her, spricht es doch von "matrix core acceleration". Und wie wir alle wissen, sind die bei CDNA verbauten Matrix Cores ja schon dedizierte Einheiten.
Edit: Das Gefettete im Zitat im B3D-Forum ist eigentlich nur eine Kurzbeschreibung, wie GPUs allgemein funktionieren. Das hat keinerlei Aussagekraft, wie WMMA genau implementiert ist.

https://www.phoronix.com/scan.php?page=news_item&px=AMD-ROCm-5.2-Released

The new AMD rocWMMA library is a C++ library for accelerating mixed precision matrix multiplication and accumulation (MFMA) operations leveraging specialized GPU matrix cores. The AMD documentation goes on to sum up rocWMMA:
rocWMMA provides a C++ API to facilitate breaking down matrix multiply accumulate problems into fragments and using them in block-wise operations that are distributed in parallel across GPU wavefronts. The API is a header library of GPU device code, meaning matrix core acceleration may be compiled directly into your kernel device code. This can benefit from compiler optimization in the generation of kernel assembly and does not incur additional overhead costs of linking to external runtime libraries or having to launch separate kernels.

rocWMMA is released as a header library and includes test and sample projects to validate and illustrate example usages of the C++ API. GEMM matrix multiplication is used as primary validation given the heavy precedent for the library. However, the usage portfolio is growing significantly and demonstrates different ways rocWMMA may be consumed.
The ROCm 5.2 release notes only mention CnetOS/RHEL 7 and 8, SUSE Linux Enterprise Server 15 SP3/SP4, Ubuntu 18.04, and Ubuntu 20.04 as supported operating systems. Ubuntu 22.04 LTS is not officially support yet with the ROCm 5.2 release, unfortunately, nor is RHEL 9.0. Though as I wrote about a short time ago this morning, the 22.20 packaged driver is preparing RHEL 9.0 and Ubuntu 22.04 support so hopefully the next ROCm release will have proper support for these new enterprise Linux distributions.

The graphics cards listed as officially supported by ROCm 5.2 are GFX9, RDNA, and CDNA hardware.

basix

2022-07-01, 10:36:17

Das stimmt. Zumindest in diesem "Interview" mit Sam Naffziger hört es sich aber auch in etwa so an:
https://www.tomshardware.com/features/gpu-chiplet-era-interview-amd-sam-naffziger
We asked whether AMD would include some form of tensor core or matrix core in the architecture, similar to what both Nvidia and Intel are doing with their GPUs. He responded that the split between RDNA and CDNA means stuffing a bunch of specialized matrix cores into consumer graphics products really isn't necessary for the target market, plus the FP16 support that already exists in previous RDNA architectures should prove sufficient for inference-type workloads. We'll see if that proves correct going forward, but AMD seems content to leave the machine learning to its CDNA chips.

Wieso "Interview" in Anführungszeichen: Im ganzen Text ist nicht immer ganz klar, was der Naffziger selbst gesagt hat und was Eigeninterpretationen von Tom's Hardware sind. Das gilt bei Matrix Cores (der Naffziger will sicher nicht RDNA1/2 ohne Matrix Cores schlecht reden) wie auch der Aussagen zu Chiplet Architecture, was mit "Single IOD" + "Multiple Compute Chiplets" angeführt wird.

HOT

2022-07-04, 15:23:49

Hm, um mal auf diesen ominösen Großchip einzugehen, der 2x N32 werden soll, würde ich sagen, das könnte auch wie folgt gelaufen sein (ich spinn mal ein bisschen rum):

- N30 gab es wirklich, und zwar mit 40WGPs, wurde aber gecancelt, nicht effizient das Desgin.
- N31 wurde stattdessen mit 32WGPs aufgelegt
- AMD merkt, dass Ada doch viel stärker werden könnte als gedacht mit den 600W-Gerüchten und custom-N4
- AMD bekommt Panik und stellt noch einen weiteren RDNA3-Chip (N35?) auf, der ~ 48WGP hat (vielleicht in N4?)
- Release dieses neuen Chips dann vielleicht im April 23 oder so

Mal schauen :D. Ist halt ein Scenario, was höchstwahrscheinlich so nicht eintreten wird :D.

basix

2022-07-04, 15:52:23

Deine WGP Zahlen sind falsch ;) N31 ist momentan mit 48 WGP im Rennen.

Panik ist vielleicht übertrieben. Es macht immer Sinn, sich auf Eventualitäten vorzubereiten für den Fall der Fälle. Ein noch fetteres Design als 48 WGP ist sicher denkbar. z.B. eben 64 WGP. Aber wir wissen ja noch nichtmal, ob die 48 WGP wirklich stimmen, wie die Chiplet-Architektur aussieht usw.

N31 soll mit 7x Chiplets am Start sein. Verschiedene Aufbauten sind denkbar und wurden schon diskutiert, aber selbst die 7x Chiplets sind nur ein Gerücht:
1.) 3x MCD, 3x GCD, 1x IO
2.) 1x MCD / IO, 6x GCD
3.) 1x GCD / IO, 6x MCD

Eine späte Anpassung des Portfolios mit einer neuen Variante sehe ich eigentlich nur bei 2.) und 3.). Bei 1.) scheinen mir MCD & GCD zu stark verschränkt. Wobei ich hier 2.) deutlich im Vorteil sehe:
- Kein neues N5 Design nötig --> Nimm einfach 8x GCDs
- Grösseres MCD erlaubt mehr Infinity Cache --> Erhöhte effektive Bandbreite für die erhöhte Rohperformance

HOT

2022-07-04, 17:26:41

War ja auch nur als Denkanstoss gedacht ;). klar hast du recht, 48 war eh schon im Gespräch :D. Dann eben 64 WGPs.

Die 1 SE-GCDs waren ja meine Idee, aber davon bin ich wieder runter. MMn sind das dann 1 MCD + 3 GCDs (je 2 SE) + 3 "AI"CDs als MCM-Ausführung. Das muss man sich wie ein Reihenmotor vorstellen, die "AI"CDs auf der einen, die GCDs auf der anderen Seite des MCDs. Das Ganze kann man dann mit 2, 3 und 4 GCDs machen, das würde 3 MCD-Chips benötigen. Für N33 lohnt sich das nicht, das wäre dann ja quasi ein GCD, das kann man auch gleich monolithisch designen.

basix

2022-07-04, 20:24:09

MMn sind das dann 1 MCD + 3 GCDs (je 2 SE) + 3 "AI"CDs als MCM-Ausführung. Das muss man sich wie ein Reihenmotor vorstellen, die "AI"CDs auf der einen, die GCDs auf der anderen Seite des MCDs. Das Ganze kann man dann mit 2, 3 und 4 GCDs machen, das würde 3 MCD-Chips benötigen.

Auch eine Variante. Shuffling the Chiplets around :D Ich habe allerdings das Gefühl, dass es bei AMD eine Matrix Engine Light werden wird (weniger potent wie bei Turing/Ampere) und sich deswegen ein Auslagern auf ein separates Chiplet nicht wirklich lohnt.

Ich denke wir liegen eh alle falsch und sobald die GPU released wird: "Ah ja klar. Macht absolut Sinn das so umzusetzen. Wieso ist das uns nicht selbst in den Sinn gekommen?" ;)

Linmoum

2022-07-04, 22:16:32

Navi31 with 6 MCD x 64-bit is looking more and more likely
https://mobile.twitter.com/Kepler_L2/status/1544042779122204672

Grundlage ist wohl dieser Patch hier:
https://lists.freedesktop.org/archives/amd-gfx/2022-July/081027.html

Add umc ras functions for navi31:
1. Add driver and asic register for umc new ip.
2. Support query umc ras error counter.
3. Support ras umc ue error address remapping.
https://i.gyazo.com/6be4f0d4fa65bf0dcc2118c7a015f78a.png

Scheint RGT mit seinem 384-bit bus ja richtig zu liegen.

prinz_valium_2

2022-07-04, 22:19:30

64bit pro MCD, also insgesamt 384?

24GB Ram ist schon ein ganze Menge.
Aber hatte die 3090 ja auch ^^
Dafür dann normaler GDDR6 und kein super schneller und teuer GDDR6X nehme ich an?

basix

2022-07-04, 22:46:04

2x 16bit pro Channel, 2x 32bit Channels pro MCD, 6x MCDs --> 384bit --> passt

In einem späteren Tweet schreibt Kepler 32 MByte / MCD. Mal einer mit etwas zurückgestutzten IF$-Kapazitäten ;)

Linmoum

2022-07-04, 23:03:39

vinacis_vivids

2022-07-04, 23:47:40

N31:
12288SP (192CU=48WGP)
3,0-3,3Ghz GPU-CLK
24GB GDDR6
384bit SI
864GB/s
384MB IF$ ?
350-400W TDP

GDDR6 wird den Preis noch Human halten können.

Die Rechenleistung läge bei ~80 Tflop/s+ fp32 bzw. ~160 Tflop/s+ fp16.
Die Bandbreite läge bei 864GB/s nativ GDDR6 +
Die Bandbreite des IF$ 12-Channel Cache bei einem IF-CLK von ~2,5Ghz sind ~ 1,92TB Bandbreite.
Kumuliert wären das 2,784 TB/s Bandbreite für Navi31. Beim Synchronen 3,3Ghz IF-CLK wären das sogar 2,53 TB/s Bandbreite und kumuliert 3,394 TB/s

Im Vergleich zu N21 (~1986 GB/s) wäre das ein Plus von ~70% Bandbreite.
Mit 2,7 - 3,3 TB/s Bandbreite kann man schon mal etwas anfangen. :eek:
Der größere Cache erlaubt außerdem hoch eine deutlich höhere Hitrate bei 4K.

Selbst wenn N31 wirklich weniger Recheneinheiten haben sollte als AD102, bleiben AMD`s CUs deutlich besser und zusätzlich ist AMD bei der Bandbreite überlegen und es kommt somit zu einem Kopf-an-Kopf Rennen, wobei AMD mehr Leistung auf die Straße bringt.
Im Kern bleibt AMD deutlich günstiger in der Produktion und verbraucht auch wesentlich weniger Energie bei ähnlicher Leistung. Also hat AMD RDNA3 mit hoher Wahrscheinlichkeit eine klar bessere und deutlich effizientere Technologie als NV mit Ada trotz leicht günstigerer Fertigung.

Zusammenfassung für AMD:
Bessere CU`s
Bessere Taktraten
Effizientere Technik
Weniger Energieverbrauch
Günstigere Fertigung
Günstigerer Speicher

Prognose: Mit Brute-Force NV dürfte es langsam und stetig bergab gehen und mit AMD geht es weiter bergauf.

basix

2022-07-05, 00:14:25

384-bit bus, 20/24Gbps GDDR6, 192 MByte IF$. Letzteres wäre völlig ausreichend. Ich sehe wenig Grund dafür, wofür es die vormals kolportierten 256/384 MByte brauchen sollte. Das würde IMO nur unnötig Fläche kosten ohne wirklichen Nutzen.

Hätte ich auch gesagt. Gab letztens auch ein Statement von wegen "AMD did learn from RDNA2, more efficient use of IF$ (only caching stuff which benefits from caching)".

Rein von der Bandbreite her sollte 192MByte IF$ und 384bit @ 20Gbps für eine sehr hohe Performance reichen. Beispiel: RTX 3070 kommt mit 448 GByte/s aus. 192 MByte IF$ resultieren in >2.5x Bandbreitenmultiplikator bei 4K und N31 Speicherbandbreite beträgt 960 GByte/s. Ist N31 also gleich bandbreiteneffizient wie die RTX 3070, dann könnte er 2.5*2.1=5.3x schneller sein. Oder anders gesagt: >3x schneller als eine RTX 3090 oder 6900XT. Müsste also eigentlich reichen, zumindest für alles bis und mit 4K.

Edit:
Was allenfalls von noch mehr Bandbreite profitieren könnte wäre paralleler Betrieb von Shader-ALUs, Matrix Cores und RT-Cores.

unl34shed

2022-07-05, 10:01:40

32MB, 64b GDDR6 inkl controller und ein Interface zum GCD wären dann in etwa 40mm² oder?

basix

2022-07-05, 13:20:49

32MB, 64b GDDR6 inkl controller und ein Interface zum GCD wären dann in etwa 40mm² oder?

Kommt in etwa hin, ja.

BavarianRealist

2022-07-05, 13:48:20

Der 5nm-Prozess N5P von TSMC scheint recht performant zu sein: nicht nur Zen4 soll einen großen Takt-Sprung machen. Der Takt-Sprung von Nvidia von rund +50% wäre schon heftig!

Nachdem AMD angeblich seine 7nm-Wafer leicht reduziert haben soll - was mich wundert, braucht man den doch auch für die Konsolen-SoCs! - gehe ich davon aus, dass auch AMDs RDNA3 gewaltig zulegen dürften und AMD deshalb nun keine 7nm-Wafer mehr für die aktuellen RDNA2 einsetzen will, d.h. hierfür ab Q4 vielleicht sogar gar keine Wafer mehr verwendet?

Wenn beide GPUs nahe beieinander liegen und beide Angst haben, dass sie zu wenig verkaufen - Nvidia hat ja angeblich auch Wafer gestrichen - dann sollte es diesmal spannende Angebote geben, die dann auch dem PC-Markt (DIY und Gamer) helfen könnten.

DrFreaK666

2022-07-05, 14:02:25

...
Nachdem AMD angeblich seine 7nm-Wafer leicht reduziert haben soll - was mich wundert, braucht man den doch auch für die Konsolen-SoCs! ..

Die SoCs bestellen MS und Sony

BavarianRealist

2022-07-05, 14:11:11

Die SoCs bestellen MS und Sony

Das wusste ich nicht, danke! Dann hoffe ich, dass die nun deutlich mehr ordern bzw. die von AMD nicht verwendeten Wafer dafür verwendet werden.

HOT

2022-07-05, 15:51:48

https://www.computerbase.de/2022-07/amd-patentantrag-gpu-chiplet-auslastung/

Hochinteressant. Das ist dann wohl RDNA4. Jetzt wird absolut klar, dass ohne Stacking die Datenbandbreiten nicht ausreichen, um mehrere GCDs auf einem MCM zu betreiben, wie ich das schon vermutet hatte, AMD schreibt das ja selbst in seiner Patentschrift.
RDNA3 ist also nach wie vor monolithisch, es wird nur das, was auch ausgelagert werden kann, ausgelagert, wie genau, sehen wir dann; aber im Grunde ist das auch egal, weil sich RDNA3 sehr sicher wie eine monolithische GPU verhalten wird, wie bisher auch.
RDNA4 wird dann verschiedenartige Chiplets mit Spezialisierungen bekommen laut dieser Dokumentation, um die GPU-Leistung ohne Einschränkungen mit Chiplets zu gewährleisten. Das geht jedoch, so würde ich das folgern, nur mit einprechendem Chip-Stacking, weil sonst die Bandbreiten nicht ausreichen werden und die Verlustleistung zu hoch wird.

Weitergehend würde ich spekulieren, dass es auf einem Interposer oder einem entsprechendem Träger von TSMC 6nm-Base-Chiplets mit Cache und Mem-CTR geben drüfte, die mit entsprechenden WGP-Chiplets (N3e Custom?) bestapelt werden bei RDNA4. Außerdem dürfte der Träger dann ein recht hoch getaktetes High-Performance Command-Chiplet haben (mittig vielleicht in in N4X?) zusammen mit dem primären Geometriechiplet (in N4?). Viele hochwertige Spekus, die hier von basix und anderen betrieben wurden, dürften dann bei RDNA4 wirklich zutreffen mMn.

Relic

2022-07-05, 16:21:24

https://www.computerbase.de/2022-07/amd-patentantrag-gpu-chiplet-auslastung/

Hochinteressant. Das ist dann RDNA4. Jetzt wird absolut klar, dass ohne Stacking die Datenbandbreiten nicht ausreichen, um mehrere GCDs zu betreiben, wie ich das schon vermutet hatte, AMD schreibt das ja selbst in seiner Patentschrift.
RDNA3 ist also nach wie vor monolithisch, es wird nur das, was auch ausgelagert werden kann, ausgelagert, wie genau, sehen wir dann; aber im Grunde ist das auch egal, weil sich RDNA3 sehr sicher wie eine monolithische GPU verhalten wird, wie bisher auch.
RDNA4 wird dann verschiedenartige Chiplets mit Spezialisierungen bekommen laut dieser Dokumentation, um die GPU-Leistung ohne Einschränkungen mit Chiplets zu gewährleisten. Das geht jedoch, so würde ich das folgern, nur mit einprechendem Chip-Stacking, weil sonst die Bandbreiten nicht ausreichen werden und die Verlustleistung zu hoch wird.

Auch nur ein leicht weiterentwickeltes https://de.wikipedia.org/wiki/Split_Frame_Rendering
oder?

HOT

2022-07-05, 16:40:04

Relic

2022-07-05, 16:55:43

Nein, das ist eher ein 2 stufiger TBR. Das funktioniert wie eine monolithische GPU, allerdings spart man eben soviel Datenverkehr wie möglich ein und versucht die WGPs möglichst effizient zu füttern.

Naja nur nach außen monolithisch, aber das waren ja die 2 Karten bei SLI/CF auch. Bei SFR wurde das Bild halt nur in 2 Tiles aufgeteilt. Jetzt schaut man sich vorher die Geometrie an um genauer bestimmen zu können, wo man wieviel Rechenleistung braucht und benutzt mehrere Tiles um besser auslasten und ggf. auch mehrere Chiplets auslasten zu können.
Aber hast schon recht kommt vom Ablauf recht nah ran an das, was IMG macht.

robbitop

2022-07-05, 16:58:55

Wäre interessant zu wissen, wie Apple es gemacht hat. Im M1 Ultra wurden 2x GPUs ohne Stacking verbunden (2,5 TB/s sind jetzt auch nicht gerade wenig).
Die Frage ist, ob sie dafür ein ähnliches Sortierungsverfahren brauchen und ob/wie es ihnen bereits half, dass es sich bei den GPUs um TBDRs handelt.

HOT

2022-07-05, 20:45:12

Naja nur nach außen monolithisch, aber das waren ja die 2 Karten bei SLI/CF auch. Bei SFR wurde das Bild halt nur in 2 Tiles aufgeteilt. Jetzt schaut man sich vorher die Geometrie an um genauer bestimmen zu können, wo man wieviel Rechenleistung braucht und benutzt mehrere Tiles um besser auslasten und ggf. auch mehrere Chiplets auslasten zu können.
Aber hast schon recht kommt vom Ablauf recht nah ran an das, was IMG macht.
SFR ist das völlig anderes, hat hiermit nix zu tun.

GrimReaper85

2022-07-05, 22:30:11

Ich konnte nicht mehr warten, kaufte RX 6800 für 630€. Vielleicht werde ich es durch Navi 33 ersetzen, wenn sie ein 16GB herstellen, aber das ist fast unmöglich. Und N32 ist mir egal, ~350W werden zu viel sein.

GrimReaper85

2022-07-06, 10:28:46

Wie groß ist die Wahrscheinlichkeit, dass Navi 33 16GB bekommt? In den neuesten Nachrichten vom 5. Juli wird 8/16 GB erwähnt. Das wäre eine perfekte Karte, 6900 XT Leistung bei 220W.

HOT

2022-07-06, 10:32:14

Berniyh

2022-07-06, 10:32:18

GrimReaper85

2022-07-06, 10:53:56

8 ist absolut ausgeschlossen, das würde sich bei der angepeilten Preislange um die 500€ schlichtweg nicht verkaufen. Das ging bei Ampere noch grade so, aber das ist 1 1/2 Jahre her. Außerdem wäre das ein Rückschritt: 6700XT 12GB zu 7700XT 8GB - das wird nicht passieren.
Aber 128-Bit ist bereits eine kostensparende Maßnahme. Es wäre seltsam, ihm dann 16 GB zu geben und diese Ersparnis zunichte zu machen.

Vielleicht nennen sie es sogar 7600 XT, dann gibt es keine Probleme mit 8 GB und PCIe x8, da 6600 XT dasselbe ist.

BlacKi

2022-07-06, 10:54:41

Wie groß ist die Wahrscheinlichkeit, dass Navi 33 16GB bekommt? In den neuesten Nachrichten vom 5. Juli wird 8/16 GB erwähnt. Das wäre eine perfekte Karte, 6900 XT Leistung bei 220W.
wenn der chip eine neue preisklasse erhält...

wenn nicht, warum sollten sie. schau mal, warum sollten sie eine doppelbelegung machen, weil 128bit speicherinterface, wenn sie sogar am pcie interface sparen und von 16x auf 8x runtergehen?

edit: zu spät.

HOT

2022-07-06, 11:31:18

Dann aber nur, wenn das Ding als FHD-Karte verkauft wird mit 32 oder maximal 64MB IF$. Ansonsten ergibt die Argumentation 0 Sinn. Wenn der annährend bei der 4070 rauskommt ist das ne WQHD-Karte, damit ist 8GB schichtweg ausgeschlossen. Dann gibts halt 16 mit Doppelbestückung und fertig. Ihr tut immer so, als wenn das wer weiss wie schlimm ist, das ist es nicht.

BlacKi

2022-07-06, 11:58:31

das problem ist nicht die karte alleine. was ist mit n32? 24gb? oder doch 12?

das ist auch marketingtechnisch schwierig zu lösen.

entweder man bleibt bei 350-400€ dann wirds auch nur 8gb geben. mit eine uvp deutlich darüber geht das durchaus, dann muss man aber schauen wie das zu nvidia passt.

wenn nv fast zu selben uvp zwar nur 10gb anbieten, aber schneller sind, dann mag das für einzelne hier nicht schwierig zu entscheiden sein, aber die masse da draussen nimmt die 10gb karte wenn sie schneller ist.

mboeller

2022-07-06, 12:13:15

das problem ist nicht die karte alleine. was ist mit n32? 24gb? oder doch 12?

N32 ist 256bit, zumindest nach den letzten Gerüchten. Also 16GB

N33 ist natürlich eine 8GB-Karte, zumindest in Notebooks und für die OEM's. Bei Retail-Karten sehe ich aber schon eine Chance für einige 16GB-Versionen der verschiedenen Hersteller. Wahrscheinlich aber nicht gleich zu Beginn bzw. bei der Vorstellung.

BlacKi

2022-07-06, 12:17:12

ah, stimmt, sry.

HOT

2022-07-06, 13:00:47

Bisheriger Stand:

N31 -> 384Bit, 24GB
N32 -> 256Bit, 16GB (UHD)
N33 -> 128Bit, 16GB (WQHD)
N22S -> 192Bit, 12GB (FHD)
N23S -> 128Bit, 8GB

why_me

2022-07-06, 13:05:07

Vielleicht sehen wir ja auch endlich mal die 1,5GB chips, die seit Jahren immer wieder genannt, aber nie verbaut wurden.

basix

2022-07-06, 13:25:24

Zu den Infinity Cache Grössen:
Eigentlich kann man AMD und Nvidia miteinander vergleichen. AD102 kommt mit 96 MByte L2$ daher. N31 mit 192-384 MByte. Durch den grösseren Cache hat AMD einen zusätzlichen Bandbreitenmultiplikator von 1.41...2.0x (wenn beide Implementationen da gleich arbeiten). Nvidia soll mit 21Gbps GDDR6X daherkommen. AMD wird vermutlich etwas zwischen 16...20Gbps verbauen. Nvidias Speicher ist also 1.05...1.31x schneller. Da sieht es also so aus, dass 192 MByte eigentlich ausreichen sollten, um auf Niveau des schnellsten AD102 zu landen (wiederum Annahme, dass RDNA3 und Lovelace eine ähnliche Bandbreiteneffizienz mitbringen).

Vielleicht sehen wir ja auch endlich mal die 1,5GB chips, die seit Jahren immer wieder genannt, aber nie verbaut wurden.
*Daumendrück* ;) Oder sowas wie mixed Assembly (2x 2 GByte, 2x 4 GByte) und entsprechender Ausgleich via Infinity Cache. Mir ist aber nicht bekannt, dass es 4 GByte GDDR6 Bausteine gibt.

Optimales Lineup:
N33 = 12GB
N32 = 16GB
N31 = 20-24GB

Weniger geil:
N33 = 8GB

Gipsel

2022-07-06, 15:55:05

Vielleicht sehen wir ja auch endlich mal die 1,5GB chips, die seit Jahren immer wieder genannt, aber nie verbaut wurden.Gibt wohl DDR5-RAM-Riegel mit 24Gbit, also 3GB pro Chip (https://www.tweakpc.de/news/48343/sk-hynix-neue-ddr5-ram-mit-bis-zu-96-gb-pro-modul/), aber breit verfügbar sieht anders aus. Bin auch gerade nicht sicher, ob diese krummen Größen nicht aus der GDDR6-Spezifikation rausgeworfen wurden. Aber prinzipiell wäre sowas schon wünschenswert, weil es mehr Flexibilität bei den Speichergrößen ermöglicht, ohne das Interface anzufassen.

prinz_valium_2

2022-07-06, 21:16:46

Blöde Frage: wenn man eh schon mit Interposern arbeitet, warum dann noch GDDR6?
War bei HBM nicht vor allem der Interposer immer das teure?
Mit HBM wäre man ja auch viel flexibler in der Speicherbestückung und könnte so die Varianten besser abgrenzen?

Nicht nut der Interposer, auch das packaging und das zusammenbauen.
Das wird bei einem multi chip die dann schon komplizierter. Vllt muss der ganze Interposer dann wieder deutlich größer und es gibt mehr Prozessschritte.

Da ist GDDR6 dann immer noch günstiger.
Ich denke das dauert noch eine lange Zeit, bis sich das ändert

*Daumendrück* ;) Oder sowas wie mixed Assembly (2x 2 GByte, 2x 4 GByte) und entsprechender Ausgleich via Infinity Cache. Mir ist aber nicht bekannt, dass es 4 GByte GDDR6 Bausteine gibt.

Optimales Lineup:
N33 = 12GB
N32 = 16GB
N31 = 20-24GB

Weniger geil:
N33 = 8GB

Aber du kannst doch 1GB und 2GB mixen, wie es die Series X auch schon gemacht hat.
Dann ist das Interface natürlich sehr groß. Ka, ob das Sinvoll wäre. Halte auch die Kosteneinsparung nicht für enorm.
Eigentlich möchte man so wenig wie möglich dies

HOT

2022-07-06, 21:19:53

Bisher sind nirgendwo auch nur im Ansatz 24 oder 32Gb GDDR6-Chips zu sehen. Ich verweise dieses Mal ins Reich der Wunschträume. Vielleicht Ende 23 oder gar 24. Bisher sind alle Chips, die von Samsung und Micron mit 20 und 24 GT/s gezeigt wurden 16Gb, auch SKHynix 27GT/s sind 16Gb.
Die kommen ganz normal im Clamshell-Mode und fertig. Das ist 0 Problem.

Ich kann einfach nicht verstehen, was das Gelaber soll. Wenn N33 keinen IF$ hätte, würde er ganz normal mit 256Bit-Inferface erscheinen, wie sine Vorgänger auch (von Pitcairn bis N10), der hätte genauso die 16GB, aber niemand würde sich darüber beschweren. AMD kann das Speicherinterface einsparen, aber nicht die Speichermenge.

prinz_valium_2

2022-07-06, 21:34:30

Wie ist das denn im Clamshell Modus, wenn du 1GB und 2GB verbaust?
Ist es dann trotzdem die volle Bandbreite für den gesamten Pool und nicht wie bei der Series X, wo nur 10GB die volle Leistung haben?

Für mich ist das dann wie ein 3GB chip an einem 64bit interface. anstatt 2*2 aka 4GB
Aber da habe ich jetzt nicht die Expertise um das genau sagen zu können.

Gipsel

2022-07-06, 21:54:49

Wie ist das denn im Clamshell Modus, wenn du 1GB und 2GB verbaust?Dann kannst Du nur 1GB pro Chip nutzen und die zweite Hälfte des 2GB-Chips nicht adressieren. Das verhält sich dann, als wenn Du 2x 1GB verlötest. Hilft also nicht.

basix

2022-07-06, 22:14:35

prinz_valium_2

2022-07-06, 22:26:55

Dann kannst Du nur 1GB pro Chip nutzen und die zweite Hälfte des 2GB-Chips nicht adressieren. Das verhält sich dann, als wenn Du 2x 1GB verlötest. Hilft also nicht.

Achso. Also wird bei Clamshell quasi parallel und Gleichzeitig adressiert und das funktioniert dann nicht mehr?
Schade. Aber ergibt wohl Sinn. Sonst hätte man solche Lösungen bestimmt schon lange gesehen.

Berniyh

2022-07-06, 22:45:15

Da ist GDDR6 dann immer noch günstiger.
Das ist doch jetzt auch nur eine Mutmaßung von dir, oder hast du da Zahlen?

prinz_valium_2

2022-07-06, 23:15:05

Das ist doch jetzt auch nur eine Mutmaßung von dir, oder hast du da Zahlen?

And GDDR6 Preise zu kommen ist einfach. DRAM exchange, oder bei Händlern in China, die das an kleine Abnehmer weiterverkaufen. Bei HBM sieht es anders aus. Da kann ich dir die Preise echt nicht realistisch sagen.
Aber ich weiß nicht, wie HBM irgendwie konkurrenzfähig sein könnte.
Dann würde es jeder nutzen.

OgrEGT

2022-07-07, 06:09:51

Was man machen könnte: Bei 2x 32bit jeweils 2GByte verbauen und bei den restlichen 2x 32bit auf Clamshell gehen, mit dann 2x2GByte pro Channel. Das sollte funktionieren. Wäre dann total 12 GByte an 128bit. Und inkl. all den Grausamkeiten bezüglich Speichermenge vs. Bandbreite, welche dann asymmetrisch wird.

Aber man hat es hier schon angetönt: Der Infinity Cache könnte evtl. helfen, um diese Asymmetrie zu verstecken. Mit entsprechendem Streaming und Prefetching.
Warum sollte man bei den unüberschaubaren Komplikationen einen derart zusätzlichen Aufwand betreiben? Nur um zwanghaft weniger VRAM als die 16GB der N32 zu realisieren? Dann doch lieber bei 8 oder 16GB bleiben sofern es die 1.5GB Chips nicht gibt für 12GB...

HOT

2022-07-07, 08:33:59

Was man machen könnte: Bei 2x 32bit jeweils 2GByte verbauen und bei den restlichen 2x 32bit auf Clamshell gehen, mit dann 2x2GByte pro Channel. Das sollte funktionieren. Wäre dann total 12 GByte an 128bit. Und inkl. all den Grausamkeiten bezüglich Speichermenge vs. Bandbreite, welche dann asymmetrisch wird.

Aber man hat es hier schon angetönt: Der Infinity Cache könnte evtl. helfen, um diese Asymmetrie zu verstecken. Mit entsprechendem Streaming und Prefetching.

Die werden so einen bescheuerten Stunt wegen 2 (!!) Speichermodulen wohl kaum machen.

Warum sollte man bei den unüberschaubaren Komplikationen einen derart zusätzlichen Aufwand betreiben? Nur um zwanghaft weniger VRAM als die 16GB der N32 zu realisieren? Dann doch lieber bei 8 oder 16GB bleiben sofern es die 1.5GB Chips nicht gibt für 12GB...

16GB ist genauso problemlos wie 8GB. Und 8GB ist zuwenig für WQHD, punkt.

basix

2022-07-07, 08:45:05

Warum sollte man bei den unüberschaubaren Komplikationen einen derart zusätzlichen Aufwand betreiben? Nur um zwanghaft weniger VRAM als die 16GB der N32 zu realisieren? Dann doch lieber bei 8 oder 16GB bleiben sofern es die 1.5GB Chips nicht gibt für 12GB...

Am besten um 12 GByte zu erreichen wären 4x 3 GByte Chips. Weitere Möglichkeit: N33 kommt auf dem Desktop mit nur 96bit und dafür sehr hoch taktendem GDDR6 (3*32bit mit 2x 2GByte im Clamshell Modus). Samsung sampled bereits 24Gbps GDDR6.

Und wieso wir überhaupt über das diskutieren?
- 8 GByte? Eindeutig zu wenig für dieses Performance Segment. Bereits die 3070 war da grenzwertig, inkl. Nvidias besserem Speichermanagement
- 12 GByte? Sweet Spot für 1440p, auch mittel- bis langfristig
- 16 GB? Ja gerne, nehmen wir alle nur zu gern. Problem: Speicher ist teuer (vor allem heutzutage). Weg des geringsten Widerstands für Kostenreduktion? 8 GByte, was wie oben beschrieben einfach zu wenig ist

Nun, wenn AMD ihr Speichermanagement deutlich verbessert, mittels Gehirnschmalz, dann kann ich auch mit 8GByte leben. Mir ist prinzipiell egal, ob 4, 8, 12 oder 16 GByte da drauf sind. Weniger würde ich grundsätzlich sogar begrüssen, da die Karten damit günstiger werden können. Nur will ich keine Karte, welche bereits absehbar mit einer Sollbruchstelle daherkommt. Also, was gäbe es da im Gehirnschmalz-Katalog?
- Zusätzliche Kompression
- Intelligenteres Streaming / Speicher-Management (siehe teilweise Nvidia)
- HBCC - High Bandwidth Cache Controller

Es gibt also viele Möglichkeiten, die N33 Karten gut werden zu lassen. 8GByte ohne weitere Massnahmen ist aber definitiv keine davon.

Die werden so einen bescheuerten Stunt wegen 2 (!!) Speichermodulen wohl kaum machen.
Ich hoffe es auch nicht. Wie oben gesagt: 96bit mit hoch taktendem GDDR6 im Clamshell Modus ist vermutlich einfacher und das Resultat ist das selbe. 96bit @ 24Gbps = 128bit @ 18Gbps. Bandbreite ist die selbe. Und 128bit vs. 192bit sparte etwas an Chipfläche (~15-20mm2). Mobile wird dann 128bit und 8/16 GByte mit langsamerem Speicher verbaut. Wenn N33 der Top End Mobil Chip wird, sind es dann eher 16 GByte (N22, N23 darunter mit 12/8 GByte). N31 und N32 dann Desktop only. Dann kommt man im Desktop wie auch Mobile Portfolio auch nicht mit N32 und 16 GByte "in die Quere".

Berniyh

2022-07-07, 09:15:39

And GDDR6 Preise zu kommen ist einfach. DRAM exchange, oder bei Händlern in China, die das an kleine Abnehmer weiterverkaufen. Bei HBM sieht es anders aus. Da kann ich dir die Preise echt nicht realistisch sagen.
Aber ich weiß nicht, wie HBM irgendwie konkurrenzfähig sein könnte.
Dann würde es jeder nutzen.
Naja, normalerweise muss man halt noch einiges anderes drauf rechnen, nicht nur die HBM Preise.

Hatte mich das eben nur gefragt, denn zumindest früher wurde der Interposer immer als der wesentlichste Stolperstein bezeichnet.

HOT

2022-07-07, 09:28:55

[...]Und 128bit vs. 192bit sparte etwas an Chipfläche (~15-20mm2). Mobile wird dann 128bit und 8/16 GByte mit langsamerem Speicher verbaut. Wenn N33 der Top End Mobil Chip wird, sind es dann eher 16 GByte (N22, N23 darunter mit 12/8 GByte). N31 und N32 dann Desktop only. Dann kommt man im Desktop wie auch Mobile Portfolio auch nicht mit N32 und 16 GByte "in die Quere".

Das kommt sich nix in die Quere.

basix

2022-07-07, 09:32:31

Naja, normalerweise muss man halt noch einiges anderes drauf rechnen, nicht nur die HBM Preise.

Hatte mich das eben nur gefragt, denn zumindest früher wurde der Interposer immer als der wesentlichste Stolperstein bezeichnet.

Der Interposer selbst ist relativ günstig, sind je nach Grösse nur 10-20$. Da sind ja nicht viele Prozessschritte involviert und irgendwas von 40-90nm der Standard. Das Packaging kommt aber noch oben drauf.

Und meines Wissens ist schon der HBM selbst das teuere in der Gesamtkostenrechnung.

Linmoum

2022-07-07, 09:41:17

Noch ein aktuelles Interview mit Naffziger:

There are various games that can be played. A dual GPU can be operating at a more efficient point, delivering more performance-per-watt. Whether that’s beneficial to the average gaming experience is another question. That’s difficult to coordinate. But it is a matter of focus. We certainly were – not short-changing Nvidia’s contributions, because they do have very power-efficient designs, and have had that. We were behind for a number of years. We made a strategic plan to never fall behind again on performance-per-watt.
The other thing we rolled out at our financial analyst day that we’re looking forward to delivering later this year is the RDNA 3. We’re not going to let our momentum slow at all in the efficiency gains. We publicly went out with a commitment to another 50% performance-per-watt improvement. That’s three generations of compounded efficiency gains there, 1.5 or more. We’re not talking about all the details of how we’re going to do it, but one component is leveraging our chiplet expertise to unlock the full capabilities of the silicon we can purchase. It’s going to be fun as we get more of that detail out.
https://venturebeat.com/2022/07/06/amd-addressing-the-challenge-of-energy-efficient-computing/

Und allgemein auch noch ein wenig was zum Thema Effizienz.

GrimReaper85

2022-07-07, 15:47:08

Wenn 7700 XT 16GB bekommt, werden sie sich wie warme Semmeln verkaufen, lesen Sie - Preis 800€, wenn 8GB 500€ sind. Ich würde es trotzdem kaufen, perfekter Ersatz für RX 6800.

Wenn wir noch 2-3 Jahre auf die perfekte Karte warten müssen, dann sei's drum. Vielleicht machen sie sogar einen abgespeckten N32 mit nur 250-300W.

prinz_valium_2

2022-07-07, 22:40:52

800€ für eine 7700 XT
Ne danke

Cyberfries

2022-07-08, 15:56:14

Da die 7700xt auf N32 basieren soll, sind 16gb und 800€ gar nicht so abwegig.
Die spekulierten Taktraten wandern jedenfalls in immer neue Höhen, mittlerweile sollen es über 3,3 GHz (https://nitter.net/Kepler_L2/status/1544157582742458369#m), wenn nicht gar 3,5 GHz (https://nitter.net/greymon55/status/1545050447995899904#m) sein.
Bei angeblich ca. 300w (https://nitter.net/Kepler_L2/status/1544078996903698435#m) und einer Leistung in der Nähe von nVidias 4080 könnte das ein tolles Gesamtpaket sein.

Bei einem ungefähren Gleichstand von N31 und der 4090 bei TDP und Leistung scheint nVidia
sich mit einem zu kleinen AD103 ziemlich verzockt zu haben, wenn eine derartige Brechstange ausgepackt werden muss.

iamthebear

2022-07-10, 18:08:13

Die 4090 kommt mit 128SM@2.75GHz
Die 4080 wird vermutlich in etwa bei 80SM@3.15GHz liegen wenn die Taktpunkte von AGF stimmen.

Das bedeutet die 4090 ist 1.4x vor der 4080.

AMD wird Navi32 aber kaum so hoch pushen.
Beispiel: Navi31 375W 3GHz
Navi32 300W 3.2GHz

Dann werden hier auch in etwa 1.4x dazwischen liegen

Falls Navi31 jedoch mit Full AD102 mit 144SM@800W konkurriert, dann dürfte es für die 4080 tatsächlich etwas schwierig werden aber das ist nichts was sich nicht durch den Preis fixen lassen würde. Dann muss Nvidia halt 10% mit dem Preis runter gehen oder AMD geht 10% rauf.

nordic_pegasus

2022-07-10, 18:22:07

prinz_valium_2

2022-07-10, 18:45:44

7800 und 7700XT könnten interessante Karten werden

OgrEGT

2022-07-10, 19:25:05

laut https://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/News/RTX-4000-und-RX-7000-Leaker-mit-neuer-Specs-Tabelle-1398911/

bzw.
https://twitter.com/Kepler_L2/status/1545605190685966336

soll der Navi31 Vollausbau 384MB IF-Cache haben und 7970XT3D heissen... also stacked Cache? Diese Behauptung kannte ich bislang noch nicht.

Da es wohl 6 MCDs a 32Mb IF sein sollen... macht es da Sinn auf jeden nochmal 32Mb drauf zu stacken? Eigentlich nur wenn die Ausbeute nahe 100% ist... sonst besser 64Mb MCDs nutzen?

Ansonsten wenn N31 bei 350W bei ca 2x 6900XT liegen könnte dann wird es spannend sein zu sehen wie die Skalierung darüberhinaus bis 450W sein wird...

reaperrr

2022-07-10, 23:13:24

laut https://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/News/RTX-4000-und-RX-7000-Leaker-mit-neuer-Specs-Tabelle-1398911/

bzw.
https://twitter.com/Kepler_L2/status/1545605190685966336

soll der Navi31 Vollausbau 384MB IF-Cache haben und 7970XT3D heissen... also stacked Cache? Diese Behauptung kannte ich bislang noch nicht.

Das wird schon länger anhand von Linux Treiber Patches, Patenten und mehreren Leakern so erwartet, dass der InfinityCache in 6nm gefertigt wird, und in mehreren Slices so auf den 6nm-IO-Die und 5nm-Compute-Die gepackt wird, dass er diese verbindet und die Kommunikation zwischen denen über den IF$ läuft.

Aber was den Namen angeht, Zitat:
My best guess at the next-gen lineups.
Also nur Speku von ihm und damit in Hinblick auf die Graka-Namen nicht viel mehr wert als das, was wir hier fabrizieren :wink:

iamthebear

2022-07-11, 00:32:21

Da es wohl 6 MCDs a 32Mb IF sein sollen... macht es da Sinn auf jeden nochmal 32Mb drauf zu stacken? Eigentlich nur wenn die Ausbeute nahe 100% ist... sonst besser 64Mb MCDs nutzen?

Woher kommt denn die Information mit den 32MB?
Meines Wissens nach wurden Varianten mit 32MB und 64MB getestet aber wir wissen nicht wofür sich AMD schlussendlich entschieden hat.

Bei 192MB habe ich ehrlich gesagt Bedenken, dass die Hitrate unter 8K oder 4K mit höheren Details kräftig einbrechen könnten.
Auf der anderen Seite: 384MB wären schon um die 150-200mm² nur für den Cache. Auf der anderen Seite: Wenn es nur 192MB sind: Sind dann 6 MCDs nicht etwas zu viel?

OgrEGT

2022-07-11, 06:39:28

Woher kommt denn die Information mit den 32MB?
Meines Wissens nach wurden Varianten mit 32MB und 64MB getestet aber wir wissen nicht wofür sich AMD schlussendlich entschieden hat.

Bei 192MB habe ich ehrlich gesagt Bedenken, dass die Hitrate unter 8K oder 4K mit höheren Details kräftig einbrechen könnten.
Auf der anderen Seite: 384MB wären schon um die 150-200mm² nur für den Cache. Auf der anderen Seite: Wenn es nur 192MB sind: Sind dann 6 MCDs nicht etwas zu viel?

Ich hatte mich auf den gerade zitierten Leak bezogen... demnach wären es 32MB/ 32MB+32MB MCDs... wenn du dir die kummulierte Rumor Spec Tabelle auf VC anschaust geht man da von 64MB MCDs aus... also entweder die Yields dür das 32MB+32MB sind so gut dann könnte man mit nur einem MCD inkl Stacking Option alle möglichen SI und IF Varianten abdecken oder es existieren zusätzlich 64MB MCDs... was am Ende stimmt wir werden es sehen...

unl34shed

2022-07-11, 18:20:34

Nach aktuellem Stand sind die MCDs (Memory Complex Die) Inifity cache plus Memory Controller und die sollten wohl nur etwa 40mm² klein sein und daher schon eine recht gute Yield besitzen (sollten die Spekulationen stimmen).
GCD ist Graphics Complex Die, also die ganzen CUs etc.

basix

2022-07-11, 18:43:13

Nach aktuellem Stand sind die MCDs (Memory Complex Die) Infinity Cache plus Memory Controller und die sollten wohl nur etwa 40mm² klein sein und daher schon eine recht gute Yield besitzen (sollten die Spekulationen stimmen).
GCD ist Graphics Complex Die, also die ganzen CUs etc.

Die momentan wahrscheinlichste Lösung für RDNA3, ja. GCD = "monolithisch"

Ich hatte mich auf den gerade zitierten Leak bezogen... demnach wären es 32MB/ 32MB+32MB MCDs... wenn du dir die kummulierte Rumor Spec Tabelle auf VC anschaust geht man da von 64MB GCDs aus... also entweder die Yields dür das 32MB+32MB sind so gut dann könnte man mit nur einem GCD inkl Stacking Option alle möglichen SI und IF Varianten abdecken oder es existieren zusätzlich 64MB GCDs... was am Ende stimmt wir werden es sehen...

Ich kann mir kaum vorstellen, dass das MCD in dieser Form 3D-Stacked ist. Und dann nur für eine der Chiplet SKUs? Ich halte das für dummes Geschwätz. Wieso diese zusätzliche Komplexität? Es lohnt sich einfach nicht.
- 64bit + 32MB = ~40mm2
- 64bit + 32MB + 32MByte V-Cache = ~40mm2 + ~20mm2 + 3D-SoIC Packaging
- 64bit + 64MB = ~60mm2

Ein "monolithisches" MCD wird einfach günstiger sein. Vor allem, da Cache aufgrund von Redundanzen faktisch 100% Yield hat. Entweder kommen alle Chiplet GPUs mit 32MByte oder 64MByte pro MCD. 3D-V-Cache Stacking wird nicht kommen und ein Mix davon schon gar nicht. Mit RDNA4 kann sich das wieder ändern (Re-Use der selben MCDs aber dann mit verdoppeltem IF-Cache für die höhere GPU-Performance) aber bei RDNA3 halte ich das für ausgeschlossen. Und selbst bei RDNA4 empfinde ich es als Unsinn, da wie gesagt ein etwas grösseres "monolitisches" MCD günstiger sein wird.

OgrEGT

2022-07-11, 18:44:06

iamthebear

2022-07-13, 03:13:41

OgrEGT

2022-07-13, 07:01:23

Ein MCD wird 2x32 also gesamt 64 Bit haben.
Navi32 bekommt 4 davon
Navi31 bekommt 6 davon
Wobei auch Cut down Varianten mit 3 bzw. 5 denkbar sind.

Was wir noch nicht wissen ist ob es 32MB oder 64MB pro MCD werden.
Bei 64MB werden die 40mm² vermutlich nicht reichen wenn das SI auch noch mit drauf muss.

https://mobile.twitter.com/locuza_/status/1399148639440670722
N21 N7
32b SI 6.32mm2
64MB IF$ 44.58mm2

https://www.tsmc.com/english/dedicatedFoundry/technology/logic/l_7nm
In addition, N6 manufacturing process delivers 18% higher logic density over the N7 process.

Wenn wir davon ausgehen dass das SI nicht skaliert der IF$ mit 18%

N3x MCD N6
2x32b SI 12.6mm2
64MB IF$ 37.8mm2
Insg. ca. 50mm2

Das wäre jetzt auch nicht riesig bzw. arg viel größer... woher wissen wir genau dass das MCD 40mm2 groß sein muss bzw. nicht größer sein kann?

mboeller

2022-07-13, 07:16:28

Das wäre jetzt auch nicht riesig bzw. arg viel größer... woher wissen wir genau dass das MCD 40mm2 groß sein muss bzw. nicht größer sein kann?

Gar nicht...

Das mit den 6 MCD kommt nur daher weil es mal Gerüchte gab, dass N31 aus 7 Chiplet besteht. Daran halten sich einige noch fest. Ich auch, aber eher so mit 1x I/O + 3x GCD + 3x MCD weil das nach den letzten Gerüchten mit 4096/8192/12288 CU für N33/N32/N31 für mich am meisten Sinn ergibt.

Da sich aber inzwischen alle Gerüchte als Schall und Rauch entpuppt haben... wer weiß. Wir werden es sehen wenn die RDNA3-Karten vorgestellt werden.

OgrEGT

2022-07-13, 08:44:58

Gar nicht...

Das mit den 6 MCD kommt nur daher weil es mal Gerüchte gab, dass N31 aus 7 Chiplet besteht. Daran halten sich einige noch fest. Ich auch, aber eher so mit 1x I/O + 3x GCD + 3x MCD weil das nach den letzten Gerüchten mit 4096/8192/12288 CU für N33/N32/N31 für mich am meisten Sinn ergibt.

Da sich aber inzwischen alle Gerüchte als Schall und Rauch entpuppt haben... wer weiß. Wir werden es sehen wenn die RDNA3-Karten vorgestellt werden.
Bei xGCDs müsste der Command Processor eigentlich zentral ins IO Die... ggf könnte man die GCDs in variabler Größe in x 4096SP Einheiten aus dem Wafer schneiden (ggf auch je nach Fehler Lokalisation um die Ausbeute zu maximieren) dann würde man sich den GCD-to-IO-to-GCD Interconnect sparen... analog könnte man sich das auch mit den MCDs vorstellen also (4x32b SI + 128MB IF$) Einheiten... Das IO Die wäre immer das Gleiche (ggf auch mit variabler Länge) welches variabel bestückt wird mit jeweils einem 1er/2er/3er GCD und einem 1er/2er/3er MCD...
Ggf wären auch 4er Einheiten denkbar was dem 16k SP N30 Gerücht von greymon entsprechen würde...

Das 7er Chiplet Gerücht für N31 bezieht sich ggf nicht auf Chiplets sondern auf Funktionseinheiten...

HOT

2022-07-13, 09:03:26

Oder es gibt zwei Arten von GCDs ;).

mboeller

2022-07-13, 09:07:00

Bei xGCDs müsste der Command Processor eigentlich zentral ins IO Die...

ja, das war die Idee dahinter. Der Command/Geometry-Processor zentral im I/O-Die. Allenfalls werden noch die GHz angepasst. Also bei N33 0,8GHz, bei N32 1,6GHz und bei N31 2,4GHz.

Wenn ich mich an die alten Sachen erinnere, dann war es immer problematisch die Geometrie richtig zu verteilen. Deshalb hatte AFR immer Probleme mit der Auslastung. Das würde man mit einem zentralen I/O mit Geometry+Command Prozessor umgehen.

Und wenn du dir das N21 Die anschaust, dann sind allenfalls noch die L2 Cache zentral (außer dem Command/Geometry Processor) und alles andere ist soweit eher dezentral über das Die verteilt dass ich mir nicht vorstellen kann dass man das mit multiplen nicht nachstellen und "aufblasen" könnte.

basix

2022-07-13, 12:45:23

Und wenn du dir das N21 Die anschaust, dann sind allenfalls noch die L2 Cache zentral (außer dem Command/Geometry Processor) und alles andere ist soweit eher dezentral über das Die verteilt dass ich mir nicht vorstellen kann dass man das mit multiplen nicht nachstellen und "aufblasen" könnte.

Grundsätzlich würde ich sagen, dass die Shader Engines (alles von Shader-ALUs bis und mit L1$) für sich allein stehen. Verbindung passiert dann via Command Processor sowie L2$. Deswegen sollte man mMn die SE + L1$ als Chiplet umsetzen können. Und mit zentralem Command Processor, L2$ & IF$ bleibt die GPU grundsätzlich "monolithisch".

Das AMD Patent, worüber letztens berichtet wurde, geht in eine etwas andere Richtung: Dort hat man eine Art Master Chiplet und der Rest sind Slave Chiplets. Soweit ich das verstanden habe, müssten die Chiplets ihren jeweils eigenen Command Processor / Geometrie Engine etc. tragen (zumindest in reduzierter Form), da ja ein "Fine Bin Tiling" auf dem entsprechenden Chiplet gemacht werden soll. Durch das 2-Stage Tiling erreicht man eine Art Split Frame Rendering, welches zentral und in HW vom Master Chiplet gesteuert wird. Das Master Chiplet ist somit eine Art "Work Distributor" und muss meinem Verständnis nach auch nicht identisch mit den Slave Chiplets sein (zumindest steht nichts explizit dazu im Patent). Anhand Beschreibungen im Patent wären die Memory Channels direkt in den GPU-Chiplets integriert, was ich ein bisschen irritierend finde. Alle bisheringen Gerüchte und Leaks gingen in die Richtung, das die Speicherkanäle von den Shader Engines etc. enkoppelt/abgesplitted werden. Ist evtl. aber auch nichtssagend, da in den Patent Claims rein gar nichts zu dem beschrieben ist. Wie ich mir diese Architektur vorstellen könnte:

Master Chiplet = Monolithsche GPU. Da ist der "Main Command Processor", PCIe, Video / Display etc. drauf. Das Master Chiplet kann man auch als Standalone GPU verwenden. Hier würde auch Sinn machen, dass man bei geringer Last gar nicht erst Workload auf die Slave Chiplets verteilt.
Slave Chiplets = Shader Engines + Speicher Interface
Grosse Frage 1: Wie skaliert / verbindet man die Chiplets? Interposer? Substrat?
Grosse Frage 2: Da laut Patent möglichst wenig Daten zwischen den Chiplets geteilt werden müssen, kann man den L2$ dann ebenfalls gesplittet belassen? Jeweils eine eigene Portion L2$ auf den verschiedenen Chiplets?
Grosse Frage 3: Wie skaliert man den Infinity Cache? Ebenfalls verteilt in den Chiplets enthalten? Auf einem Interposer unter den Chiplets?

Wenn ich die Gedanken so weiterspinne und RDNA3 dazunehme:

N33 = Master Chiplet (2x Shader Engines)
N32 = N33 + 2x Slave Chiplets (2 + 2 Shader Engines)
N31 = N33 + 4x Slave Chiplets (2 + 4 Shader Engines)

Geht deutlich weg vom 1x GCD + 6x MCD Konzept (inkl. dem geleakten Treiber Zeugs) aber wer weiss :)

Zossel

2022-07-13, 13:17:40

HOT

2022-07-13, 13:23:32

Interessantes Konzept basix. Ich glaub aber nicht, dass man das so löst. Entweder macht man den Master gleich ganz ohne SEs oder man macht alle SEs in den Master. Wenn man einen X3D berücksichtigt, ergibt es eigentlich am meisten Sinn, dass der IF$ in eigenen Chiplets vorliegt mit je 64MB, beim X3D dann jeweils bestapelt mit weiteren 64MB.

basix

2022-07-13, 14:15:24

Bisher ist so eine "Distributed GPU" ja daran gescheitert, dass man enorme Bandbreiten zwischen den Chiplets benötigen würde. Mit dem 2-Step-Tiling könnte man dem evtl. entgegenwirken. Aber auch wenn man das Bandbreiten-Problem so lösen könnte (und die distributed Resources wie Speicherinterfaces und Cache), gegenüber 1x GCD + 6x MCD ist es eine ganz andere Liga an Komplexität und man verliert auch den Vorteil, unterschiedliche Nodes für GCD und MCD zu nutzen. Nichtsdestotrotz sehe ich eine gewisse Attraktivität in so einem Setup.

Interessantes Konzept basix. Ich glaub aber nicht, dass man das so löst. Entweder macht man den Master gleich ganz ohne SEs oder man macht alle SEs in den Master.
Anhand des Patents würde es eben schon Sinn machen, einige SEs auf dem Master zu haben. Und man gewinnt den Vorteil, eine relativ kleine monolithische GPU zu haben, welche eben so eingesetzt werden kann (Midrange Desktop, Mobile). Skalierung von N33 bis N31 mit gerade mal 2x Chipdesigns, welche von der Chipfläche her beide relativ klein sind:
- Chiplet Master ~250mm2
- Chiplet Slave ~100mm2

Wenn man einen X3D berücksichtigt, ergibt es eigentlich am meisten Sinn, dass der IF$ in eigenen Chiplets vorliegt mit je 64MB, beim X3D dann jeweils bestapelt mit weiteren 64MB.
Klar, eine Auslagerung des Caches könnte (kosten)effizienter sein. Pro Shader Engine z.B. jeweils 64MByte. Ist aber komplexer als obige Lösung, da 3D-Stacking dazukommt. Und mometan ist der Infostand, dass bei RDNA3 kein 3D-Stacking zum Einsatz kommt.

Edit:
Achja, zu MCD und GCD:
- MCD = Master Complex Die :D
- GCD = Graphics Complex Die

Und zu 7x Chiplets:
Was ist jetzt mit der ominösen 16'384 FP32-Unit Version von RDNA3? 1x Master (64 CU) + 6x Slave (6x 32 CU)? :D
Wäre dann aber ein 512bit SI Brocken, ausser man deaktiviert einen Teil des Speicherinterfaces.

Iscaran

2022-07-13, 18:19:27

Wenn ich die Gedanken so weiterspinne und RDNA3 dazunehme:

N33 = Master Chiplet (2x Shader Engines)
N32 = N33 + 2x Slave Chiplets (2 + 2 Shader Engines)
N31 = N33 + 4x Slave Chiplets (2 + 4 Shader Engines)

Geht deutlich weg vom 1x GCD + 6x MCD Konzept (inkl. dem geleakten Treiber Zeugs) aber wer weiss :)

18.Mai 2022: https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13007543#post13007543
10.Mai 2022: https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12999911#post12999911
3.Mai 2022: https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12994172#post12994172
Mit Verweis auf Oktober 2021 wo ich im Grunde dieselbe Idee schonmal vorbrachte :-) (nur noch basierend auf alten Speku-Zahlen zu WGPs und CUs usw.)
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12808278#post12808278

Ich meine auch, dass basierend auf den Patentschriften wir eine Lösung im Sinne von
Core Dies (CCD)+ x Chiplets (MCD/GCD) sehen werden.

Mir erscheint es unlogisch warum AMD hier "nur" MCDs chipletisieren würde - nur um damit den Cache und ggf. das SI zu skalieren, aber dann 3 unterschiedliche Monotlithische Core Dies auflegen würde (um die Shader Engines unterzubringen).

Für mich das plausibelste ist man brauch beides. MCDs + GCDs und die beiden braucht man in bestimmten Verhältnissen zueinander um sie mit dem CCD zu verbrücken.

1 CCD + x MCD + y GCD ergeben dann immer einen Chip.
Wobei x/y z.B. 1:1 oder 2:1 sein muss (oder ähnliches)

Das CCD ist immer gleich (?), auf jeden Fall aber ist das MCD immer gleich und das GCD immer gleich in dem Ansatz.

N33: 1 CCD + 0 MCD + 0 GCD
N32: 1 CCD + 2 MCD + 1 GCD
N31: 1 CCD + 4 MCD + 2 GCD

CCD: Basis SI (z.B. 128 Bit)
GCD = 16 WGPs = 4096 Shader
MCD = 64 bit SI + 64 MB Cache (z.B. Werte hier unklar/variabel)

FALLS der Cache zum "verkleben" nötig ist kann sein dass JEDES Bauteil eine bestimmte Menge Cache tragen muss.
Also CCD z.B. 32 MB Cache, MCD 64 MB Cache, GCD 32 MB Cache
(Die Menge an MB Cache kann ich schlecht einschätzen, aber evtl. sowas in der Art).

Dann wären die 3 Chips wie folgt:
N33 also 16 WGPs mit 32+32 MB Cache @128 Bit => 8 oder 16 GB VRAM ?
N32 also 16+16 WGPs mit 32+32+2x64 MB Cache (=192 MB) @128+128 bit (256 Bit)
N31 16+16+16 WGP, 32+2x32+4x64 = (352 MB Cache) @128+256 Bit)

Just my 2 cents.

iamthebear

2022-07-13, 22:22:33

https://mobile.twitter.com/locuza_/status/1399148639440670722
N21 N7
32b SI 6.32mm2
64MB IF$ 44.58mm2

https://www.tsmc.com/english/dedicatedFoundry/technology/logic/l_7nm
In addition, N6 manufacturing process delivers 18% higher logic density over the N7 process.

Wenn wir davon ausgehen dass das SI nicht skaliert der IF$ mit 18%

N3x MCD N6
2x32b SI 12.6mm2
64MB IF$ 37.8mm2
Insg. ca. 50mm2

Das wäre jetzt auch nicht riesig bzw. arg viel größer... woher wissen wir genau dass das MCD 40mm2 groß sein muss bzw. nicht größer sein kann?

Die MCDs sind in 6nm gefertigt. Bei 6nm ist Logic ca. 10% kleiner, SRAM vermutlich maximal 5% oder auch gar nicht.

Ichgehe allerdings mittlerweile doch eher von 32MB pro MCD aus.

Gar nicht...

Das mit den 6 MCD kommt nur daher weil es mal Gerüchte gab, dass N31 aus 7 Chiplet besteht. Daran halten sich einige noch fest. Ich auch, aber eher so mit 1x I/O + 3x GCD + 3x MCD weil das nach den letzten Gerüchten mit 4096/8192/12288 CU für N33/N32/N31 für mich am meisten Sinn ergibt.

Von mehr als 3 GCDs war noch nie die Rede und das wird auch nicht ohne Weiteres so funktionieren, da der Cache zwischen den GCDs als Bridge funktionieren muss, da dieser geshared ist. Es macht auch von der Größe her keinen Sinn.

Aktueller Kenntnisstand ist:
N33 ist monolithisch (16 WGP)
N31/2 ist großteils monolithisch nur sind SI und IC als MCDs ausgelagert (32 bzw. 48 WGP mit 4 bzw. 6 MCDs)
N3X (X ist noch nicht bekannt aber > 3) soll das Flagship 2023 werden und aus 2 GCDs je 32WGP bestehen.

Da sich aber inzwischen alle Gerüchte als Schall und Rauch entpuppt haben... wer weiß. Wir werden es sehen wenn die RDNA3-Karten vorgestellt werden.

So wie es gerade aussieht waren die Fehlinformationen:
.) 2 GCDs für N31/32, die gibt es erst bei N3x
.) Die 60/40/20 WGP. Das sind nur 48/32/16.

dargo

2022-07-13, 22:24:56

Kann man die 384Bit SI und 24GB Vram bei N31 schon als gesichert sehen?

ChaosTM

2022-07-13, 22:29:58

Alles unter 24 wäre nach den 16 der derzeitigen Gen etwas "enttäuschend.

Linmoum

2022-07-13, 22:40:31

Kann man die 384Bit SI und 24GB Vram bei N31 schon als gesichert sehen?Wenn man nicht annimmt, dass die Patches von AMD wiederholt (und bewusst) Falschinformationen enthalten, dann ist das mittlerweile nahezu sicher.

prinz_valium_2

2022-07-14, 00:59:10

Wahrscheinlich aber auch nur für den absoluten top dog chip.
Denke der enthusiast salvage wird 20GB.

Also Ka, ob die 24GB sofort kommen, oder erst später.

Linmoum

2022-07-14, 01:30:09

Bei einem 384bit SI wird es auch sofort 24GiB geben. Das SI einfach künstlich zu beschneiden wird es so auch nicht geben, da es wohl auf 1xMCD/SE (N31 hat nach aktuellem Stand derer 6) hinausläuft.

Hat bei Salvages natürlich den Vorteil, dass man die MCDs dann komplett weglassen kann und keinen Ballast in Form von totem Silizium hat. Entsprechend reduzieren sich dann auch logischerweise das SI und der Speicherausbau.

Das hat mit Blick auf Time-to-Market und dem Entwicklungsaufwand schon alles riesige Vorteile, wenn das tatsächlich so kommt. Deswegen ist dieses "N33 ist aber noch monolithisch" auch Quatsch. Ganz zu schweigen davon, dass AMD das auf dem FAD im Prinzip selbst schon begraben hat. Das ist alles 1xGCD+MCDs.

basix

2022-07-14, 07:09:36

Deswegen ist dieses "N33 ist aber noch monolithisch" auch Quatsch. Ganz zu schweigen davon, dass AMD das auf dem FAD im Prinzip selbst schon begraben hat. Das ist alles 1xGCD+MCDs.

Ist auch meine Vermutung. N33 monolithisch und dann noch N6 macht mMn zu wenig Sinn.

dargo

2022-07-14, 08:27:52

Bei einem 384bit SI wird es auch sofort 24GiB geben. Das SI einfach künstlich zu beschneiden wird es so auch nicht geben, da es wohl auf 1xMCD/SE (N31 hat nach aktuellem Stand derer 6) hinausläuft.

Hat bei Salvages natürlich den Vorteil, dass man die MCDs dann komplett weglassen kann und keinen Ballast in Form von totem Silizium hat. Entsprechend reduzieren sich dann auch logischerweise das SI und der Speicherausbau.

Wie meinst du das? Meinst du vom N31 wird es keinen Salvage in alter bekannten Manier mehr geben und der Salvage dann praktisch N32 heißt?

Edit:
Stop... Denkfehler bei mir. Der Salvage vom N31 wird dann sicherlich 5x MCD haben mit dann 20GB Vram.

HOT

2022-07-14, 08:45:56

Nope, eher nicht. Das wäre ja eine Produktionsänderung beim Packageing. Die werden alle 6 MCDs bekommen. Die Frage ist dann eher, ob man auch defekte verbaut und so salvaged.

AffenJack

2022-07-14, 09:02:28

Alleine schon um Packagingfehler bei den MCD zu salvagen wird man natürlich auch bei einer 5 MCD Version trotzdem 6 MCD verbauen. Nur dann eventuell mit Dummies oder auch defekten MCDs.

Linmoum

2022-07-14, 09:34:48

So viel defekte MCDs dürfte es gar nicht geben, die man in ausreichenden Stückzahlen dann dafür nutzen könnte. Die sind sicher noch mal ein gutes Stück kleiner als die ohnehin schon winzigen Zen-Chiplets. Ist aber trotzdem möglich, dass man das so handhabt oder alternativ Dummys nutzt.

In jedem Fall hat man die Abstufung dann trotzdem

N31 mit 6SE/6MCD und 5SE/5MCD
N32 mit 4SE/4MCD und 3SE/3MCD
N33 mit 2SE/2MCD und 1SE/1MCD

Dass man für jede 3% eine SKU auflegt ist sowieso albern. Das reicht als Portfolio von oben bis unten und dürfte in der Hinsicht maximal effizient sein.

dargo

2022-07-14, 09:41:48

Nope, eher nicht. Das wäre ja eine Produktionsänderung beim Packageing. Die werden alle 6 MCDs bekommen. Die Frage ist dann eher, ob man auch defekte verbaut und so salvaged.
Du meinst das extra Packaging wäre in dem Fall finanziell ungünstig?

Neurosphere

2022-07-14, 10:28:30

Cyberfries

2022-07-14, 12:02:47

Amd beschneidet ungern SIs, in den letzten 10 Jahren nur zweimal. Selbst die um ein ganzes SE ärmere 6800
setzt immer noch auf die vollen 16gb/128mb obwohl 12gb/96mb gegenüber nVidia immer noch besser ausgesehen hätte.

Die 7900 sollte min. 42 WGP haben, da sonst entweder der Abstand zur 7900xt recht groß würde oder der Takt recht hoch sein müsste.
Also 6 SE - und dann nur 5 MCD? Machbar aber unwahrscheinlich und von unten schränkt N32 den Raum für einen zweiten Salvage ein.

Für N32 ist dagegen eine 7700xt mit 3 SE / 22 WGP / 3 MCD duchaus sinnig um die große Lücke zu N33 zu schließen.

Leonidas

2022-07-14, 12:38:52

Hier entnommen:
https://www.3dcenter.org/news/geruechtekueche-amds-navi-31-mit-384-bit-interface-192-mb-infinity-cache-und-optional-192-mb-3d

https://www.3dcenter.org/dateien/abbildungen/AMD-Navi-31-GCD-MCD-3D-V-Cache.png

basix

2022-07-14, 22:42:25

N31 mit 6SE/6MCD und 5SE/5MCD
N32 mit 4SE/4MCD und 3SE/3MCD
N33 mit 2SE/2MCD und 1SE/1MCD

Ich denke nicht, dass es so viele Salvages mit weniger MCDs usw. geben wird. Und 50% Salvage von N33? Nee ;)
- N31 = 6 / 5 SE; 6 / 5 MCD --> 384 / 320bit @ 18 Gbps @ 24 / 20 GByte
- N32 = 4 / 3 SE; 4x MCD --> 256bit @ 16-18 Gbps @ 16 GByte
- N33 = 2 SE; 2x MCD --> 96bit @ 21 Gbps = 12 GByte
- N33 Mobile = 2 SE; 2x MCD --> 128bit @ 16 Gbps = 8 / 16 GByte

MCD und Packaging Yield wird >97% betragen. Da lohnt sich Salvaging nur bedingt.

basix

2022-07-18, 11:03:18

Mit Samsungs neuem Speicher (https://www.computerbase.de/2022-07/fuer-rtx-4000-und-rx-7000-samsungs-gddr6-speicher-beschleunigt-auf-24-gbps/) ergibt sich eine interessante Option hinsichtlich Energieeffizienz:
- 20 Gbps @ 1.1V
- Umladeverluste in Leiterbahnen etc. sind aufgrund der reduzierten Spannung gleich hoch wie bei RDNA2 @ 16 Gbps --> C*U*f (Annahme: Selbes PCB Design)
- Theoretisch effizientere GDDR6-Module, Speichercontroller & PHY, da reduzierte Spannung (U^2*f)

Meine Erwartung:
- 20 Gbps benötigt nicht mehr Energie als RDNA2 heute mit 16 Gbps --> 1.25x Energieffizienz

Moonshot:
- Im besten Fall sogar noch ein gutes Stück weniger (mit entsprechenden Optimierungen an Speichercontroller, PHY & PCB). Energieverbrauch 384bit@ 20Gbps in etwa auf Niveau 256bit @ 16Gbps --> 1.88x Energieeffizienz. Dazu müssten die Umlade-Kapazitäten in den PHYs sowie im PCB um 1.5x sinken. Möglichkeiten: GDDR6 Module wandern näher zum Chip, reduzierte Kapazität von Seiten Chip-Package und mehr PCB-Layer. Neben dem müssten auch die PHYs sowie der Speichercontroller an sich deutlich stromsparender sein. Mit N5HPC sehe ich hier gewisse Chancen.

HOT

2022-07-18, 11:13:59

Na ja, der Speichercontroller wird ja N6 sein. Aber es wird kaum ne Rolle spielen, ob N5 oder N6, das Design muss halt effizient sein. Kommt halt darauf an, wie gut die neueren Varianten der Controller von Synopsys, RAMBUS und co. geworden sind. Die sind ja passend für bis zu 24GT/s designt worden dann.

basix

2022-07-18, 11:29:14

Stimmt, hast recht. MCD "sollen" ja in N6 daherkommen.

reaperrr

2022-07-19, 19:12:04

Stimmt, hast recht. MCD "sollen" ja in N6 daherkommen.
"Werden" meiner Meinung nach auch, weil es einfach Sinn macht.

Die MCDs werden ja quasi ausschließlich aus Cache (SRAM-Zellen) und SI (analogen Transistoren) bestehen, für die TSMC nur Packdichte-Verbesserungen von 1,3x bzw. 1,2x in N5 ggü. N7 angibt (also eher noch etwas weniger ggü. N6, da der zumindest SRAM evtl. etwas dichter packen kann als N7), während N5-Wafer wahrscheinlich massiv (Gerüchten zufolge Stoßrichtung 1,8x) teurer sein werden als N6.
Auch der Effizienz-Vorteil von N5 ggü. N6 sollte gerade in den Bereichen SRAM und Interfaces eher geringer ausfallen als bei Logik-Transistoren, es würde also auch vom Verbrauch/Takt her nicht so viel bringen, die in N5 zu produzieren.

Ganz abgesehen davon, dass halt auch die Frage ist, wieviele N5-Wafer sich AMD überhaupt sichern konnte/wollte, da ist es vielleicht nicht nur aus Kosten-, sondern auch Kapazitätsgründen besser, für Sachen wie den MCD auf N6 auszuweichen.

Leonidas

2022-07-20, 09:45:41

GCD von N31 ist bei 350+mm²
gesamter Chip ergo bei ~590mm² (ohne extra 3DVC), mit extra 3DVC grob ~710mm²
https://www.3dcenter.org/news/news-des-19-juli-2022

HOT

2022-07-20, 09:51:16

Hui, da hat man die WGPs aber echt ganz schön geschrumpft.

Linmoum

2022-07-20, 09:54:40

RGT spricht schon seit Monaten von 380mm2-400mm2 für das Single GCD. Dürfte IMO auch passen.

Zossel

2022-07-20, 10:16:40

für die TSMC nur Packdichte-Verbesserungen von 1,3x bzw. 1,2x in N5 ggü. N7 angibt

Eigentlich wäre der Faktor für eine bessere Packdichte < 1.

reaperrr

2022-07-20, 10:40:46

Eigentlich wäre der Faktor für eine bessere Packdichte < 1.
Nicht, wenn es um die maximale Transistorzahl in gleicher Fläche geht :)

amdfanuwe

2022-07-20, 11:08:55

OK, so langsam bin ich auch davon überzeugt, dass 1 x GCD + 6 x MCD kommt.
Die MCDs mit je 32 MB IF$ und 64 Bit SI. Zum MCD hin dürfte die Anbindung breiter/schneller ausfallen.
Der IF$ Cached also nur die Inhalte der jeweils angeschlossenen Speicherchips und das Konstrukt aus MCD und 64 Bit Speicher wirkt für den GCD wie ein herkömmlicher Speicher mit 128 Bit Anbindung.
Damit verhielte sich das N31 MCD praktisch wie eine "normale" GPU ohne IF$ mit virtuell 768 Bit SI.
N32 entsprechend wie mit einem virtuellem 512 Bit SI.

Ob das von vornherein Plan A war oder nur Plan B ist werden wir wohl nie erfahren.
Was solls, mal sehen was dabei raus kommt

mboeller

2022-07-20, 12:11:00

OK, so langsam bin ich auch davon überzeugt, dass 1 x GCD + 6 x MCD kommt.

ja... grummel grummel... ;)

https://videocardz.com/newz/amd-rdna3-navi-31-gpu-with-six-mcds-to-feature-384-bit-wide-memory-bus

Some new information on AMD next-gen RDNA3 series has been posted and immediately retracted from Linux code.

If this is true, then this would confirm previous rumors that Navi 31 has a single GCD (Graphics Complex Die) and six MCDs

robbitop

2022-07-20, 12:19:51

Der IF$ Cached also nur die Inhalte der jeweils angeschlossenen Speicherchips und das Konstrukt aus MCD und 64 Bit Speicher wirkt für den GCD wie ein herkömmlicher Speicher mit 128 Bit Anbindung.
So war es nach meinem Verständnis bereits in Navi 2x implementiert. Der IF$ war segmentiert und es gab pro Speicherkanal im IMC eben ein IF$ Segment was für diesen Speicherkanal cacht.

basix

2022-07-20, 12:48:32

So war es nach meinem Verständnis bereits in Navi 2x implementiert. Der IF$ war segmentiert und es gab pro Speicherkanal im IMC eben ein IF$ Segment was für diesen Speicherkanal cacht.

Was auch Sinn macht. Eine GPU wird zwecks Bandbreiten-Maximierung die Daten über verschiedene Speicherkanäle verteilen wollen. Somit reicht ein Caching pro Speichersegment aus. Irgendwo gibt es aber sicher noch eine Verschaltung der einzelnen Segmente zu einem dann eben "unified" Infinity Cache.

amdfanuwe

2022-07-20, 12:50:06

So war es nach meinem Verständnis bereits...
Das Verständnis fehlte mir bisher :confused:. Na, besser spät als nie.

Bin schon gespannt, wie AMD die anbindet und ob da noch GPUs mit nur einem MCD (64 Bit SI) kommen. Sonst hätte man die MCDs ja auch direkt doppelt so groß (128 Bit SI) ausführen können. Ob 40 oder 80 mm² sollte beim Yield noch keinen so großen Unterschied machen.

Leonidas

2022-07-20, 12:56:13

64-Bit ist die natürliche Organisations-Form beim Speicherinterface. Macht man 128-Bit in einen MCD, sind das trotzdem 2x 64 Bit Teilinterfaces.

Einen Vorteil hat das ergo nicht. Kleinere Chips sind immer besser. Und wenn man mal Salvage mit 320-bit oder 192-bit machen will, dann rechnet sich das kleinere MCD sofort.

Der_Korken

2022-07-20, 12:58:39

amdfanuwe

2022-07-20, 13:03:29

Irgendwo gibt es aber sicher noch eine Verschaltung der einzelnen Segmente zu einem dann eben "unified" Infinity Cache.
Wozu denn? Wenn jeder nur seinen jeweiligen Speicherbaustein cached, braucht es kein unified.
Der L2 dient als unified Cache. Für den GPU Kern sieht das Konstrukt aus IF$ und Speicherbaustein wie ein normaler Speicher aus. Nur eben beschleunigt durch den IF$.

basix

2022-07-20, 13:13:30

Wozu denn? Wenn jeder nur seinen jeweiligen Speicherbaustein cached, braucht es kein unified.
Der L2 dient als unified Cache. Für den GPU Kern sieht das Konstrukt aus IF$ und Speicherbaustein wie ein normaler Speicher aus. Nur eben beschleunigt durch den IF$.

Wegen den 1024 Byte/clk Bandbreite, welche der IF$ zur Verfügung stellen muss. Sonst kommt es zu asymmetrischen Zugriffspattern, je nach Daten welche im entsprechende Cache-Slice liegen. Und weil man so die Gesamtmenge des IF$ besser nutzen kann. Im Optimalfall sind die Daten aber genug feingranular verteilt, dass diese Nachteile gering ausfallen.

Klar, man kann das natürlich vereinfachen und dann haben die 8x 32bit Memory-Channel Segmente jeweils einen 128Byte Anschluss zum L2$. Ist vermutlich auch hinsichtlich Routings des Chips deutlich einfacher. Dann wird es aber zwangsläufig darauf rauslaufen, dass das jeweilige IF$-Slices eine gewisse underutilization aufweisen werden, da man keine Daten innerhalb des IF$ zwischen den Slices hin und her schieben könnte. Das ginge in diesem Fall nur, wenn man zuerst den Umweg über den L2$ machen würde. Und das hat den Nachteil, dass man relativ weite Wege gehen muss (in Distanz gemessen).

Die Segmentierung des IF$ ergibt sich allein schon aus der Tatsache, dass der Cache eine beschränkte Assoziativität hat. Jede Adresse kann nur in n Cache-Zeilen gecached werden bei n-facher Assoziativität. Bei N21 gab es 8 Speichercontroller, die jeweils 1/8 des physischen Adressraums bedient haben. Anhand der Speicheradresse konnte man also ablesen zu welchem der 8 Controller man die Anfrage schicken musste.

Jetzt kann aber sowieso nicht jede Adresse in jede Cache-Zeile rein. Warum also die n möglichen Zeilen nicht immer so positionieren, dass sie in dem Cache-Slice liegen, dass direkt neben dem passenden Speicher-Controller liegt? Das verkürzt die Datenwege dramatisch und besitzt theoretisch keine Nachteile gegenüber einer zufälligen Verteilung über alle Slices. Ausnahme: Es wird die ganze Zeit nur der Adressraums eines Controllers genutzt und dadurch auch nur ein Cache-Slice. Dagegen müssten GPUs aber schon lange entsprechende Mechaniken haben, weil GPUs ohne IF$ sonst auch komplett umfallen würden, weil sie die ganze Zeit nur 1/8 ihrer Speicherbandbreite nutzen würden.

Danke für die Erklärung. Wie oben von mir geschrieben: Ist dann eben nicht eine gewisse Underutilization der Cache-Slices zu erwarten? Halt je nach Granularität und Grösse der Datenblöcke.

amdfanuwe

2022-07-20, 13:55:58

Anhand der Speicheradresse konnte man also ablesen zu welchem der 8 Controller man die Anfrage schicken musste.

Wie stellst du dir das bei salvaged Chips vor? Mit z.B. 6 Controllern 192 Bit, oder 320 Bit etc.

Ausnahme: Es wird die ganze Zeit nur der Adressraums eines Controllers genutzt und dadurch auch nur ein Cache-Slice. Dagegen müssten GPUs aber schon lange entsprechende Mechaniken haben, weil GPUs ohne IF$ sonst auch komplett umfallen würden, weil sie die ganze Zeit nur 1/8 ihrer Speicherbandbreite nutzen würden.
Daran hab ich mir auch etwas die Zähne ausgebissen.
Ist aber kein Problem die vorhandenen Chips so zu mappen, dass sie z.B. interleaved mit jeweils 32, 256 Byte oder 1MB etc angesprochen werden.
Physikalisch verteilen sich die Adressen damit kunterbunt über alle Speicherchips. Ist denen aber egal.
Bei einer Speicheranforderung über einen Kanal wird die Adresse geschickt und der Speicherbaustein schickt dann 8x32 Bit = 32 Byte zurück.
In NVIDIA Fermi and Kepler GPUs (probably Maxwell too), an L1 cache line is 128-bytes long, while an L2 cache line is 32-byte long
Die nächsten 32 Byte können sich auf einem anderen Speicherchip befinden, je nachdem wie man das Interleaving ausführt.
Zwar etwas tricki bei einer von 2^n abweichenden Anzahl von Speicherchips, aber einfach machbar. Man muß sich nur von dem Gedanken lösen, dass die Physikalischen Adressen in einem Speicherbaustein auch logisch in der Reihenfolge angesprochen werden.

Der_Korken

2022-07-20, 14:07:50

Das Risiko einer schlechten Auslastung ist nicht höher als ohne Cache, da du ja auch so schon deine Zugriffe möglichst gut auf die einzelnen Speichercontroller verteilen musst. Ich weiß nicht, wie es tatsächlich gemacht wird, aber eine blockweise Aufteilung der physischen Adressen ist vermutlich schlecht, d.h. erster Controller: Adresse 1 bis 2*1024^3 - 1 (also die ersten 2 GB), zweiter Controller 2*1024^3 bis 4*1024^3 - 1 (die nächsten 2GB), etc. Wenn man nämlich ein großes Array hat, das einen zusammenhängenden phyischen Bereich einnimmt und oft gelesen wird, dann landet das wahrscheinlich komplett in einem Controller und der Durchsatz ist gering. Besser wäre es, wenn man das nach Cache-Zeilen (sind das bei GPUs auch 64Bytes?) aufteilt: Erster Controller bekommt erste Cache-Zeile, also die ersten 64 Bytes, zweiter Controller bekommt zweite Cache-Zeile, also Bytes 64 bis 127, usw. Nach 8*64 Bytes geht es wieder von vorne los. Dadurch sind die physischen Adressen stark gestreut und jeder große zusammenhängende Speicherbereich, den ich auslesen will, kann von allen Controllern parallel gelesen werden. Natürlich kann man sich auch da irgendwelche pathologischen worst-case-Szenarien ausdenken. Zum Beispiel, dass ich aus einer Matrix, die zeilenweise gespeichert wurde, eine Spalte auslesen will und die Daten zufällig immer genau in 512Byte Abstand zueinander liegen, sodass alle physischen Adressen dafür auf einen Speichercontroller fallen. Solche Fälle sind aber unwahrscheinlich und selbst wenn, gibt es in der Regel so viel parallele Arbeit auf der GPU, dass das insgesamt die Performance nicht stark beeinträchtigt.

Ansonsten zu der Idee einen "unified cache" zu haben: Man könnte die Zuweisungen der Adressen zu Cache-Slices auch sehr chaotisch wählen, sodass jeder Slice Daten von jedem Controller halten kann. Hier wäre die Konstruktion eines worst-case-Zugriffsmusters wie oben deutlich schwieriger (aber nicht unmöglich). Allerdings wird die Effizienz in den Keller gehen. Jeder Speicherzugriff müsste dann quer über die gesamte GPU zu allen Cache-Slices geschickt werden, weil ich ja überall nachgucken muss, ob meine Daten nicht zufällig genau da liegen. Man müsste also viele Datenleitungen legen, die Fläche und Strom kosten, die Latenz wird auch schlechter ausfallen und man bekommt komische Abhängigkeiten rein, wenn man mal einen Cache-Slice aus Yield-Gründen abschalten will. Ich glaube dass die Nachteile einer solchen Organisation viel größer als die Vorteile sind und AMD das deswegen aufgeteilt hat. Noch krasser wird es, wenn du bei Chiplets einen über mehrere Chips hinweg zusammenhängenden Cache haben willst. Intel baut sowas bei Sapphire Rapids und Latenz+Bandbreite von dem Teil sind grottenschlecht. Es kann zwar jeder Core den gesamten L3 nutzen (im Gegensatz zu AMDs Epyc), aber für diese Spezialfälle, wo ein Kern alles an Cache braucht und die anderen Kerne quasi nichts, ist es AMD wohl nicht wert dafür alle "normalen" Anwendungsfälle auszubremsen.

Gipsel

2022-07-20, 14:23:11

Die Segmentierung des IF$ ergibt sich allein schon aus der Tatsache, dass der Cache eine beschränkte Assoziativität hat. Jede Adresse kann nur in n Cache-Zeilen gecached werden bei n-facher Assoziativität. Bei N21 gab es 8 Speichercontroller, die jeweils 1/8 des physischen Adressraums bedient haben. Anhand der Speicheradresse konnte man also ablesen zu welchem der 8 Controller man die Anfrage schicken musste.

Jetzt kann aber sowieso nicht jede Adresse in jede Cache-Zeile rein. Warum also die n möglichen Zeilen nicht immer so positionieren, dass sie in dem Cache-Slice liegen, dass direkt neben dem passenden Speicher-Controller liegt? Das verkürzt die Datenwege dramatisch und besitzt theoretisch keine Nachteile gegenüber einer zufälligen Verteilung über alle Slices.Deswegen macht AMD das auch schon seit ewig und 3 Tagen genau so (Zuordnung von L2-Tiles zu Speicherkanälen). Schon bei den VLIW-GPUs war das so.
Das Risiko einer schlechten Auslastung ist nicht höher als ohne Cache, da du ja auch so schon deine Zugriffe möglichst gut auf die einzelnen Speichercontroller verteilen musst. Ich weiß nicht, wie es tatsächlich gemacht wird, aber eine blockweise Aufteilung der physischen Adressen ist vermutlich schlecht, d.h. erster Controller: Adresse 1 bis 2*1024^3 - 1 (also die ersten 2 GB), zweiter Controller 2*1024^3 bis 4*1024^3 - 1 (die nächsten 2GB), etc. Wenn man nämlich ein großes Array hat, das einen zusammenhängenden phyischen Bereich einnimmt und oft gelesen wird, dann landet das wahrscheinlich komplett in einem Controller und der Durchsatz ist gering. Besser wäre es, wenn man das nach Cache-Zeilen (sind das bei GPUs auch 64Bytes?) aufteilt: Erster Controller bekommt erste Cache-Zeile, also die ersten 64 Bytes, zweiter Controller bekommt zweite Cache-Zeile, also Bytes 64 bis 127, usw. Nach 8*64 Bytes geht es wieder von vorne los. Dadurch sind die physischen Adressen stark gestreut und jeder große zusammenhängende Speicherbereich, den ich auslesen will, kann von allen Controllern parallel gelesen werden.Auch hier hast Du den Grund für dieses Vorgehen korrekt beschrieben. Einige GPUs haben übrigens 128Byte Cachelines (auch RDNA-GPUs, zumindest für die L0-vD$ sowie L1 und L2 [bzw. Infinitycache bei RDNA2]; die L0-I$ und L0-sD$ haben 64Byte-Lines), vermutlich weil dann im Optimalfall alle 32 Elemente (zu je 4 Byte) einer Wavefront in eine Cacheline passen, wenn der Speicherzugriff entsprechend aligned ist.

CPUs verfolgen übrigens eine andere Strategie (sind ja latenzsensitiver und meist reicht die Bandbreite eines einzelnen Speicherkanals für einen einzelnen Thread locker aus). Der Adressraum wird bei CPUs inzwischen (seit ~10-12 Jahren?) nur noch höchst selten an Cachelinegrenzen zwischen den Kanälen interleaved (sondern quasi unabhängig voneinander betrieben). Soweit ich weiß nimmt man dafür inzwischen eher die 4kB Pages (im Prinzip könnte man dafür auch einfach in lineare Blöcke teilen und die Randomisierung der Address Translation Tabellen in modernen OS machen dann den Rest, macht glaube ich aber keiner, sondern die Bits für die Aufteilung auf die Speicherkanäle sind normalerweise von der Randomisierung ausgenommen). Dies hat den Vorteil, daß man bei einem dual channel interface nicht in beiden Speicherkanälen exakt die gleichen Speicherbänke aufmachen muß, sondern auf dem zweiten Speicherkanal andere Bänke gleichzeitig aufhaben kann. Die Anzahl der gleichzeitig offenen Bänke erhöht sich also (verdoppelt bei "dual channel", vervierfacht bei quad channel usw.). Damit reduziert sich die effektive Latenz in der Praxis (weil man etwas weniger häufig Speicherbänke öffnen und schließen muß, was eine Operation mit recht hoher Latenz ist) auf Kosten der (von einem oder wenigen Threads) maximal erreichbaren Bandbreite. Letzteres ist aber für CPUs normalerweise nicht wichtig für die Performance, Ersteres schon.

==================

Wie stellst du dir das bei salvaged Chips vor? Mit z.B. 6 Controllern 192 Bit, oder 320 Bit etc.Die Cache-Tiles gehören quasi mit zum Speicherinterface. Bei AMD wird die zum Controller gehörende Tile des Caches dann schlicht auch deaktiviert. Gibt es z.B. 4MB L2 an einem 256Bit Interface, sind bei Deaktivierung von 64bit des Interfaces (also dann nur noch 192bit aktiv) nur noch 3 MB L2 aktiv. Beim Infinity-Cache sieht es genau so aus.

basix

2022-07-20, 14:36:19

Danke euch für die Erläuterungen! :up:

Fazit:
Aufgesplitteter Infinity Cache und Separierung in Chiplets haben grundsätzlich keinen Einfluss auf den generellen Aufbau der GPU sowie deren Funktionsweise. Somit ist die Aufsplittung in 1x GCD und 6x MCD eine wirklich extrem naheliegende Option. Man nimmt die Chiplet-Vorteile mit, hinsichtlich Funktionsweise ist es aber immer noch extrem nahe an einer monolithischen GPU.

CPUs verfolgen übrigens eine andere Strategie (sind ja latenzsensitiver und meist reicht die Bandbreite eines einzelnen Speicherkanals für einen einzelnen Thread locker aus). Der Adressraum wird bei CPUs inzwischen (seit ~10-12 Jahren?) nur noch höchst selten an Cachelinegrenzen zwischen den Kanälen interleaved (sondern quasi unabhängig voneinander betrieben). Soweit ich weiß nimmt man dafür inzwischen eher die 4kB Pages (im Prinzip kann man dafür auch einfach in lineare Blöcke teilen und die Randomisierung der Address Translation Tabellen in modernen OS machen dann den Rest). Dies hat den Vorteil, daß man bei einem dual channel interface nicht in beiden Speicherkanälen exakt die gleichen Speicherbänke aufmachen muß, sondern auf dem zweiten Speicherkanal andere Bänke gleichzeitig aufhaben kann. Die Anzahl der gleichzeitig offenen Bänke erhöht sich also (verdoppelt bei "dual channel", vervierfacht bei quad channel usw.). Damit reduziert sich die Latenz (Speicherbänke öffnen und schließen ist eine Operation mit recht hoher Latenz) auf Kosten der (von einem oder wenigen Threads) maximal erreichbaren Bandbreite. Letzteres ist aber für CPUs normalerweise nicht wichtig für die Performance, Ersteres schon.

Interessant. Daher die inherenten Performance-Vorteile von DDR5 vs. DDR4? Dual-Channel DDR5 ist grundsätzlich ja ein Quad-Channel Interface mit halbierter Breite.

amdfanuwe

2022-07-20, 15:02:58

Besser wäre es, wenn man das nach Cache-Zeilen (sind das bei GPUs auch 64Bytes?) aufteilt: Erster Controller bekommt erste Cache-Zeile, also die ersten 64 Bytes, zweiter Controller bekommt zweite Cache-Zeile, also Bytes 64 bis 127, usw. Nach 8*64 Bytes geht es wieder von vorne los.
Bei Fermi und Kepler hat L2 32 Byte Cacheline, also das was ein Kanal bei einem Zugriff liefert.
https://forums.developer.nvidia.com/t/cache-line-size-of-l1-and-l2/24907
Was anderes find ich auf die schnelle nicht.

Die Controller abwechseln anzusprechen ist dann interleaved Betrieb.
Bei 2, 4, 8 Kanälen kein Problem, bei anderen Kanalanzahlen wird es etwas komplexer.
Z.B. Bei 3 Chips a 2GByte kann man mit einem virtuellem Adressbereich von 8 GByte arbeiten.
1 2 3 (4)
5 6 7 (8)
Die im nicht vorhandenem Chip 4 liegenden Daten werden auf 7 gemapped.
1 2 3
5 6 4
Voila 6 GByte auf 3 Chips, alle sind glücklich.
Kann man mt beliebiger Blockgröße und Chipanzahl machen.

amdfanuwe

2022-07-20, 15:09:43

==================

Die Cache-Tiles gehören quasi mit zum Speicherinterface. Bei AMD wird die zum Controller gehörende Tile des Caches dann schlicht auch deaktiviert....
Das war nicht das Problem. Ging schlicht darum, dass man an der Adresse einfach ablesen kann, welcher Kanal anzusprechen ist.

Gipsel

2022-07-20, 15:14:37

Das war nicht das Problem. Ging schlicht darum, dass man an der Adresse einfach ablesen kann, welcher Kanal anzusprechen ist.Modulo 6 der Adresse (abzüglich der letzten 7bits, die innerhalb der Cacheline adressieren) bekommt man schon noch hin, wenn es sein muß.

Zossel

2022-07-20, 15:15:06

Dagegen müssten GPUs aber schon lange entsprechende Mechaniken haben, weil GPUs ohne IF$ sonst auch komplett umfallen würden, weil sie die ganze Zeit nur 1/8 ihrer Speicherbandbreite nutzen würden.

Selbst in deterministischen Maschinen sind manche Dinge hinreichend zufällig :-)

amdfanuwe

2022-07-20, 15:25:03

Interessant. Daher die inherenten Performance-Vorteile von DDR5 vs. DDR4? Dual-Channel DDR5 ist grundsätzlich ja ein Quad-Channel Interface mit halbierter Breite.
sollte etwas ausmachen, wesentlich sind andere Vorteile:
Bei DDR5-Arbeitsspeicher steigt die Bandbreite der Riegel auf bis zu 51 Gb/s und ist damit fast doppelt so schnell wie bei DDR4 (26Gb/s). Weiter verbessern sich die Datenübertragungsraten, Taktraten sowie die Effizienz. Zudem haben DDR5 Speichermodule einen etwas geringeren Stromverbrauch.
Quelle: Google ddr4 vs ddr5

Gipsel

2022-07-20, 15:33:00

Interessant. Daher die inherenten Performance-Vorteile von DDR5 vs. DDR4? Dual-Channel DDR5 ist grundsätzlich ja ein Quad-Channel Interface mit halbierter Breite.Bei latenzsensitiven Dingen kann dies (natürlich je nach Zugriffsmuster) eine Rolle spielen, ja. Ist nicht ganz unähnlich zu den Performanceunterschieden zwischen single und dual rank Speichermodulen.

amdfanuwe

2022-07-20, 15:36:53

Modulo 6 der Adresse (abzüglich der letzten 7bits, die innerhalb der Cacheline adressieren) bekommt man schon noch hin, wenn es sein muß.
Klar aber nicht durch Berechnung mittels ALU.
Schnellstes dürfte eben Adresstranslation mit entsprechendes Mapping sein.

Gipsel

2022-07-20, 16:04:47

Klar aber nicht durch Berechnung mittels ALU.
Schnellstes dürfte eben Adresstranslation mit entsprechendes Mapping sein.Wenn das Ding nichts Anderes macht, geht das auch in Hardware (kann ja stark optimiert werden; muß doch im Prinzip nur mod 3 [96Bit, 192bit] und vielleicht noch mod 5 [160bit, 320bit] oder mod 7 [224bit, 448bit] können, je nachdem, wie flexibel man sein will). Das kostet im Vergleich zu den Stromkosten des Speicherzugriffs quasi kaum etwas. Und es gibt durchaus auch auch andere Ansätze (https://patents.google.com/patent/US20150095595).
Ganz krude wäre auch eine kleine Lookuptable für z.B. mod 3 von 8 Bits der Adresse (die über die Kanalzuordnung entscheiden), wo dann aber nur für 85*3=255 der 256 Einträge ein gültiger mod3 Eintrag hinterlegt ist und es dann einfach kleine Löcher im physischen Adressraum gibt (alle Adressen mit 11111111b an der Stelle wären dann schlicht nicht gültig). Dadurch verliert man 1/256 des installierten Speichers, bei 12GB wären also 48MB nicht nutzbar wegen dieser Löcher. Das ist vermutlich verkraftbar. Für modulo 5 ergeben die gleichen 255/256 gültigen Einträge ebenfalls 1/256 des installierten Speichers Verschwendung (40MB bei einer 10GB-Karte). Das muß man dann bei der Adressierung wieder entsprechend kompensieren, wenn man mit weiterhin mit linearen Adressen [ohne die Lücken beim physischen Zugriff] arbeiten will, dafür reicht aber ein relativ schmaler Addierer [Größe des Adressraums -7bit bzw. 15bit, im Beispiel mit 128Byte Cachelines, 8Bit LUT und maximal 32GB reicht also ein ADD von 28bit+20bit+1bit bis 32GB; das Einzelbit ist eins, wenn die 8 Selektionsbits alle 1 sind sonst Null, das stellt also das Überspringen sicher; die andere Addition passiert vor dem Lookup, die vorderen 20bit der Adresse werden entsprechend ausgerichtet einfach auf die vorderen 28bit der Adresse addiert, da dies aussagt, wie oft ich schon über die Lücke gesprungen bin; Gesamtablauf ist also 20+28Bit Addition => 8bit Lookup => 1 bit Addition mit Carry falls letzter Eintrag der LUT getroffen wird]).
Das völlig auf die Adresstranslation Tables abzuwälzen, ist vermutlich schwieriger (insbesondere bei den alten GPUs mit krummen Speicherinterfaces, wo es das noch gar nicht in dem Umfang wie heute gab). Zudem wäre die Aufteilung dann maximal an Pagegrenzen möglich, nicht aber an Cachelinegrenzen (oder man benötigt extrem große Tabellen).

mksn7

2022-07-20, 18:19:08

Bei Fermi und Kepler hat L2 32 Byte Cacheline, also das was ein Kanal bei einem Zugriff liefert.

Die request granularity zwischen L1-L2 und L2-DRAM bei den neueren NVIDIA Architekturen ist auch weiterhin üblicherweise 32B (außer bei den GDDR6X Karten, da werden 64B aus dem DRAM geladen? Bin mir nicht sicher). L1 und L2 cache lines sind 128B lang, können aber in 32B sektoren verwaltet werden, so dass nur die benötigten Teile einer cache line geladen werden müssen. Belegt werden aber trotzdem 128B.

amdfanuwe

2022-07-20, 18:48:47

Wenn das Ding nichts Anderes macht, ... Zudem wäre die Aufteilung dann maximal an Pagegrenzen möglich, nicht aber an Cachelinegrenzen (oder man benötigt extrem große Tabellen).
Na, da bleiben keine nicht nutzbare Lücken im Speicher und große Tabellen sind auch nicht nötig.

Für 10 GByte Speicher braucht es 5 Speicherchips a 2 GByte.

Für 2 GByte brauchen wir 31 Adressleitungen, die an den Chips angelegt werden.
Für 10 GByte braucht es 34 Adressbits wobei die oberen 3 Bit nicht komplett genutzt werden.
Fürs Interleaving auf Cache Line Size nimmt man dann A9, A8 und A7 bei 128Bit Cache Line A0 bis A6.
Also nur eine Tabelle für 6 Bit ( A7, A8, A9, A32, A33, A34) = 64 Zeilen nötig.
Die anderen Adressbits werden direkt angelegt.

Bleiben wir bei dem Fazit, dass die GPU Hersteller ihre effizienten Methoden haben um die Channels auf die Speicherchips zu verteilen.

Gipsel

2022-07-20, 18:53:20

Für 10 GByte braucht es 34 Adressbits wobei die oberen 3 Bit nicht komplett genutzt werden.
Fürs Interleaving auf Cache Line Size nimmt man dann A9, A8 und A7 bei 128Bit Cache Line A0 bis A6.
Also nur eine Tabelle für 6 Bit ( A7, A8, A9, A32, A33, A34) = 64 Zeilen nötig.
Die anderen Adressbits werden direkt angelegt. Da sind die Zugriffe dann aber nicht gleichverteilt. Du mußt aber gerade sicherstellen, daß die genutzten Adressbits "zufällig" (oder zumindest gleichverteilt) sind, damit die Kanäle gleichmäßig ausgelastet werden. Deswegen eignen sich die high order bits der Adresse dafür normalerweise nicht. Effektiv hast Du bei Deinem Vorschlag in vielen Fällen nur eine 3Bit LUT (A7 bis A9 für 8 genutzte Einträge), die sich schwerlich gleichmäßig auf 5 (oder 10) Kanäle aufteilen läßt.

Iscaran

2022-07-20, 22:24:03

GCD von N31 ist bei 350+mm²
gesamter Chip ergo bei ~590mm² (ohne extra 3DVC), mit extra 3DVC grob ~710mm²
https://www.3dcenter.org/news/news-des-19-juli-2022

Wenn ich mal 1+1 zusammenzähle dann ergibt die Info nicht wirklich Sinn.

Wenn also N21 "GCD-only" ~375 mm^2 hat (bei 5120 SP) und in N7 gefertigt ist.

N5 bringt gegenüber N7 ca 1.84x Zuwachs in Packdichte (https://en.wikichip.org/wiki/5_nm_lithography_process#N5)

=> 375mm^2/5120/1.84 = 0.0398mm^2 pro SP.
Bei angegebenen ~350mm^2 für den RDNA3 => 350/0.0398 = 8.793 SPs

=> 375 mm^2 passt wohl eher zu N32 (Gerüchtete 8192 SPs) und nicht zu N31.

Ich kann mir nicht vorstellen dass AMD hier ZUSÄTZLICH zum Prozess noch Wege findet die Shader um + 50% Dichter zu packen (12.288 SPs).

EDIT: Nur mal den Prozessfortgang mit Shrinkfaktor 1.84x auf 12.288 SPs angewendet ergäbe eine GCD-Size von ~490 mm^2 + 6*40mm^2 für 6 MCDs = 730 mm^2 für N31 und 590 mm^2 für N32 demnach.

basix

2022-07-20, 22:39:17

Ich kann mir nicht vorstellen dass AMD hier ZUSÄTZLICH zum Prozess noch Wege findet die Shader um + 50% Dichter zu packen (12.288 SPs).

- Wegfall der Legacy Geometry Pipeline
- 2x FP32 pro CU (https://www.neowin.net/news/amd-rdna-3-rx-7000-gpus-could-have-up-to-double-the-ipc-compared-to-rdna-2-rx-6000/) (siehe Ampere)
- und noch ein paar weitere Sachen aus den Treibereinträgen

Vor allem 2x FP32 pro CU (was mit SPs gleichgesetzt werden kann in dieser Rechnung) wird FLOPS/Area massiv steigern, war bei Ampere ja auch so. Ist nur die Frage, ob die IPC/FLOP degradiert oder nicht.

Eine 3090 hat 3.2x FLOPS/mm2 verglichen mit einer 2080 Ti. 1.84*1.5 = 2.8x < 3.2x --> Da hast du deine zusätzlichen +50% Dichte von RDNA3 ;)

350mm2 sind aber schon ein wenig klein. ~600mm2 für die gesamte GPU, was evtl. sogar kleiner ist als der monolithische AD102. Kommt dann bei dem Duell also auf Perf/mm2 an ;) AMD müsste hier ~1.33x mehr Performance pro mm2 oder auch SP als AD102 rauspressen, um auf einen Gleichstand zu kommen. Entweder mit Takt oder IPC. So unrealistisch ist das nicht, wenn Ada keinen grösseren IPC Sprung hinlegt (wonach es anhand der letzten Gerüchte nicht aussieht).

Iscaran

2022-07-20, 22:45:06

- Wegfall der Legacy Geometry Pipeline
- 2x FP32 pro CU (https://www.neowin.net/news/amd-rdna-3-rx-7000-gpus-could-have-up-to-double-the-ipc-compared-to-rdna-2-rx-6000/) (siehe Ampere)
- und noch ein paar weitere Sachen aus den Treibereinträgen

Vor allem 2x FP32 pro CU (was mit SPs gleichgesetzt werden kann in dieser Rechnung) wird FLOPS/Area massiv steigern, war bei Ampere ja auch so. Ist nur die Frage, ob die IPC degradiert oder nicht. Eine 3090 hat 3.2x FLOPS/mm2 verglichen mit einer 2080 Ti.

Ja aber auch die 2x FP32 pro CU gibts nicht für "umsonst" bei gleicher CU Größe. Das meinte ich damit eher.

Auf die 1.84x Verbesserung der PRozesspackdichte müsste AMD nochmal fast +50% Verbesserung in Packdichte durch, weglassen von Dingen oder cleveres Lösen von Dingen was vorher 3 Transistoren gebraucht hat mir nur 2 zu erledigen.

Kann ICH mir nicht vorstellen. Es ist nach Okham für mich plausibler hier erstmal N32 zu vermuten.

EDIT: Die hier beschriebenen Fortschritte beziehen sich aber auf IPC. Wäre es so wie Neowin schreibt, hätte der 350 mm^2 Die dann zwar "nur" 8192 SPs, aber mit der Performance von 16.384.
(Wenn der Schritt von 1 Command / cycle => 1 Command /0.5cycles) so kommt wie Neowin das darstellt.

Damit passen die Kolportierten SPs (12.228) und Die-Size (350 mm^2) immer noch nicht für N31.

basix

2022-07-20, 22:52:53

Wie gesagt ist das beste Beispiel Ampere: Deutlich erhöhte Anzahl der FP32-Units, ohne den ganzen Rest des SMs im selben Masse mitzuskalieren. 2.6x FLOPS bei 1.5x Transistoren (3090 vs. 2080 Ti).

Ich vermute, das wird bei RDNA3 ähnlich aussehen.

Edit:
Die These von Neowin mit 1 cmd /0.5clk ist mMn Schwachsinn. Ich interpretiere das eher so, dass eine RDNA3 CU neu 2x wave64 pro Takt ausführen kann. Bei RDNA1/2 war das noch 2x wave32 pro Takt. Wieso ich darauf komme? Gab hier im Thread die Diskussion zu VOPD Befehlen (in meinem Verständnis "Dual-Issue" wave32, mit aber nur 1x Instruktion). VOPD = 2x wave32 = ~1x wave64, was sich mit dem vergrösserten CU decken würde. Das geht nicht mit allen Instruktionen aber allem Anschein an reicht der Vorteil aus, um das CU entsprechend umzubauen.
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13044597#post13044597
https://br.atsit.in/de/?p=249774

https://cdn.neow.in/news/images/uploaded/2022/04/1651297917_rdna_3_simd_(source-_kepler_l2_twitter).jpghttps://cdn.neow.in/news/images/uploaded/2022/04/1651297776_gcn_vs_rdna_simd_ipc.jpg

In diesem Sinne kann man mit VOPD im Idealfall 2x FP32 mit ~ähnlichen Scheduler Ressourcen bedienen. Somit gesteigere Rohleistung bei sub-proportional ansteigendem Transistorbedarf für das CU. Die grosse Gretchenfrage: Wie sieht es mit der IPC aus? Ampere hat hier pro FLOP deutlich weniger Performance auf die Strasse gebracht als Turing (als Limitation der Architektur). Irgendwie so könnte es kommen:
- wave32 only --> RDNA3 kann nur 50% der theoretischen Rohleistung auf den Boden bringen
- wave64 only --> RDNA3 kann theoretisch 100% der Rohleistung auf den Boden bringen
- Mix aus wave64 und wave32 --> Solange genug wave32 VOPD Befehle gebündelt werden können, kann RDNA3 theoretisch 100% der Rohleistung auf den Boden bringen. Alle nicht "VOPDbaren" Befehle sollten als wave64 ausgeführt werden.

RDNA3 CU Scheduling Möglichkeiten:
- 2x wave32
- 2x wave64
- 1x wave64 + 1x VOPD (2x wave32)
- 2x VOPD (2 mal 2x wave32)

Wie bei RDNA1/2 bleibt es bei 2 Scheduling Ports/Pipelines pro CU, aber mit im Idealfall doppeltem Durchsatz. Zudem erreicht man den Vorteil, dass bei wave64 beide Scheduling Pipelines genutzt werden können. Bei RDNA1/2 lag nach meinem Verständnis in diesem Fall eine der zwei Scheduler-Ports ungenutzt. Nachteil hier ist halt, dass man mit wave32 only die CUs nicht ausgelastet bekommt. Deswegen das Zusammenfassen von wave32 via VOPD. Und solange man genug von diesen hat sollte die IPC hoch bleiben.

4x wave32 pro CU wäre natürlich noch besser, würde aber die Scheduler-Ressourcen wieder aufblähen. Deswegen eben diese VOPD Instruktionen.

amdfanuwe

2022-07-20, 23:16:41

Da sind die Zugriffe dann aber nicht gleichverteilt. Du mußt aber gerade sicherstellen, daß die genutzten Adressbits "zufällig" (oder zumindest gleichverteilt) sind, damit die Kanäle gleichmäßig ausgelastet werden. Deswegen eignen sich die high order bits der Adresse dafür normalerweise nicht. Effektiv hast Du bei Deinem Vorschlag in vielen Fällen nur eine 3Bit LUT (A7 bis A9 für 8 genutzte Einträge), die sich schwerlich gleichmäßig auf 5 (oder 10) Kanäle aufteilen läßt.
Nein.
Es werden ja nicht die High Order Bits verwendet sondern A7 bis A9, je nach Cache Line Size.
Für 5 Kanäle braucht es 40 ( 5*8) Einträge. Ließe sich sogar mit ein paar Logikgattern erledigen, mit einer LUT ist man aber flexibler für salvage Konfigurationen.
Hab mal versucht das zu visualisieren. Links die von der GPU gelieferten Adressen, der rote Bereich wird bei 10GB nicht adressiert.
Rechts die LUT Einträge. Kann man ja nach belieben verwürfeln. Die Lücken im Virtuellem Adressraum werden mit den Virtuellen Adressen aus dem 10-16GB Bereich aufgefüllt.

Gipsel

2022-07-21, 07:53:49

Nein.
Es werden ja nicht die High Order Bits verwendet sondern A7 bis A9, je nach Cache Line Size.
Für 5 Kanäle braucht es 40 ( 5*8) Einträge. Ließe sich sogar mit ein paar Logikgattern erledigen, mit einer LUT ist man aber flexibler für salvage Konfigurationen.
Hab mal versucht das zu visualisieren. Links die von der GPU gelieferten Adressen, der rote Bereich wird bei 10GB nicht adressiert.
Rechts die LUT Einträge. Kann man ja nach belieben verwürfeln. Die Lücken im Virtuellem Adressraum werden mit den Virtuellen Adressen aus dem 10-16GB Bereich aufgefüllt.Das funktioniert so aber nicht.
Wenn ich aus Deiner Tabelle einfach mal ablese, in welchen Speicherkanal/Chip (CS) die Speicherzugriffe auf einen kontinuierlichen Block (virtueller Adressen) gehen, kommt das raus (weil sich die höherwertigen Adressbits innerhalb einer Page ja nicht ändern):
1,2,3,4,5
1,1,1
1,2,3,4,5
1,1,1
[...]

Irgendwo in einer anderen Page (also mindestens 64kB weg), würden die wiederholten Zugriffe auf Kanal 1 (je nach konkreter Adresse) wiederholte Zugriffe auf Kanal 2, 3, 4, oder 5 sein.
Das sieht mir nicht so optimal aus (man kann die Tabelle zwar noch etwas besser machen, aber nicht wirklich gut). Am Ende des Tages hast Du pro Page nur eine 3 bit-Tabelle, die sich eben nicht gut auf 5 Kanäle mappen läßt.

Die unteren Adress-Bits innerhalb der Page Size werden von der Address Translation nicht angefaßt (die virtuellen Adressen entsprechen da also den physischen). Deswegen geht per Pagetable nur Interleaving auf Pageebene, nicht Cacheline-Ebene.

Aber was Du machen könntest, ist das Interleaving-Muster per Page zu ändern ;). Du nimmst Dir einfach die 2 niedrigwertigsten Bits der Adresse oberhalb der Cacheline (A7, A8) und machst Interleaving zwischen nur 4 von 5 Kanälen (wir waren ja bei einem Beispiel mit 10GB an z.B. 160Bit Interface). Welche 4 das sind, permutierst Du aber auf Pagebene (also z.B. alle 64kB). Bei der Adresstranslation selektiert man also auch (auf Pageebene) welcher der 5 Kanäle jeweils weggelassen wird.
Das ist dann kein "perfektes" Interleaving, sollte aber zumindest gut genug funktionieren. Da muß man aber zwar auch noch halbwegs clever sein, wie man das genau macht, das halte ich aber für lösbar.

Zossel

2022-07-21, 08:17:01

Das funktioniert so aber nicht.
Wenn ich aus Deiner Tabelle einfach mal ablese, in welchen Speicherkanal/Chip (CS) die Speicherzugriffe auf einen kontinuierlichen Block (virtueller Adressen) gehen, kommt das raus (weil sich die höherwertigen Adressbits innerhalb einer Page ja nicht ändern):

Heutige GPUs haben doch sowieso eine MMU, warum nicht diese dafür nutzen?

amdfanuwe

2022-07-21, 10:19:02

Heutige GPUs haben doch sowieso eine MMU, warum nicht diese dafür nutzen?
Weil die MMU keine CS erzeugt und nur mit großen Blöcken hantiert.

Das funktioniert so aber nicht.
Wenn ich aus Deiner Tabelle einfach mal ablese, in welchen Speicherkanal/Chip (CS) die Speicherzugriffe auf einen kontinuierlichen Block (virtueller Adressen) gehen, kommt das raus (weil sich die höherwertigen Adressbits innerhalb einer Page ja nicht ändern):
1,2,3,4,5
1,1,1
1,2,3,4,5
1,1,1
[...]

Ist eine Lut.
Hab sie Einträge im Bild mal optimiert.
Jetzt wird bei einem Blockzugriff alle 128 Byte auf einen anderen Chip zugegriffen. Bei gewünschter anderer Byte Anzahl nimmt man statt A7-A9 entsprechend andere Adressbits.
Sieht jetzt auch gleichverteilt aus, ohne Lücken.
Die erste Lösung war bedingt durch meinen Ansatz das mit ein paar Logikgattern zu generieren. Mit der Lut sind wir flexibler und kostet auch nichts extra außer ein paar mehr Transistoren.
Und es bleibt bei einer 6 Bit Tabelle. 3 Bit für Phys RA28-RA30 am Chip und 3 Bits für CS Auswahl.
Für die nötigen 40 Zustände sind 6 bit notwendig.

Für 12 GB sieht es mit 48 Zuständen ähnlich aus.

mboeller

2022-07-21, 11:12:42

GCD von N31 ist bei 350+mm²
gesamter Chip ergo bei ~590mm² (ohne extra 3DVC), mit extra 3DVC grob ~710mm²
https://www.3dcenter.org/news/news-des-19-juli-2022

IMHO eigentlich unglaubwürdig, vor allem dann für die kleineren Versionen.

N32: in etwa 250mm² + 4x40mm² = 410mm²
N33: in etwa 150mm² + 2x40mm² = 230mm²

StefAlb

2022-07-21, 11:42:27

Iscaran

2022-07-21, 12:09:09

Wie gesagt ist das beste Beispiel Ampere: Deutlich erhöhte Anzahl der FP32-Units, ohne den ganzen Rest des SMs im selben Masse mitzuskalieren. 2.6x FLOPS bei 1.5x Transistoren (3090 vs. 2080 Ti).

Ich vermute, das wird bei RDNA3 ähnlich aussehen.

OK - wenn ich dein Konzept richtig versteht, implizierst du dass AMD hier einfach die IPC um +50% anheben kann - aber auch dann passen einfach die Chipgröße und gemeldete CU/SP Zahlen nicht wirklich zueinander

5120 SPs bei RDNA2 haben angeblich ~ 375 mm^2
=> 0.07324...mm^2 / SP

Der Prozessfortschritt erlaubt eine erhöhung der Packdichte um 1.84x
=> 0.07324 .../1.84 = 0.0398...mm^2 / SP

Weiter heisst es ANGEBLICH sind N31=12228, N32=8192 bzw. N33=4096 SPs verbaut

=> Variante 1: Die SPs skalieren mit dem Prozessgain von 7nm auf 5nm
ergibt dann als Werte NUR für die GCD-Größen:
=> 0.0398...*12228 = 487 mm^2
=> 0.0398...*8192 = 326 mm^2
=> 0.0398...*4096 = 163 mm^2

Dazu noch 6x40 mm^2 MCD bzw. 4x40 bzw 2x40
Also:
N31 = 487 + 240 mm^2 = 727 mm^2
N32 = 326 + 160 = 486 mm^2
N33 = 163 + 80 = 243 mm^2

ALTERNATIVE Variante 2. AMD hat wie du schreibst Wege gefunden die IPC zu erhöhen.

=> Die Zahl der SPs stimmt nicht (diese "ergab" sich durch die IPC-Dopplung)

=> 12.228 sind eigentlich nur 6144 SPs, 8192 sind de facto nur 4096 SPs aber mit doppeltem Durchsatz und 4096 sind nur 2048.

Mit Prozess-Shrink also dann
N31: 0.0398...*6144 = 243 mm^2 GCD + 240 mm^2 MCD = 483 mm^2
N32: 0.0398...*4096 = 163 mm^2 GCD + 160 mm^2 MCD = 323 mm^2
N33: 0.0398...*2048 = 82mm^2 GCD + 80 mm^2 MCD = 162 mm^2

Wenn also AMD irgendwie den Durchsatz pro SP verdoppelt hat, würden 6144 SPs mit ~480 mm^2 hinkommen.

DANN hätte aber das GCD only nur ~243 mm^2
analog die anderen Chips.

Das alles passt nicht, oder nur mit nahezu absurden Annahmen zu einer WEITEREN Steigerung der IPC durch AMD von +100%.

Selbst wenn ich mal Variante 3 rechne "nur +50%" IPC.

Aus 12.228 SPs werden so 8192
aus 8192 => 5461
aus 4096 => 2731

Für N31 erhält man da ja noch sinnvolle Zahlen, aber die anderen sind dann total merkwürdig.

Ich bleibe dabei - die ~350mm^2 GCD-Die-Size ist für N32 angegeben und eben nicht für N31 oder N33.

Oder die 350mm2 beziehen sich WIRKLICH auf den Gesamten Chip (inkl. MCDs) und AMD zaubert hier nochmal +100% IPC hin.

Linmoum

2022-07-21, 12:25:04

Du machst aber erst einmal schon den Fehler, dass du nur den IF$ und Speichercontroller rausrechnest. Da fehlen aber noch XGMI, GDS, Legacy Geometrie Pipeline und Legacy Scan Converter, für die AMD bei RDNA3 wohl den Rotstift angesetzt hat.

Keine Ahnung, ob es dazu verlässliche Größenordnungen für gibt, aber das beschränkt sich sicherlich nicht nur auf ein paar mm² Einsparung.

mboeller

2022-07-21, 12:52:01

Ich bin mal auf die ersten "Vortests" gespannt, so wie aktuell es schon kompllett inoffizielle von der 4090 gibt.

Je besser der Navi 31 wird um so günstiger dürften auch die NVIDIA Karten werden. (Hoffe ich jedenfalls)

da die N31 Karten 5% langsamer werden als die 4090-Karten darfst du den vollen Preis bezahlen. :biggrin:

mboeller

2022-07-21, 13:47:45

Weiter heisst es ANGEBLICH sind N31=12228, N32=8192 bzw. N33=4096 SPs verbaut

=> Variante 1: Die SPs skalieren mit dem Prozessgain von 7nm auf 5nm
ergibt dann als Werte NUR für die GCD-Größen:
=> 0.0398...*12228 = 487 mm^2
=> 0.0398...*8192 = 326 mm^2
=> 0.0398...*4096 = 163 mm^2

Du gehst davon aus, das 1 WGP mit 4CU genau doppelt so groß ist wie ein WGP mit 2 CU.

N21 hat 80 WGP mit 5120 CU
N31 hat, laut Gerüchten 96 WGP mit 12288 CU

Iscaran

2022-07-21, 14:00:45

Du gehst davon aus, das 1 WGP mit 4CU genau doppelt so groß ist wie ein WGP mit 2 CU.

N21 hat 80 WGP mit 5120 CU
N31 hat, laut Gerüchten 96 WGP mit 12288 CU

WGP ist erstmal wurscht, ich hab mich rein auf die SPs bezogen.

Wenn aber 96 "WGP" 12288 SPs entsprechen, dann hat nun 1 CU nun 4 SP

Das deutet eigentlich tatsächlich genau auf das hin was basix andeutet...der Durchsatz pro realem CU ist 2x so hoch.

Das wäre dann Variante 2, allerdings passen die Größen halt nicht irgendwie.

Gipsel

2022-07-21, 14:48:30

Heutige GPUs haben doch sowieso eine MMU, warum nicht diese dafür nutzen?Weil die auch nur auf Page-Ebene funktioniert. ;)

Gipsel

2022-07-21, 14:58:56

Ist eine Lut.
Hab sie Einträge im Bild mal optimiert.
Jetzt wird bei einem Blockzugriff alle 128 Byte auf einen anderen Chip zugegriffen. Bei gewünschter anderer Byte Anzahl nimmt man statt A7-A9 entsprechend andere Adressbits.Dummerweise wiederholen sich innerhalb einer Page aber A7, A8 und A9 alle 8 Cachelines, während A31, A32 und A33 konstant sind. Du hast da also ein Interleaving Muster von 8 Einträgen über 5 Kanäle. Das funktioniert also immer noch nicht. 5 ist schlicht teilerfremd zu den Zweierpotenzen und Du hast effektiv innerhalb einer Page immer nur eine 3 bit LUT.
Bei der neunten Cacheline einer Page landet man also wieder beim allersten 0,0,0 Eintrag für A7-A9, mappt also in der Realität wieder auf Kanal 1. Die Abfolge wäre also bei Deiner zweiten Tabelle:
1,2,3,4,5,
1,2,3
1,2,3,4,5,
1,2,3
[..]

Wie gesagt konnte man Deine erste Tabelle noch etwas optimieren, wirklich gut wird es aber nie.

Die Idee, auf Pagetable-Ebene ein paar high-order bits reinzumixen ist ja im Prinzip okay. Aber dann sollte man eher wie von mir beschrieben innerhalb einer Page wieder ein Interleaving-Pattern in Zweierpotenzen nehmen (am einfachsten einfach 2 bits bei 5 Kanälen und einen Kanal weglassen) und zwischen den Pages dann diese 2 bit LUTs permutieren (also welcher Kanal jeweils weggelassen wird). Das ist dann noch etwas einfacher (und läuft im Endeffekt performancetechnisch auf Deinen zweiten Vorschlag hinaus). Aber wie gesagt ist das kein "perfektes" Cacheline-Interleaving, sondern man überspringt eben immer mal einen Kanal (oder zwei in Deinem Beispiel), was man dann auf Pageebene ausgleicht.

Am Ende wird es sowieso darauf hinauslaufen, daß man eher in die Richtung zu der Speicheranforderung wie bei CPUs kommt (zwar immer noch bandbreitenoptimiert, aber nicht ganz so extrem). Man ist bei GPUs normalerweise zwar nicht soo latenzsensitiv. Aber bei immer breiter werdenden GPUs und mehreren concurrent laufenden Shadern, wird es durchaus attraktiv, kein vollständiges Cacheline-Interleaving mehr zu haben. Wenn man z.B. immer nur Cacheline-Interleaving innerhalb von 64bit-Interface-Blöcken macht (4 Kanäle bei GDDR6), den Rest dann aber unabhängig davon betreibt (wie bei CPUs), dann hat man das Thema praktisch sowieso schon erschlagen (zumindest für 64bit-Abstufungen der Speicherinterfacebreite). Eine Page würde dann immer vollständig in einem 64bit Segment des Interfaces liegen (maximale Bandbreite dahin dann 160GB/s bei 20GT/s GDDR6). Dies sollte angesichts der immer größeren Caches und Auflösungen (und damit größeren Anzahl an Pages, auf die parallel zugegriffen wird und der durch größere Caches normalerweise verursachten etwas zufälligeren Natur der Speicherzugriffe [tendentiell etwas weniger Streaming, wo es auf maximale Bandbreite ankommt]) perspektivisch das Mittel der Wahl sein. Würde mich nicht wundern, wenn das zumindest bei RDNA3 schon so läuft (vereinfacht eventuell auch die Modularität der MCDs), eventuell auch schon bei RDNA2 (hat immerhin sehr große Caches eingeführt, konkrete Informationen zur genauen Funktionsweise des Speichermappings muß man aber mit der Lupe suchen, die typischen Manuals schweigen sich dazu aus).

amdfanuwe

2022-07-21, 16:09:10

Dummerweise wiederholen sich innerhalb einer Page
Da reden wir aneinander vorbei bzw. verstehe ich dein Problem mit den Pages nicht.
Mir ging es erstmal darum einen Weg zu finden die Ramchips interleaved anzusteuern, damit nicht der 1te Kanal 0-2GB, der 2te 2-4GB etc. bedient.
Die GPU fordert Daten von einer Adresse an und bekommt diese geliefert. Bei zugriffen über einen größeren Datensatz können alle Kanäle gleichzeitig arbeiten.

Den 2k ... 64k Pages kann es doch egal sein, wo die Daten im Ram liegen.
Die braucht man doch nur, damit jeder Thread ab virtuell Adresse 0 seine Daten findet.

Kannst natürlich auch eine Page auf einen Kanal pinnen, verwendest halt statt A7-A9 dann A11-A13 für 2k Blöcke. Ist nur langsamer da die Daten dann nicht mehr über mehrere Kanäle gelesen werden können.

Wegen A31-A33, die braucht man, da ja nur bis 10GByte adressiert wird.
Und es ist ja klar, dass A7-A9 und A30-A33 gar nicht mehr an die Ramchips angelegt werden.

Zossel

2022-07-21, 16:21:46

Die braucht man doch nur, damit jeder Thread ab virtuell Adresse 0 seine Daten findet.

Die Adresse 0 willst du ganz bestimmt nicht haben und man will auch immer einen Page-Fault bekommen wenn man auf Adresse 0 zugreift.

Neurosphere

2022-07-21, 17:16:59

Zugegebenermaßen kann ich eurer Rechnerei nicht folgen. Frage mich aber ob man den kleinen und reduzierten Chip nicht wirklich deutlich höher Takten kann als Navi 21.

amdfanuwe

2022-07-21, 17:20:14

Die Adresse 0 willst du ganz bestimmt nicht haben und man will auch immer einen Page-Fault bekommen wenn man auf Adresse 0 zugreift.
Deshalb das Wörtchen "virtuell" vor Adresse 0.

amdfanuwe

2022-07-21, 17:23:59

Zugegebenermaßen kann ich eurer Rechnerei nicht folgen. Frage mich aber ob man den kleinen und reduzierten Chip nicht wirklich deutlich höher Takten kann als Navi 21.
Macht nicht, kann auch vielen Themen nicht folgen.
Zum Takt kann ich nur sagen, dass allein durch 5 nm höhere Takte möglich sein sollten. Damit endet meine Weisheit in dem Bereich.

Zossel

2022-07-21, 17:49:17

Deshalb das Wörtchen "virtuell" vor Adresse 0.

Du willst auch keine virtuelle Adresse 0.

Irgendwelche PA-Risc Kisten aus den 90'ern haben einem Zugriff auf Adresse 0 nicht mit einem Page-Fault quittiert, absolut widerlich.

Gipsel

2022-07-21, 17:53:19

Da reden wir aneinander vorbei bzw. verstehe ich dein Problem mit den Pages nicht.Die Frage war, wie man am besten das Speicherinterleaving handhabt, speziell mit welcher Methode man die linear im Speicher hintereinander liegenden Cachelines (also den Adressraum auf Cachelineebene) gleichmäßig zwischen den RAM-Channels interleaven kann (um die maximale Bandbreite nutzen zu können).
Für eine Zweierpotenz an RAM-Channels ist das trivial (man nehme eine Anzahl an Bits die alle Kanäle numeriert werden können [2 Bits für 4 Kanäle, 3 Bits für 8 Kanäle usw.] direkt oberhalb der Bits für Adressen innerhalb der Cachelines und das ergibt direkt die Speicherkanalnummer [diese Bits werden bei Adressierung der Speicherchips dann schlicht rausgeschnitten]). Super easy.
Beispiel 4 Kanäle, linear ansteigende Adressen gehen dann auf Kanäle 1,2,3,4,1,2,3,4,1,2,3,4,...
Für "krumme" Breiten des Speicherinterfaces geht das dann nicht mehr ganz so einfach und Dein Vorschlag liefert für krumme Interfaces kein in diesem Sinne optimales Interleaving-Muster (es ist nicht gleichverteilt sondern in bestimmten Speicherbereichen werden bestimmte Kanäle mehr belastet, in anderen Speicherbereichen entsprechend andere). Ohne einen Divider geht das auch nicht wirklich komplett lückenlos. Eine Idee ist deshalb, das z.B. an den Pagegrenzen jeweils zu durchbrechen und das Interleaving-Muster zwischen den Pages zu permutieren (ist aber nicht wirklich nötig, das an den Pagegrenzen zu machen, das kann quasi auch in Hardware transparent für die Address Translation erfolgen [je größer die Blöcke mit konstanten Interleaving-Muster, desto geringer der Aufwand dafür, aber desto schlechter die Performance [zumindest prinzipiell, wieviel das praktisch ist, keine Ahnung], weswegen es auch nicht auszuschließen ist, daß man einen Modulo/Divider mit festem Divisor 3, 5 oder was auch immer da reinpackt; das ist schon noch überschaubar vom Aufwand). Innerhalb einer Page (oder Speicheradressbereich mit festem Interleaving-Pattern) kann dann zwar nicht die volle Bandbreite erreicht werden, aber mit der fortschreitenden GPU-Evolution wird das auch immer weniger wichtig. Bei CPUs hatten wir den Punkt wie gesagt vor 12 Jahren oder so, seit dem die Kanäle quasi unabhängig betrieben werden (und nicht mehr interleaved auf Cacheline-Level [wer erinnert sich noch an "ganged" und "unganged" beim K10? Das war der Switch]).
Mein Vorschlag für die Zukunft [vermutlich wird das bereits jetzt in GPUs aktuell bzw. z.B. bereits jetzt in RDNA2 verbaut] wäre jetzt, daß man aus den beschriebenen Gründen ähnlich wie bei CPUs z.B. 64Bit-Segmente des Speicherinterfaces dafür nimmt und Cacheline-Interleaving nur noch innerhalb dieser Segmente des Speicherinterfaces macht (also nur noch über jeweils 4 GDDR6-Kanäle und nicht über das komplette Interface).

amdfanuwe

2022-07-21, 18:45:38

Die Frage war, wie man am besten das Speicherinterleaving handhabt, speziell mit welcher Methode man die linear im Speicher hintereinander liegenden Cachelines (also den Adressraum auf Cachelineebene) gleichmäßig zwischen den RAM-Channels interleaven kann (um die maximale Bandbreite nutzen zu können).
Ich denke, du verrennst dich da in etwas.
Belassen wir es dabei.

iamthebear

2022-07-21, 18:47:23

Also grob geschätzt besteht Navi21 aus:
160mm² WGPs (40x4mm²)
140mm² sonstige Teile, die mit der Anzahl an WGPs skalieren
80mm² IC
60mm² SI
15mm² L2 (skalierte bei RDNA2 mit SI)
30mm² PCIe (skaliert mit PCIe Lanes)
35mm² Rest (Display, Media Engine etc.)

Wenn wir davon ausgehen, dass bei der Verdopplung der FP32 Einheiten die WGPs um 50% anwachsen wären das bei Navi31 in 7nm:

GCD:
160*1.2*1.5 WGP
140 * 1.2 skalierender Teil
15 L2
30 PCIe
35 Rest
Gesamt: 536mm²

MCD:
80*1.5 IC (bei 192MB)
60*1.5 SI
Gesamt: 6*35=210mm²

Wenn wir den GCD auf 5nm shrinken unter der Annahme dass Logic 1.7x shrinked und der Rest nicht:
456/1.7 = 270mm² Logic
80mm² Rest
Gesamt: 350mm²

Wenn man davon ausgeht, dass sich die Größe der WGPs durch die Erhöhung der FP32 Anzahl verdoppelt landen wir bei 400mm².

Ich denke wir werden also irgendwo zwischen 350 und 400mm² landen.

Gipsel

2022-07-21, 19:44:53

Ich denke, du verrennst dich da in etwas.
Belassen wir es dabei.Für die Prämissen reicht ein Blick zurück (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13061641#post13061641). Fakt bleibt: Dein Vorschlag erfüllt das nicht. Für die sich aus modernen/zukünftigen Anforderungen ergebenden Erwägungen für neuere Hardware bin ich später auch eingegangen.
Aber ich stimme zu: Wir müssen da wirklich nicht weiter drauf rumreiten.

basix

2022-07-21, 21:10:24

WGP ist erstmal wurscht, ich hab mich rein auf die SPs bezogen.

Wenn aber 96 "WGP" 12288 SPs entsprechen, dann hat nun 1 CU nun 4 SP

Das deutet eigentlich tatsächlich genau auf das hin was basix andeutet...der Durchsatz pro realem CU ist 2x so hoch.

Das wäre dann Variante 2, allerdings passen die Größen halt nicht irgendwie.

Bei SPs sind sich eigentlich "alle" langsam im konsens, dass 12288 SPs / FP32-Units für N31 gelten. Am Anfang auf 48WGP und 192CUs aufgeteilt, mittlerweile eher 48WGP und 96CUs. Und letzteres wären dann 128x FP32 pro CU, wie bei Amperes SMs.

N21 vs. N31:

WGP = 40 <-> 48
CU = 80 <-> 96
CU Area = 1.0 <-> 1.5 (estimate, siehe 2.6x TFLOPs @ 1.5x Transistoren GA102 vs. TU102)
N5 Scaling = 1.0 <-> 1.5 (estimate, whole Shader Array)

Anhand dem Beispiel kompensiert N5 die Flächensteigerung der CUs. Somit bleibt nur der WGP Anstieg übrig und die Shader Arrays von N31 wären 96/80=1.2x grösser als bei N21.

Turing vs. Ampere:

TPC = 10.9mm2 (https://www.reddit.com/r/nvidia/comments/baaqb0/rtx_adds_195mm2_per_tpc_tensors_125_rt_07/) <-> 8.7mm2 (https://semianalysis.substack.com/p/nvidia-ada-lovelace-leaked-specifications?s=r) --> 0.8x

Obwohl man bei Ampere die RT-Cores und Tensor-Cores aufgebohrt hat und dazu 2x FP32 Rohleistung pro SM implementiert hat, ist die Fläche pro TPC sogar gesunken! Transistor Density von GA102 vs. TU102 ist allerdings 1.83x, was über dem liegt was man von N5 vs. N7 erwarten kann. Für reine Logik könnten 1.8x schon hinkommen (was die CUs allerdings nicht sind). Wenn AMD also einen auf Ampere macht, scheint eine auf WGP bezogene flächenneutrale Verdopplung der FP32-Einheiten drinzuliegen. Im besten Fall wie bei Ampere sogar eine geringere Fläche. Das würde sich dann am ehesten mit den 350mm2 fürs GCD decken.

N21:

Total = 521mm2
xGMI = 10mm2
256bit = 60mm2
IO/Video/Display = 40mm2
IF$ =90mm2 https://pbs.twimg.com/media/E2q_tgBXoAE6X_b?format=jpg&name=large
Shader Arrays + Command Core + L2$ = ~320mm2

1.2x * 320 = 385mm2
1.0x * 320 = 320mm2
0.8x * 320 = 255mm2

Das ist ein ungenauer Wert (siehe Spread) und es kämen da noch IO/Video/Display und die Interfaces zu den MCDs dazu (und in den 320mm2 sind noch L2$ und Command Core enthalten). Nichtsdestotrotz sehe ich es als realistisch an, dass das GCD von N31 <400mm2 landet.

iamthebear

2022-07-21, 22:14:22

Bisher habe ich schon mindestens 3-4 komplett verschiedene Rechenansätze gesehen und alle landen sofern sie keine schweren Denkfehler haben zwischen 350 und 400mm². Also denke ich, dass das nicht so verkehrt sein kann.

Interessant ist es jedoch auch das Verhältnis von WGP Fläche zu IF$ und SI zu betrachten, die ja beide den Zweck der Speicheranbindung erfüllen.

Bei Navi21 waren wir ca. bei:
4x40=160mm² WGPs zu 80+60=140mm² für SI+IF$

Bei Navi31 mit der Annahme 1.5x WGP Wachstum bei 1.5x Shrink und 40mm² per MCD:
4*48= 192mm² WGPs zu 6*40=240mm²

Es hat die Speicheranbindung also die WGPs überholt und das trotz der FP32 Verdoppelung und ohne 3D Stacking.

Von der Seite aus betrachtet macht es durchaus Sinn, dass AMD eher die FP32 Leistung aufbohrt und die Speicherseite bewusst etwas mager gestaltet.

Nach ersten Daten wird der Trend der besser shrinkenden Logicteile auch bei 3nm weiter anhalten und ich bin mir nicht sicher ob GDDR7 hier alle Probleme lösen kann.

basix

2022-07-21, 22:35:16

Wie kommst du auf nur 4mm2 pro WGP?

Und die WGPs stellen ja nicht die komplette Shader Engine dar. Nur die WGPs zu nehmen ist da wohl nicht die ganze Wahrheit.

vinacis_vivids

2022-07-21, 22:37:06

Macht nicht, kann auch vielen Themen nicht folgen.
Zum Takt kann ich nur sagen, dass allein durch 5 nm höhere Takte möglich sein sollten. Damit endet meine Weisheit in dem Bereich.

Der Shrink auf 5nm ist nur ein Teil für höhere Taktrate. Allein der shrink erlaubt bei gleicher Fläche mehr Oberfläche für die Transistoren und somit mehr Transistoren.

Die Erhöhung der Transistoren und dickere DCU's (Dual Compute Units) machen den anderen Teil aus. Dicke Compute Units kann man länger mit mehr Energie versorgen und auch die Taktraten dauerhaft hoch halten.

Ein ganz anderer wesentlicher Teil ist der IF-CLK, welcher für die verfügbare Bandbreite verantwortlich ist. Dieser läuft mit einer anderen CLK-Domain, die ebenfalls u.a. vom Shrink profitiert.

Dann gibt es noch den VRAM-Takt, also vom Me-Controller und Speicherbausteine abhängig.

Im Allgemeinen ist höherer Takt gleichzeitig höhere Leistung. Nicht nur vom reinen fp32/fp16 output, sondern auch
die höhere discard-rate, also die Löschleistung.

Die letzte Methode der Taktraten-Erhöhung ist durch BruteForce, also die reine Erhöhung des Energiebudged durch eine höhere Energieaufnahme.

Interessant wird es auf jeden Fall wie AMD die 3,0Ghz oder auch 3,3-3,5 GHz GPU-CLK erreicht. Damit ist AMD absoluter Weltmeister.

Auf der Bauteilebene ist die verwendete Kühlkonstruktion noch interessant für den Takt.

Leonidas

2022-07-22, 03:26:20

Quelle:
https://twitter.com/_wildc/status/1550143106573549576

https://pbs.twimg.com/media/FYM2hopWYAALi1U?format=jpg

Gott1337

2022-07-22, 04:11:34

Der Shrink auf 5nm ist nur ein Teil für höhere Taktrate. Allein der shrink erlaubt bei gleicher Fläche mehr Oberfläche für die Transistoren und somit mehr Transistoren.

Die Erhöhung der Transistoren und dickere DCU's (Dual Compute Units) machen den anderen Teil aus. Dicke Compute Units kann man länger mit mehr Energie versorgen und auch die Taktraten dauerhaft hoch halten.

Ein ganz anderer wesentlicher Teil ist der IF-CLK, welcher für die verfügbare Bandbreite verantwortlich ist. Dieser läuft mit einer anderen CLK-Domain, die ebenfalls u.a. vom Shrink profitiert.

Dann gibt es noch den VRAM-Takt, also vom Me-Controller und Speicherbausteine abhängig.

Im Allgemeinen ist höherer Takt gleichzeitig höhere Leistung. Nicht nur vom reinen fp32/fp16 output, sondern auch
die höhere discard-rate, also die Löschleistung.

Die letzte Methode der Taktraten-Erhöhung ist durch BruteForce, also die reine Erhöhung des Energiebudged durch eine höhere Energieaufnahme.

Interessant wird es auf jeden Fall wie AMD die 3,0Ghz oder auch 3,3-3,5 GHz GPU-CLK erreicht. Damit ist AMD absoluter Weltmeister.

Auf der Bauteilebene ist die verwendete Kühlkonstruktion noch interessant für den Takt.
Gehts hier um den Gewinner des Comedy Clubs? ;D

Zossel

2022-07-22, 08:17:26

Die Frage war, wie man am besten das Speicherinterleaving handhabt, speziell mit welcher Methode man die linear im Speicher hintereinander liegenden Cachelines (also den Adressraum auf Cachelineebene) gleichmäßig zwischen den RAM-Channels interleaven kann (um die maximale Bandbreite nutzen zu können).

Braucht man das bei GPUs die in typischen Einsatzszenarien massiv parallel rechnen und daher quasi zufällige Zugriffspattern auf den Speicher haben?

Gipsel

2022-07-22, 09:40:07

Braucht man das bei GPUs die in typischen Einsatzszenarien massiv parallel rechnen und daher quasi zufällige Zugriffspattern auf den Speicher haben?Deswegen der Teil, den Du nicht zitiert hast (zum Ende des Posts), wo vom Wandel der Anforderungen die Rede ist ;).
Im Übrigen sind GPUs prinzipiell auch heute noch recht weit von CPUs entfernt, wo bereits recht kleine Caches ausreichen, um oft quasi zufällige Zugriffsmuster zu erzeugen. Die räumliche Kohärenz der Zugriffe ist bei den klassischen Renderaufgaben typischerweise sehr hoch und geht oft auch über ein paar Cachelines hinaus (das Interleaving ist hier also hilfreich). Die ganze "klassische" GPU-Architektur angefangen bei den Rasterizern, der Zuweisung der Wavefronts nach Screentiles (im Prinzip sogar das Rastermuster innerhalb der Screentiles) zu diesen (und auch den ROPs) und entsprechend auch der Abarbeitung der Wavefronts in dieser Zuteilung zielt darauf ab, eine möglichst große räumliche Kohärenz der Speicherzugriffe zu erzeugen. Das war im Prinzip das Mittel der Wahl zur Erhöhung der Bandbreiteneffizienz (abgesehen von Kompressionstechniken) vor der Einführung der großen Caches, die wir jetzt sehen (die kleinen Caches waren Bandbreitenmultiplier, die quasi fast nur direkten Reuse bzw. in den TMUs die überlappenden Anforderungen benachbarter Fragments abdecken).
Die Gründe, warum sich das jetzt verschiebt, habe ich bereits erläutert, z.B. im letzten Absatz hier (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13062712#post13062712).

Leonidas

2022-07-22, 09:54:32

N32: in etwa 250mm² + 4x40mm² = 410mm²
N33: in etwa 150mm² + 2x40mm² = 230mm²

N33 ist monolithisch in 6nm, ergo fast so groß wie N32.

Linmoum

2022-07-22, 10:06:54

Dass N33 monolithisch ist, behaupten Leaker weiterhin.

Dass RDNA3 hingegen eine "Chiplet-Architektur" ist, ist mittlerweile jedoch Fakt. Genauso wie im Übrigen der Prozess mit N5 und nicht N6. Analog zu Zen wird das also zumindest für das GCD gelten.

Daher glaube ich dann doch eher AMD, als Gerüchten.

basix

2022-07-22, 10:38:31

Sehe ich auch so. Ich sehe einfach keinen vernünftigen Grund, wieso N33 in N6 und monolithisch daherkommt. Vor allem noch mit der Restriktion auf 128bit bei den Leistungsdaten. Wieso nicht gleich auf 192bit gehen? Und dann noch das R&D Nightmare, die RDNA3 IP gleichzeitig auf N6 zu portieren.

Ich bin relativ stark davon überzeugt, dass N33 gleich aufgebaut ist wie seine grossen Geschwister.

amdfanuwe

2022-07-22, 10:39:41

Quelle:
https://twitter.com/_wildc/status/1550143106573549576

https://pbs.twimg.com/media/FYM2hopWYAALi1U?format=jpg
In dem Bildchen wird 16 x PCIe 5.0 angegeben.
Ist da was gesichert?
Da AM5 nur im High End PCIe 5.0 auf den Slot legt, denke ich nicht, dass diese GPU Generation schon PCIe 5.0 bringt.
Besteht von der Bandbreite her auch keine Notwendigkeit.

basix

2022-07-22, 10:41:00

PCIe 5.0 wird vermutlich noch nicht benötigt werden. Aber wieso hier zurückstecken? PCIe 5.0 kompatible GPUs und CPUs wären ein Grund für einen Plattform-Seller.

nordic_pegasus

2022-07-22, 10:52:57

sehe ich wie amdfanuwe. Das AMD PCIe 5.0 am PEG-Slot nur auf X670E (und vielleicht dem gerüchteten B650E) ermöglicht, ist für mich auch ein klares Zeichen, dass gen5 für Grafikkarten noch keine Priorität bei AMD hat.

Es gab doch auch Gerüchte, dass auch Nvidias Ada "nur" gen4 sein könnte.

amdfanuwe

2022-07-22, 10:54:30

PCIe 5.0 wird vermutlich noch nicht benötigt werden. Aber wieso hier zurückstecken? PCIe 5.0 kompatible GPUs und CPUs wären ein Grund für einen Plattform-Seller.
PCIe 5.0 stellt andere Anforderungen an das Board Design. Warum den OEMs das Leben schwer machen und unnötig die Produktion verteuern.
Zudem verprellt man viele PCIe 4.0 Mainboard Besitzer die sich unschlüssig sind, ob die GPU dann überhaupt in ihrem Board läuft.

Linmoum

2022-07-22, 11:10:29

Wenn man komplett auf 5.0 verzichtet, muss man keinen Chipsatz dafür bringen und kann sich den Aufwand sparen bis X770 und 2024.

Davon ab passt das auch nicht zu AMDs "Innovation"-Strategie. Dass X670E PCIe 5.0 unterstützt, wird seinen Grund haben und der liegt sicher nicht an der Konkurrenz. Die Frage ist IMO nur, welche RDNA3-GPUs, nicht ob überhaupt.

Leonidas

2022-07-22, 11:13:54

Dass RDNA3 hingegen eine "Chiplet-Architektur" ist, ist mittlerweile jedoch Fakt.

Bestreitet niemand. Es widerspricht sich aber auch nicht. Wieso kann N33 nicht mono sein, der Rest aber MCM?

Sehe ich auch so. Ich sehe einfach keinen vernünftigen Grund, wieso N33 in N6 und monolithisch daherkommt.

Einsparung von Wafer-Fläche auf N5 zugunsten von Zen 4 nach den leidvollen Erfahrungen anno 2020/21, als AMD gar nichts richtig liefern konnte, weil zu viel gleichzeitig auf N7 aufgelegt war.

BlacKi

2022-07-22, 11:22:07

verlinke doch auf die hauptseite, da hast du es ja gut erklärt. zusätzlich könnte man auch kapazitätsauslastung nennen.
PCIe 5.0 wird vermutlich noch nicht benötigt werden. Aber wieso hier zurückstecken? PCIe 5.0 kompatible GPUs und CPUs wären ein Grund für einen Plattform-Seller.

wann gab es je grafikkarten die nicht den aktuell verfügbaren pcie standard unterstützt haben. das wäre das erste mal, die wahrscheinlichkeit für 5.0 ist deutlich höher als für nur 4.0. gerade wenn amd auch bei den boards das feature bringt. ausserdem kann man so n33 ohne probleme mit nur x8 anbinden.

Linmoum

2022-07-22, 11:59:09

Bestreitet niemand. Es widerspricht sich aber auch nicht. Wieso kann N33 nicht mono sein, der Rest aber MCM?Theoretisch kann es durchaus sein, dass man es bei N33 wie zB bei den APUs handhabt, die auch monolithisch sind.

Aber alleine die offizielle N5-Angabe für RDNA3 widerspricht diesem N6-Mono-Gedanken dann bereits und verweist im Prinzip alle aktuellen Gerüchte dahingehend ins Reich der Fabeln.

Für Zen4 hat AMD zukünftig explizit mehrere Nodes angegeben, da nicht alles auf demselben basieren wird. Für RDNA3 hingegen ausschließlich N5. Das wird seinen Grund haben und ich sehe auch nicht den Vorteil eines N6-Monolithen ggü. einer N5-Chiplet-Lösung.

Kapazitäten kann man anführen, aber der Launch wird sicher auch erst Richtung Sommer 2023 nach N31 und N32 erfolgen und vor allem dürfte N33 in N5 ein gutes Stück unter 200mm2 landen.

Wenn man schon den Chiplet-Approach verfolgt, dann wird man das auch durchziehen. Die MCDs kann man bequem für alle Chips wiederverwenden und das GCD selbst ist ziemlich klein.

amdfanuwe

2022-07-22, 11:59:26

Wenn man komplett auf 5.0 verzichtet, muss man keinen Chipsatz dafür bringen und kann sich den Aufwand sparen bis X770 und 2024.

Gibt außer GPU noch andere PIBs, die die Bandbreite auch brauchen können.
Ich denke an FPGA Boards, SSD Erweiterungen, Entwicklerboards etc.

amdfanuwe

2022-07-22, 12:04:57

Denke auch, dass da eher noch N23 oder N22 auf 6nm kommt für das billig Segment.
N24 ist ja schon N6.

BlacKi

2022-07-22, 12:18:17

Denke auch, dass da eher noch N23 oder N22 auf 6nm kommt für das billig Segment.
N24 ist ja schon N6.

warum sollte man n23 oder n22 denn n34 vorziehen?

Linmoum

2022-07-22, 12:21:43

Dafür müsste man erst einmal wissen, ob es einen Chip unterhalb von N33 überhaupt geben wird.

basix

2022-07-22, 12:28:37

Einsparung von Wafer-Fläche auf N5 zugunsten von Zen 4 nach den leidvollen Erfahrungen anno 2020/21, als AMD gar nichts richtig liefern konnte, weil zu viel gleichzeitig auf N7 aufgelegt war.

Auch daran gedacht, dass...

...Zen 4 ebenfalls viel N6 Fläche in Form des IOD beansprucht?
...im unteren GPU Segment vermutlich N22/23/24 in N7 weiterlaufen?
...alle APUs mit Ausnahme der zukünftigen Zen 4 APUs in N6/7 produziert werden, auch in 2023 aka Mainstream/Lowend?
...Zen 3 im Mainstream Segment am Desktop weiterlebt?
...MCDs von RDNA3 sowie Zens V-Cache in 6nm designed sind?
...die Konsolen und ihren SoCs, welche nur schwer verfügbar sind, sowie Steam Deck alle auf 7nm setzen?
...CDNA2 und vermutlich der V-Cache von CDNA3 in N6 produziert werden?

Es gibt also noch extrem viele Chips bei AMD, welche 6/7nm Allocation beanspruchen. Und eben auch 2023/2024 nicht vom Markt verschwinden werden. Und heute mit zu geringen Produktionsvolumen zu kämpfen haben. Ich glaube da ist AMD besser beraten, alle RDNA3 GCDs auf N5 zu designen.

Und wie gesagt, es wäre eine Engineering Hölle, die gleiche IP gleichzeitig auf zwei verschiedenen Prozessen aufzulegen. Man alloziert viel R&D Manpower für einen fragwürdigen Gewinn bei Kosten und Wafer-Allocation. Und viel Spass beim Bring-Up und Debugging. Das würde nur Sinn machen, wenn dies zeitlich versetzt passieren würde, wonach es aber nicht wirklich aussieht.

- N31 = N5
- N32 = N5
- Phoenix = N5
- N33 = N6?! -> macht keinen Sinn, insbesondere da N33 eine perfekte Mobile GPU wäre. Und eben das Dilemma mit 128b SI...

Beispiel Zen 4 (Desktop) vs. N33:
- Zen 4 = 72mm2 (N5) + ~120mm2 (N6)
- N33 @ N6 = ~400mm2
- N33 @ N5 = ~150mm2 (N5) + ~80mm2 (N6)

-> Kommt N33 in N6, kann man ~3x IOD weniger produzieren --> 3x CPUs weniger
-> Kommt N33 in N5, kann man ~2x CCD und ~1x IOD weniger produzieren --> 1-2x CPUs weniger

Was ist jetzt vorteilhafter? N33 mit der bestmöglichen Technologie und weniger R&D Effort herzustellen? Und dazu noch mehr Zen 4 CPUs produzieren zu können? Oder eben beides nicht? ;)

Kapazitäten kann man anführen, aber der Launch wird sicher auch erst Richtung Sommer 2023 nach N31 und N32 erfolgen und vor allem dürfte N33 in N5 ein gutes Stück unter 200mm2 landen.
Wie oben beim Beispiel N33 vs. Zen 4 hergeleitet: Das mit den Kapazitäten ist ein Trugschluss.

Dafür müsste man erst einmal wissen, ob es einen Chip unterhalb von N33 überhaupt geben wird.
(N22) / N23 / N24 sollen weiterlaufen.

Edit:
Bestreitet niemand. Es widerspricht sich aber auch nicht. Wieso kann N33 nicht mono sein, der Rest aber MCM?
Neben den gesamten Shader Arrays auf N6 zu portieren müsste auch der Uncore auf separate IP setzen (Video, Display, IO). Einzige denkbare Variante wäre, wenn AMD hier das von Rembrandt mitnimmt (oder unwahrscheinlich diesen Teil in ein separates N6 Chiplet ausgelagert hat). Dann hat man hier aber allenfalls eine IP-Ungleichheit. Ich weiss nicht, ob das dann in den Treiber-Leaks und den verschiedenen IP-Block-Versionen nicht schon längst hätte auffallen müssen.

Rembrandts VCN = 3.1.1
RDNA3 = 4.x: https://twitter.com/Locuza_/status/1521597617641340934

Linmoum

2022-07-22, 12:40:52

N22 soll laut Kepler teurer in der Herstellung sein als N33. Das kann ich mir daher nicht wirklich vorstellen. Da wird man dann so schnell wie möglich den Stecker ziehen. Dann gibt's eher zwei Salvages von N33.

basix

2022-07-22, 12:44:45

Und/oder man prügelt N23 hoch.

Dafür müsste man erst einmal wissen, ob es einen Chip unterhalb von N33 überhaupt geben wird.
Nach jetzigem Kenntnisstand gibt es 4x RDNA3 GPUs. Und eine davon ist die Phoenix APU.
https://twitter.com/Locuza_/status/1521530696199819266/photo/1

Linmoum

2022-07-22, 12:51:32

Noch mehr hochprügeln als schon die 6650XT? :D Da dürfte quasi kein Platz für noch mehr sein.

Leonidas

2022-07-22, 12:52:04

Aber alleine die offizielle N5-Angabe für RDNA3 widerspricht diesem N6-Mono-Gedanken dann bereits und verweist im Prinzip alle aktuellen Gerüchte dahingehend ins Reich der Fabeln.

Da wäre ich eben vorsichtig. IMO schließt sich das überhaupt nicht aus. Hersteller geben gern mal nur das Allerbeste in ihren Folien an, gerade wenn nur Platz für kurze Schlagworte ist. Damit ist keineswegs gesagt, das die ganze Gen unbedingt exakt so aussehen muß.

Vor allem aber würde diese These bedeuten, dass ich aus den vorhandenen und sehr zutreffenden Leaks mir selektiv nur das rausnehmen darf, was zu dieser These passt. Das halte ich aber für höchst riskant. Wieso sollte derselbe Leaker mit seinen N31-Angaben richtig liegen und die im selben Leak genannten N33-Angaben müssen dann falsch sein? Entweder oder.

Natürlich reden wir hier nur über Chancen. Am Ende kann auch diese Lösung herauskommen, der vorab die kleinste Chance eingeräumt wurde.

basix

2022-07-22, 12:54:35

Noch mehr hochprügeln als schon die 6650XT? :D Da dürfte quasi kein Platz für noch mehr sein.

100-200 MHz liegen noch drin :D

mksn7

2022-07-22, 13:16:37

Deswegen der Teil, den Du nicht zitiert hast (zum Ende des Posts), wo vom Wandel der Anforderungen die Rede ist ;).
Im Übrigen sind GPUs prinzipiell auch heute noch recht weit von CPUs entfernt, wo bereits recht kleine Caches ausreichen, um oft quasi zufällige Zugriffsmuster zu erzeugen. Die räumliche Kohärenz der Zugriffe ist bei den klassischen Renderaufgaben typischerweise sehr hoch und geht oft auch über ein paar Cachelines hinaus (das Interleaving ist hier also hilfreich). [...]

Aktuelle GPUs (V100/A100) mögen es immer noch am meisten, wenn man in wenigen, großen, zusammenhängenden Blöcken zugreift.

Ein schwieriges Zugriffsmuster ist z.B. Iterieren durch einen 2D / 3D sub block innerhalb eines größeren 2D / 3D Arrays. Da man immer nur einen Teil jeder Zeile liest, hat man in den linearen Adressen immer wieder Lücken drin. Bei GPUs gibts zwar schonmal keinen prefetcher, der sich damit vertut, aber die maximale Bandbreite ist trotzdem spürbar kleiner. Ich hab mal versucht solche Muster ein bisschen auszumessen, bin aber auf keinen klaren, einfachen Zusammenhang gekommen.

Meine Vermutungen waren einmal der TLB, weil Lücken im Set an gleichzeitig benutzten Speicheradressen auch die effektive TLB coverage verschlechtern. Der ist leider schlecht dokumentiert bei GPUs, und es gibt auch keine performance counter dazu.

Oder eben eine load imbalance bei der Belegung der Speicherkanäle, oder irgendwas an der Organisation der Speicherchips, die es bevorzugen wenn innerhalb größerer Blöcke möglichst viel zugegriffen wird. Aber da kenn ich mich gar nicht aus.

w0mbat

2022-07-22, 14:07:57

Quelle:
https://twitter.com/_wildc/status/1550143106573549576

https://pbs.twimg.com/media/FYM2hopWYAALi1U?format=jpg
Ich muss zugeben, wenn die RDNA3-Familie wirklich so aussieht (was immer wahrscheinlicher wird), fällt es mir schwer den Grund für das chiplet design zu erkennen.

Navi33 ist weiterhin 100% monolithisch, also kein chiplet und auch Navi32 und Navi31 sind im Grunde monolitisch, also wenn man das GCD anschaut. AMD hat hier drei unterschiedliche chips mit drei tape-outs. Und dann kommen noch die MCDs dazu, was noch ein weiteres tape-out bedeutet. Also insg. 4 chips anstatt von 3 (wenn alle 100% monolitisch gewesen wären).

Vielleicht macht es wirklich einen großen Unterschied wenn man die MCDs in einem für cache optimierten Prozess herstellt und durch die Splittung fallen die GCDs ja auch etwas kleiner aus, was zu besseren yields führt.

Aber für mich war bisher der Hauptvorteil einer chiplet Architektur, dass man eben weniger chips entwickeln und produzieren muss. Mit einem CPU-die und zwei I/O-dies baut AMD alle CPUs, von entry level Ryzen, über Threadripper, bis hin zum EPYC. Super effizientes Vorgehen.

Aber anstatt drei monolitische GPUs zu entwickeln jetzt dazu noch ein extra MCD bis zum tape-out bringen und dann dass teurere packaging dazu, das ergibt für mich noch nicht so viel Sinn.

Aber wir werden den Grund für dieses design sicher erfahren.

sehe ich wie amdfanuwe. Das AMD PCIe 5.0 am PEG-Slot nur auf X670E (und vielleicht dem gerüchteten B650E) ermöglicht, ist für mich auch ein klares Zeichen, dass gen5 für Grafikkarten noch keine Priorität bei AMD hat.
Gen5 für PEG gibt es nicht nur auf den "Extreme" Mainboards. Aktuell sieht es so aus: B650 = nur Gen5 M.2 erlaubt, OEMs können auch Gen4 only Mobos bringen; X670 = Gen5 M.2 zwingend, Gen5 PEG erlaubt; X670E = Gen5 für M.2 & PEG zwingend.

Thomas Gräf

2022-07-22, 15:10:08

Vielleicht ist es derzeit unglaublich schwierig oder unmöglich im Consumer Bereich mehr als ein GCD adäquat ans laufen zu bekommen.

Liegts am Know how für einen solchen Treiber?
Iwas grundlegendes muss es ja sein das man im Grafikbereich bis heute nicht so agieren kann wie bei den CPUs.

Ein Windows darf ja in jedem Falle nur eine einzige GPU "sehen", oder?

basix

2022-07-22, 15:33:27

Ich muss zugeben, wenn die RDNA3-Familie wirklich so aussieht (was immer wahrscheinlicher wird), fällt es mir schwer den Grund für das chiplet design zu erkennen.

Kosten und N5 Wafer Allocation. Sollte beides besser dastehen als wenn RDNA3 in monoltithischen N5 Chips daherkäme.

Dazu: Ist der erste Schritt in Richtung Chiplets. Kleinere Schritte sind einfacher zu handhaben (Designrisiko, Learnings).

Navi33 ist weiterhin 100% monolithisch, also kein chiplet und auch Navi32 und Navi31 sind im Grunde monolitisch, also wenn man das GCD anschaut. AMD hat hier drei unterschiedliche chips mit drei tape-outs. Und dann kommen noch die MCDs dazu, was noch ein weiteres tape-out bedeutet. Also insg. 4 chips anstatt von 3 (wenn alle 100% monolitisch gewesen wären).

Genau das mit dem monolithischen N33 bezweifle ich, aus den bereits weiter oben dargelegten Gründen.

Und:
- 4x relativ kleine Chips (verglichen mit monolithisch)
- MCD könnte bei RDNA4 wiederverwendet werden

Vielleicht macht es wirklich einen großen Unterschied wenn man die MCDs in einem für cache optimierten Prozess herstellt und durch die Splittung fallen die GCDs ja auch etwas kleiner aus, was zu besseren yields führt.

Siehe SRAM-Density des V-Caches. Das sind locker 1-2 Node-Sprünge dazwischen. Und dazu noch der deutlich günstigere Prozess. Noch extremer spätestens dann wenn man in Richtung N3 geht und die MCDs in N3 bleiben können.

Aber für mich war bisher der Hauptvorteil einer chiplet Architektur, dass man eben weniger chips entwickeln und produzieren muss. Mit einem CPU-die und zwei I/O-dies baut AMD alle CPUs, von entry level Ryzen, über Threadripper, bis hin zum EPYC. Super effizientes Vorgehen.

Aber anstatt drei monolitische GPUs zu entwickeln jetzt dazu noch ein extra MCD bis zum tape-out bringen und dann dass teurere packaging dazu, das ergibt für mich noch nicht so viel Sinn.

Aber wir werden den Grund für dieses design sicher erfahren.

Wie gesagt, ist ein erster Schritt. Bei RDNA4 könnte es sein, dass es nur noch ein einzelnes GCD-Design gibt und man dann 1-N von diesen GCDs zu einer GPU verbindet. Dann kommen wir genau zu dem Vorteil, den du da ansprichst.

Oder: Die Gerüchte sind alle Nonsense und die 4096, 8192, 12'288 SP Staffelung ergibt sich aufgrund einem einzelnen 4096 SP GCD :D Who knows.

Das Packaging wird vermutlich nicht viel teurer sein, da so wie es aussieht kein 3D-Stacking und vermutlich auch keine Interposer o.ä. verwendet werden.

Der_Korken

2022-07-22, 15:40:39

Der Grund für die Aufteilung dürfte zunächst mal ein wirtschaftlicher sein. Es macht einen großen Unterschied, ob ich einen 600mm² großen 5nm-Chip habe oder einen mit 350mm² plus 6 kleine 6nm-Schnipsel: Deutlich bessere Yields beim GCD, deutlich weniger Verschnitt am Wafer-Rand und weniger starke Abhängigkeit von 5nm.

Eine GPU auf mehrere Chips aufzuteilen, ist viel schwieriger als bei einer CPU, weil eine GPU an einer gemeinsamen, großen Task rechnet, während CPU-Kerne weitestgehend unabhängig voneinander agieren. Die Analogie wäre, dass ich eine GPU baue, die für z.B. für 8, 16, 64, etc. unabhängige Clients die Frames rendert. Da wäre es natürlich kein Problem einfach Chiplet-Grenzen zu ziehen mit minimalen Loadbalancing-Verlusten. Andersherum wäre ein Chiplet-Ansatz bei CPUs ebenfalls ein großes Problem, wenn man einen einzelnen Kern auf mehrere Chips aufteilen müsste. Die Latenzprobleme und der Energieverbrauch für die enorme externe Bandbreite zwischen den einzelnen Teilen, würden das Design komplett killen. Durch die Die-Stacking-Technologien ist sowas für GPUs überhaupt erst denkbar geworden.

w0mbat

2022-07-22, 15:46:24

Das Packaging wird vermutlich nicht viel teurer sein, da so wie es aussieht kein 3D-Stacking und vermutlich auch keine Interposer o.ä. verwendet werden.
GCD und MCDs müssen aber eine sehr schnelle Verbindung haben, ohne Interposer wird das schwer, wenn ich nichts übersehe. Hier wäre eine EMIB ähnliche Technologie sehr interessant, da man alles über kleine bridges im substrate laufen lassen könnte.

Ich finde dieses Patent sehr interessant und hätte es auch schon für RDNA3 erwartet: https://www.freepatentsonline.com/y2021/0097013.html

mboeller

2022-07-22, 16:35:11

Und eben das Dilemma mit 128b SI...

Mal eine spontane verrückte Idee:

N33 = GCD + 2-3 MCD; ergo 128-192bit/8-12GB/64MB-192MB IF$ (incl. 3D-VCache)

Das wäre zumindest ein sehr guter Grund für die 64bit MCD und würde eine sehr breite Spreizung beim N33 Angebot erlauben.

Gipsel

2022-07-22, 17:26:41

Aktuelle GPUs (V100/A100) mögen es immer noch am meisten, wenn man in wenigen, großen, zusammenhängenden Blöcken zugreift.Alte Gewohnheiten legt man halt nicht so schnell ab. Das gilt offenbar auch für GPUs (quasi/beinahe kontinuierlicher Zugriff auf größere Speicherblöcke war lange Zeit ein primäres Optimierungsziel für GPUs). Wie gesagt erwarte ich aber, daß sich das (im Prinzip jetzt bzw. spätestens in naher Zukunft) zumindest etwas verschieben wird, weil sich eben auch die Anforderungen wandeln.
Ein schwieriges Zugriffsmuster ist z.B. Iterieren durch einen 2D / 3D sub block innerhalb eines größeren 2D / 3D Arrays. Da man immer nur einen Teil jeder Zeile liest, hat man in den linearen Adressen immer wieder Lücken drin. Bei GPUs gibts zwar schonmal keinen prefetcher, der sich damit vertut, aber die maximale Bandbreite ist trotzdem spürbar kleiner.Meine Versuche dazu sind schon etwas her, aber damalsTM war sowas häufig merklich schneller, wenn man das in einen Pixelshader statt Computeshader gepackt hat. Im Prinzip verbiegt das die Indizierung der Arrays (Texturen) in lustigen Mustern (AMD hat lange ein Hierachical Z Pattern/Z-order curve (https://en.wikipedia.org/wiki/Z-order_curve) benutzt), um bei der Abarbeitung die Kohärenz der Speicherzugriffe zu erhöhen. Aber das erkauft man sich mit Problemen woanders und ist deswegen oft nicht wirklich praktisch.

amdfanuwe

2022-07-22, 18:12:39

Oder eben eine load imbalance bei der Belegung der Speicherkanäle, oder irgendwas an der Organisation der Speicherchips, die es bevorzugen wenn innerhalb größerer Blöcke möglichst viel zugegriffen wird. Aber da kenn ich mich gar nicht aus.
Zum Speicherchip hab ich hier was gefunden:
http://monitorinsider.com/DRAM_transaction_scheduling.html

Zu GDDR6 hat er auch was
http://monitorinsider.com/GDDR6.html

Bei Micron eine GDDR Introduction
https://www.micron.com/-/media/client/global/documents/products/technical-note/dram/tned01_gddr5_sgram_introduction.pdf

Und Datasheet zu einem GDDR6
https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/dram/gddr/gddr6/gddr6_sgram_networking_brief.pdf?rev=ea88c60377b4432e8d7e79aedce405d7 (https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/dram/gddr/gddr6/gddr6_sgram_networking_brief.pdf?rev=ea88c60377b4432e8d7e79aedce405d7)

Berniyh

2022-07-22, 18:41:36

Sehe ich auch so. Ich sehe einfach keinen vernünftigen Grund, wieso N33 in N6 und monolithisch daherkommt.
Weil der Chip wieder verstärkt auch in mobilen Produkten zum Einsatz kommen könnte.
Dazu könnte es auch einfache eine Frage von Preis und Stückzahl sein.

robbitop

2022-07-22, 19:56:56

Gerade bei mobilen Produkten ist Leistungsaufnahme / Energieeffizienz wichtig. Wäre da 6 nm nicht ein deutlicher Nachteil ggü 5nm?

StefAlb

2022-07-22, 20:09:33

Wann war denn nochmal der "geplante" offizielle Vorstellungstermin des Navi31??

Linmoum

2022-07-22, 20:19:06

Gerade bei mobilen Produkten ist Leistungsaufnahme / Energieeffizienz wichtig. Wäre da 5 nm nicht ein deutlicher Nachteil?Du meinst sicher N6. ;)

basix seine Anmerkung bzgl. des IOD für Zen finde ich aber ganz passend und das hatte ich so bisher auch noch gar nicht betrachtet. Das Ding kommt ja auch in N6 daher und muss in Massen produziert werden. Wenn man N33 also in N6 fertigen lässt, nimmt man dem IOD Kapazitäten weg. Und in N6 reden wir bei einem Mono-N33 sicherlich von >300mm². Via Single GCD reduziert man das deutlich auf (bei 128bit Bus) nur noch 2x MCD, also ~80mm² und ausgehend von nur ~350mm² für N31 wird auch das GCD in N5 extrem klein sein.

Warum man N6 hier N5 (und Mono statt Chiplet) vorziehen sollte, erschließt sich mir schlicht nicht. Und irgendwie konnte das auch noch niemand nachvollziehbar begründen, außer, dass es die Gerüchteküche halt als gesichert ansieht. Aber die war auch monatelang von Dual-GCD überzeugt...

Wann war denn nochmal der "geplante" offizielle Vorstellungstermin des Navi31??Sicherlich irgendwann Q4.

StefAlb

2022-07-22, 20:27:13

Sicherlich irgendwann Q4.

Danke. Bin schon ganz hibbelig bezogen auf die neuen Karten von AMD und NVIDIA :D

gedi

2022-07-22, 20:57:22

Mal eine spontane verrückte Idee:

N33 = GCD + 2-3 MCD; ergo 128-192bit/8-12GB/64MB-192MB IF$ (incl. 3D-VCache)

Das wäre zumindest ein sehr guter Grund für die 64bit MCD und würde eine sehr breite Spreizung beim N33 Angebot erlauben.

Hm, ein MCD 30MB-Vcache, bedeutet 60-90MB für eine 7600XT?! Sorry, klingt für mich sehr schlüssig. Raster-Performance = 6800 non XT, RT 20% above a 6950!

Berniyh

2022-07-22, 22:01:17

Gerade bei mobilen Produkten ist Leistungsaufnahme / Energieeffizienz wichtig. Wäre da 5 nm nicht ein deutlicher Nachteil?
Der Teil war auf den Punkt "monolithisch" bezogen.

Generell ist N33 doch ein Massenprodukt, da könnte es schon sein, dass man aus Kosten- und/oder Kapazitätsgründen auf 6nm setzt, trotz des Nachteils im Stromverbrauch gegenüber 5nm.

Edit: Natürlich wäre optimal monolithisch in 5nm, das steht außer Frage. Generell gehen hier manche einfach zu sehr vom Idealfall aus.
Die letzten Jahre haben aber gezeigt, dass die Waferplanung für AMD ein essentielles Thema ist und das wird sicher auch in Zukunft so bleiben, insbesondere, da jetzt ja auch Intel und Nvidia Chips bei TSMC fertigen lassen.

w0mbat

2022-07-22, 22:13:32

Ein Grund für N6 könnte einfach fehlende Kapazität sein.

robbitop

2022-07-22, 22:23:39

Kapazität und Kosten sind im Zusammenhang von 6nm vs 5 nm selbsterklärend.
Kann schon sein für ein midrange Produkt.

amdfanuwe

2022-07-22, 23:38:41

Wann wurden denn die Kapazitäten bestellt und wann wurde die Entscheidung getroffen ob 6nm oder 5nm? Geht ja nicht alles von heut auf morgen.
Bei den Kapazitäten hat man ja auch Probleme bestellt man zuviel und das Produkt floppt, ist man gearscht und wenn zu wenig und man nicht nachordern kann eben auch.
Einzig bei Konsolen liegt das Risiko einer Fehlplanung nicht bei AMD.

Leonidas

2022-07-23, 06:19:07

Also aus Mobile-Sicht muß ich allen Kritikern Recht geben: Da wäre 5nm für N33 besser, egal ob nun mono oder MCM. Aber es wurde von Anfang an exakt so gemeldet.

Wir können nur hoffen, dass die Leaker sich geirrt haben - oder das AMD das nochmal umgebogen hat. Planänderungen kosten allerdings Zeit, das sieht man ungern.

HOT

2022-07-23, 08:18:25

Er wird mMn genau aus dem Grund sowohl N5 als auch monolithisch mit einem entsprechend niedrigprofiligem Package gefertigt sein. N6 ergibt einfach wenig Sinn, N5 hat bessere Perf/W, die Kapazität für N6 dürfte auch gut ausgelastet sein mit dem I/O-Geraffel, ich wüsste nicht, wieso N33 N6 sein sollte. Das ist nur die Aussage, die 21 getroffen wurde, die das bestätigt.

basix

2022-07-23, 12:35:32

Wir können nur hoffen, dass die Leaker sich geirrt haben - oder das AMD das nochmal umgebogen hat. Planänderungen kosten allerdings Zeit, das sieht man ungern.

Na was heisst hier hoffen? Die Wahrscheinlichkeit, dass die Leaker sich irren, ist nichtmals so klein. Immerhin ging es von monolithisch, zu 2x GCD, zu 1x GCD und x-beliebigen Infinity-Cache, Speicherinterface und Anzahl von Chiplets Kombinationen eigentlich über den gesamten denkbaren Bereich, welcher realisiert werden könnte ;)

Das einzig einigermassen belastbare sind Treibereinträge und die offiziellen Infos von AMD. Und da spricht man von N5 für RDNA3, Chiplets und mit hoher Wahrscheinlichkeit von 6x MCDs und einem 384bit Speicherinterface. That's it. Ob 1x GCD oder dann 3x GCDs bei N31? Who knows. Wir haben lange viel zu oft den Leakern geglaubt anstatt selber den Kopf einzuschalten. Und gerade die letzten Monate haben bewiesen, dass die Leaker im Trüben fischen. Noch viel mehr als bei den letzten GPU-Releases.

HOT

2022-07-23, 13:27:52

Dass N33 trotzdem monolithisch wird halte ich aber für sehr wahrscheinlich. Der wird eben für Mobil gedacht sein und ein entsprechend passendes Package bekommen. Es hat für Mobil einfach zuviele Vorteile, das Ding monolithisch zu machen mMn und ich denke, AMD möchte schon gerne den Perf/W-Vorteil, den man sich erarbeitet hat, im Mobilbereich ausfahren.

basix

2022-07-23, 13:38:41

Du, für mich sind monolithisch 5nm logischer als das selbe in N6. Ich bin da aber auch ein wenig Ingenieur gefärbt ;) N5 Wafer Allocation und Kosten werden hier dann ein deutlich stärkeres Argument. Wobei N33 in 5nm anhand der 350mm2 fürs N31 GCD nur etwa ~250mm2 gross werden sollte.

amdfanuwe

2022-07-23, 16:23:54

Ich hab mal ein paar Daten in eine Tabelle gepackt sowie möglich Salvage Varianten.
Zum Vergleich rechts Navi 20.

Salvage MCDs sollten kaum anfallen, lassen sich aber für 6 oder 10 GByte Bestückung nutzen.

Für brauchbare Salvage Chips dürfte der häufigste Fehler in einer defekten CU auftreten.
Dies handhabt AMD bisher mit Deaktivierung von jeweils 2 CU pro SE oder Abschaltung einer SE.

Viel Spaß beim erstellen eigener Salvage Varianten und Ausdenken der Passenden Verkaufsnamen.

basix

2022-07-23, 17:17:42

Von N31/32 könnte ich mir noch Salvages mit einer komplett deaktivierten Shader Engine vorstellen. Bei N33 eher nicht ;)

N31:
- 6*16 WGP -> 96WGP -> 7900XT / 24GB
- 6*14 WGP -> 84WGP -> 7800XT / 24GB
- 5*16 WGP -> 80WGP -> 7800 / 20GB

N32:
- 4*16WGP -> 64WGP -> 7750XT / 16GB
- 4*14WGP -> 56WGP -> 7700XT / 16GB
- 3*16WGP -> 48WGP -> 7700 / 16GB

N33:
- 2*16WGP -> 32WGP -> 7600XT / 12GB (96bit @ 24Gbps GDDR6)
- 2*12WGP -> 24WGP -> 7600 / 12GB (96bit @ 18Gbps GDDR6)

HOT

2022-07-23, 22:57:45

Eher nicht. N33 ist ziemlich sicher die 7700 Serie. MMn wird die 7600-Serie von N22S abgedeckt und N23S begründet die neue 7500-Serie. Darunter bleiben weiterhin Billigstprodukte mit N24, also 7100 bis 7400.

Ich denke, man wird es wirklich recht einfach machen dieses Mal

N31 full -> 7900XTX
N31 salvage -> 7900XT (1000€-Produkt)
N32 full -> 7800XT
N32 salvage -> 7800
N33 full -> 7700XT (mobil 7800XT) (450-500€)
N33 salvage -> 7700
N22S full -> 7600XT (mobil 7700XT, downgecostet PCB, nur noch 128Bit RAM-Interface und deutlich niedrigere TDP als die 6700XT) (>350€)
N22S salvage -> 7600
N23S salvage -> 7500 (N23S full mobil 7600XT) (>200€)
N24 full -> 7400
N24 salvage -> 7x00

unl34shed

2022-07-23, 23:54:08

@HOT: Die gesamte Gerüchteküche geht so weit ich weiß davon aus, das N33 in der 7600XT landen wird.

Wann gab es eigentlich das letzte mal eine 600er bzw. 60er Karte von AMD, die ein Rebranding eines alten Chips war? In den ersten GCN Generationen bis zur RX300 gab es immer einen Mix verschiedenere Iterationen auch bis ganz oben, aber das lag auch an den relativ kurzen Releasezyklen zu der Zeit.
Ansonsten ist das aller untere Ende, Mobile und dedizierte OEM Ware immer ein Bereich, in dem alter Scheiß neu gelabelt wird.

Und bei RDNA hat AMD zumindest bis jetzt noch nicht das Lineup gemischt.

nordic_pegasus

2022-07-24, 16:59:28

mit den ganzen Gerüchten, dass Nvidia den Release von Ada bis nach 2023 verschieben könnte wegen den vollen Lagern bei den AIBs, glaubt Ihr, dass auch AMD seinen Zeitplan schiebt? Oder freut es vielleicht sogar AMD, wenn sie zuerst am Markt sein könnten und erstmal höhere Preise verlangen könnten (speziell im Highend) bis die AD102 Karten rauskommen?

reaperrr

2022-07-24, 21:59:42

Und bei RDNA hat AMD zumindest bis jetzt noch nicht das Lineup gemischt.
Ich denke schon, dass sie das diesmal tun werden, weil selbst N33 zu groß und damit teuer wird, um den Preisbereich <300$ abzudecken, und es wohl erst mit Navi4x wieder neue kleinere, (relativ) günstige Chips geben soll.

Aber mMn werden nur N23 und N24 weiterlaufen/umgelabelt.
Von der Idee, dass beschnittene N22 dazwischen eingesetzt werden, halte ich wenig, da N33 wohl nur unwesentlich größer und damit teurer als N22 zu fertigen sein wird. Da macht ein stärker beschnittener N33 mehr Sinn als ein auf 128bit/64MB IF$ kastrierter N22, da viel schneller und der dadurch mögliche höhere Preis die marginal teurere Produktion mehr als ausgleicht.

mboeller

2022-07-24, 22:08:02

Aber mMn werden nur N23 und N24 weiterlaufen/umgelabelt.

IMHO:

N33 könnte 1x N5 GCD + 2-3x N6 MCD sein.

Das N5 GCD wäre, wenn es wirklich stimmt, dass das N31 GCD nur 350mm² groß ist vielleicht nur 150-160mm² groß. N33 wäre damit ins. nur ca. 230-240mm² groß mit 8GB/128bit und 280mm² mit 12GB/192bit.

N23 hat 237mm²

N33 scheint damit für mich schon als Ersatz für N23 zu passen.

vinacis_vivids

2022-07-24, 22:53:54

Im Desktop gehts um die Krone N31 vs AD102, da gibs Top-Notch Technik.

Im Mobilen Bereich sieht das anders aus:
Der Sprung von N23 zu N33 wird im mobilen Bereich gigantisch sein. Dafür ist das günstige 6nm perfekt geeignet um bezahlbare Notebooks für mobiles Gaming und höheren Stückzahlen zu generieren. Mit 5nm wäre eine Massen-Marktverbreitung nicht möglich.

AMD braucht unbedingt auch mobile Anteile.

N23m - RX6800M
40CUs - 2560SP
2,3Ghz - 11,78Tflop/s fp32
96MB IF$ - 192bit SI
12GB VRAM
335mm² 7nm TSMC

N33m - RX7800M
64CUs - 4096SP
2,5Ghz - 20,48Tflop/s fp32
128MB IF$ - 128bit SI
8 / 16GB VRAM
~400mm² 6nm TSMC

1,7 - Fache Rechenleistung, mehr verfügbare Bandreite. Mit verringernden Takt noch länger lauffähig. Die Zeichen stehen auch Durchbruch für die NAVI uArch auch im mobilen Bereich.
Eine vergleichbare Leistung mit der 6900XT im mobilen Bereich ist schon ein sehr guter Sprung mit so geringer Veränderung der Fertigung von 7nm auf 6nm.

Das bedeutet dass die Änderung/Verbesserung der uArch bei AMD und ein kleiner Fertigungssprung nur benötigt wird um ordentlich zu skalieren. Der cut am SI und die Vergrößerung des IF$, mehr Takt, mehr Shader. Fall die CU`s noch besser werden (3,3Ghz), sind locker > 6900XT drin.

Am Desktop wird AMD den N33 noch höher takten, womöglich an die Kopzgrenze ~3,3Ghz um beim Balkenvergleich zu gewinnen.

Vor allem von 520²mm runter auf 400²mm bei besserer Leistung und nur geringe Veränderungen bei der Fertigung. Anscheinend lassen sich die CUs richtig geil schrumpfen.

why_me

2022-07-25, 21:18:55

Bleib doch mal auf dem Teppich.
Wie in aller Welt sollen 32MB Cache, irgendwie, 1.7x Leistung und 2/3 SI ausgleichen?

reaperrr

2022-07-26, 20:26:59

Bleib doch mal auf dem Teppich.
Wie in aller Welt sollen 32MB Cache, irgendwie, 1.7x Leistung und 2/3 SI ausgleichen?
Ich glaube, du unterschätzt wie Overkill die 96MB und 192bit von N22 für 1080p waren.

In 1080p ist die 6700XT meist nur knapp ~25% schneller als die 6600XT, also ca. entsprechend der FLOPs, trotz 50% mehr Speicherbandbreite und 3x so großem IF$.

Soll heißen: Zumindest für 1080p hätten der 6700XT wahrscheinlich auch 40MB@160bit oder 64MB@128bit gereicht, oder zumindest keinen großen Unterschied gemacht.

N33 ist außerdem eher N23-Nachfolger, und für 1080p werden der Mix aus 4fachem IF$, schnellerem Speicher, verbesserter DCC und auf entsprechenden Plattformen auch noch PCIe 5.0 reichen, um die angepeilte Performance zu erreichen.
In WQHD wird's sicher etwas schlechter aussehen, aber das ist halt auch nicht das primäre Ziel. Die 7600XT soll mMn die attraktivste Karte für all die verbliebenen 1080p-Spieler werden.