Bericht Architektur Deep Dive: So sollen AMDs CDNA-5-GPUs Platzhirsch Nvidia Paroli bieten

[DevPandi]

Übrigens war der L1 Cache von Anfang an ein Read-Only-Cache (RDNA 1-3).
Beim RDNA4 L1 Buffer werden keine ordinären Programmdaten mehr gecached, bei einem L0 Miss muss danach der L2 Cache gechecked werden, im L1 Buffer gibt es garantiert nichts.

Du weißt schon, wie ein Read-Buffer funktioniert und du hast auch verstanden, warum im LLVM Await-Befehle für die Abfrage vorhanden sind? Du hast auch schon verstanden, dass der L0 seine Daten zwar im L2 anfragt, diese aber dann im GL1 abholt?

Irgendwie versuchst du jetzt auf Teufel komm raus recht zu behalten, und warum? Weil ich schrieb, dass das nicht so ganz stimmt? Ich habe nicht geschrieben, dass deine Aussage falsch, sondern dass sie an der Stelle aber eben auch nicht ganz richtig ist.

Du behauptest darauf, dass dann AMD in den ISA-Docs ja nur Copy-Past macht und schickst die Hinweise zum LLVM, in dem Await-Befehle und alles genau beschrieben wird und wie es arbeitet. Ich gestehe dir dann sogar zu, dass eben der L1-Cache in der Form wie bisher nicht existiert - Read-Only - sondern als Lese-Buffer agiert und womit kommst du, dass er vorher ein READ-ONLY War? Du willst mir ein Strick jetzt draus drehen, das ich sagte, dass er nicht mehr in der bisherigen Form existiert sondern als Lese-Buffer, so wie AMD es selbst beschreibt?

Und du lieferst dann die Erklärung für das ab, was ich beschriebne habe, etwas genauer NUR in dem Fall wirklich weitgehend falsch, weil du denkst dass es bei eime Read-Buffer dann zu einem Cache-Miss kommen kann, wenn der L0 vorher über den L1 beim L2 die Daten explizit anfragt und darauf wartet, bis de im GL1-Lesebuffer sind und da abgeholt werden...

... Ne, letzter Beitrag zu dem Thema, natürlich mit entsprechenden Konsequenzen.


-- Boah, ich geb es zu, du REGST mich gerade sowas von auf ... hier auch mal zu deiner Behauptung mit dem ISA-Doc und Copy-Past:

1.2.3. Device Memory
The AMD RDNA4 devices offer several methods for access to off-chip memory from the processing elements
(PE) within each WGP. On the primary read path, the device consists of multiple channels of L2 cache that
provides data to read-only L1 caches, and finally to L0 caches per WGP. The memory cache is formed by two
levels of cache: the first-level (GL1) for write-combining cache (collect scatter and store operations and
combine them to provide good access patterns to memory); the second (L2) is a read/write cache with atomic
units that lets each processing element complete unordered atomic accesses that return the initial value.
Specific cache-less load instructions can force data to be retrieved from device memory during an execution of
a load clause.
The instruction cache provides shader instructions to each SIMD, and the constant cache provides access to
scalar constants. Both of these caches are read-only.
Each processing element provides the destination address on which the atomic operation acts, the data to be
used in the atomic operation, and a return address for the read/write atomic unit to store the pre-op value in
memory.
Each store or atomic operation can receive an acknowledgment from the cache system to the requesting PE
upon completing the write at the requested cache scope, or for atomics-with-return value, upon receiving the
"pre-op" value from memory. This acknowledgment enables one processing element to implement a fence to
maintain serial consistency by ensuring all writes have been posted to memory prior to completing a
subsequent write. In this manner, the system can maintain a relaxed consistency model between all parallel
work-items operating on the system. Each scatter write from a given PE to a given memory channel maintains
order.

Und der ganze Abschnitt für RDNA 3:

1.2.3. Device Memory
The AMD RDNA3 devices offer several methods for access to off-chip memory from the processing elements
"RDNA3" Instruction Set Architecture
1.2. Hardware Overview 7 of 600
(PE) within each WGP. On the primary read path, the device consists of multiple channels of L2 cache that
provides data to read-only L1 caches, and finally to L0 caches per WGP. Specific cache-less load instructions
can force data to be retrieved from device memory during an execution of a load clause. Load requests that
overlap within the clause are cached with respect to each other. The output cache is formed by two levels of
cache: the first for write-combining cache (collect scatter and store operations and combine them to provide
good access patterns to memory); the second is a read/write cache with atomic units that lets each processing
element complete unordered atomic accesses that return the initial value. Each processing element provides
the destination address on which the atomic operation acts, the data to be used in the atomic operation, and a
return address for the read/write atomic unit to store the pre-op value in memory. Each store or atomic
operation can be set up to return an acknowledgment to the requesting PE upon write confirmation of the
return value (pre-atomic op value at destination) being stored to device memory.
This acknowledgment has two purposes:
• enabling a PE to recover the pre-op value from an atomic operation by performing a cache-less load from
its return address after receipt of the write confirmation acknowledgment, and
• enabling the system to maintain a relaxed consistency model.
Each scatter write from a given PE to a given memory channel maintains order. The acknowledgment enables
one processing element to implement a fence to maintain serial consistency by ensuring all writes have been
posted to memory prior to completing a subsequent write. In this manner, the system can maintain a relaxed
consistency model between all parallel work-items operating on the system.

Ja, es ist ja nur Copy&Past und ein Fehler. Da steht im Endeffekt genau aber das drin, weswegen ich sagte, dass deine Aussage eben nicht so ganz stimmt. Aber statt mal zu zugeben, dass man hier mal selbst ungenau war, versuchst du auf Teufel komm raus nun irgendwie "Recht" zu behalten und schwenkst dann auf das, was ich beschrieben habe um, und dass erklärst du dann auch noch falsch, weil du behautest im GL1 gäbe es dann ein Miss, dabei schiebt der L2 seine Daten da nach Anfrage hin rein, damit es abgeholt wird. Aber Hauptsache irgendwie recht haben.

Nein, eine Entschuldigung an alle anderen, aber sowas ärgert mich echt Maß los!

 

[Locuza]

@DevPandi

Ich führe mal meine Sichtweise bezüglich des Diskussionspunkts aus.
Das klärt hoffentlich auf, wieso ich gewisse Aussagen getätigt habe, die ohne Kontext durchaus verwirrend ausfallen.

1.) Zu Beginn gab es zwei Aussagen von mir:

RDNA 4: Lokaler 32 KB L"0"$ + Globaler L2 Cache + L3$/Infinity Cache
(Der L1 Cluster Cache wurde entfernt)

[2] Die Hit-Rate des L1-Caches war relativ schwach, und jedes zusätzliche Cache-Level erhöht die Latenzen.
Bei RDNA 4 hat man den L1-Cache in einen einfacheren L1-Buffer umgewandelt, welcher Speicherzugriffe zum L2-Cache nach wie vor aggregiert und steuert, aber selber keine Daten mehr cached.
Um die verlorene L1-Cache-Bandbreite auszugleichen, hat RDNA 4 relativ zu RDNA-3-Chips doppelt so viele L2-Cache-Slices, die Bandbreite und Kapazität wurde verdoppelt.

Du hast zumindest die erste Aussage gesehen und dieser mit zwei Zitaten aus der RDNA4-ISA-Dokumentation widersprochen.
Der Textausführung zum L1-Cache und dem Schaubild, welches nach wie vor einen "L1 R/O Cache" zeigt:

@Locuza
So ganz stimmt das mit dem L1-Cache nicht, dass der entfernt wurde:

"The AMD RDNA4 devices offer several methods for access to off-chip memory from the processing elements
(PE) within each WGP. On the primary read path, the device consists of multiple channels of L2 cache that
provides data to read-only L1 caches, and finally to L0 caches per WGP. The memory cache is formed by two
levels of cache: the first-level (GL1) for write-combining cache (collect scatter and store operations and
combine them to provide good access patterns to memory); the second (L2) is a read/write cache with atomic
units that lets each processing element complete unordered atomic accesses that return the initial value.
Specific cache-less load instructions can force data to be retrieved from device memory during an execution of
a load clause."

S. 8 der RDNA 4 ISA. Dazu von Seite S.5 die Grafik:
Anhang anzeigen 1749578

Du redest hier und in deinem letzten Posting zwar davon, dass meine Aussage "nicht so ganz stimmt", also von mir aus teils richtig sein könnte, allerdings gibt das zitierte Material das nicht her.
Weil es eben der gleiche L1-Cache-Textbaustein ist und keine veränderte Implementierung gegenüber RDNA3 beschreibt.
Entsprechend habe ich deinen Widerspruch als absolut gewertet.

Die ISA-Dokumentation ist natürlich nicht deine Schuld, wenn das so geschrieben wird von offizieller Seite geht man vermutlich generell von Korrektheit aus.
Hier kam dann aber mein Einwurf, dass diese Elemente Copy & Paste-Fehler sind, und immer mal wieder vorkommen.
Zusätzlich habe ich geschrieben, dass man richtigerweise alle früheren L1-Referenzen entfernt hat.
Hier habe ich mich auf den L1 als Cache bezogen.
Das hätte ich lieber explizit schreiben sollen, ich habe aber gehofft das ergibt sich aus dem Kontext.

Um zu untermauern, dass es keinen L1-Cache mehr gibt, habe ich das LLVM-GFX12/RDNA4-Memory-Model verlinkt, welches von einem L1-Buffer spricht, sowie Latenzergebnisse von Chips & Cheese, die aufzeigen, dass es keine Cache-Zwischenstufe zwischen L0 und L2 mehr gibt.
_____

2.) Soweit, so gut, hoffentlich.
Dann wird es aber vermutlich verwirrend und die Züge verlassen die Gleise.

Darauffolgend kam nämlich ein Beitrag von dir, den du in einigen Punkten bearbeitet hast.
Ich habe teilweise auf etwas geantwortet, was nicht mehr dasteht bzw. was ich dann auch nicht mehr zitieren konnte.
Entsprechend kann ich nur grob aus meiner Erinnerung oder zumindest aus meinem Eindruck heraus sprechen.

- Der Anfang deines Beitrags hat die LLVM L1-Buffer-Ausführungen als unterstützendes Material gewertet.
Zudem gab es mehr Text der einen Copy-&-Paste-Fehler als unwahrscheinlich eingestuft hat, da die Schaubilder zwischen RDNA4 und RDNA3 unterschiedlich ausfallen.
Die Ansicht, dass ein Copy-&-Paste-Fehler zumindest möglich ist, wurde nachträglich eingefügt.

- Du kannst mich gerne korrigieren, falls ich falsch liege.
Ich meine aber, dass es eine kurze Aussage bezüglich des L1 gab, mit der Ausführung, dass AMD diesen als Read-Only umgestaltet hat.
Ich weiß nicht mehr genau, ob im Beitrag schlicht vom L1, Cache, Buffer oder Struktur die Rede war.
Bei mir blieb jedenfalls der Eindruck hängen, dass AMD den L1 zu einem Read-Only Cache umgebaut hat.
Deshalb führt meine Antwort aus das der L1-Cache von Anfang Read-Only bei RDNA1-3 war.
Zudem habe ich ausgeführt, dass der L1-Buffer bei RDNA4 keine Daten zwischenspeichert und man bei einem L0-Miss im L2-Cache nachsehen muss.
(Ich habe nicht behauptet, dass es Misses im L1-Buffer gibt.)

Genau hier liegt vermutlich der Knackpunkt der Verwirrung, oder eben meiner falschen Einordnung.

- Am Ende stand: "Aber lassen wir’s mal."
Dies wurde dann entfernt und diese Passage hinzugefügt

RDNA 4,

Nimmt man alles zusammen, ist der L1-Cache an der Stelle nicht einfach verschwunden, sondern wird im ganzen anders in die Kette eingebunden - was auch die Latenzen erklärt.

-- Und um das ganze mal zumindest versöhnlich zu Ende zu bringen: Der L1-Cache in der "klassischen" Form, wie bei RDNA 1 - 3 existiert nicht mehr, richtig. Aber der L1 wird jetzt als Lese-Buffer genutzt. Die Daten werden im L2 angefragt, liegen dann aber im L1 bereit zum Abholen, das erklärt eben auch, warum sich die Latenzmessungen hier geändert haben und der "Spike" geglättet wird - was im Ganzen sich positiv auf die Latenzen und eben den Durchsatz auswirkt, gleichzeitig den L2 allerdings dennoch entlasstet.

Abseits von meiner möglichen Fixierung, dass ich in diesem Kontext den Ausdruck "Cache" gänzlich ausklammern würde, habe ich prinzipiell keine Einsprüche.

Man könnte debattieren, wie man hier Latenz, Durchsatz und Entlastung des L2-Caches einordnet, im Vergleich zur vorherigen L1-Cache-Implementierung oder gegenüber einer fiktiven Implementierung gänzlich ohne Zwischenbuffer für L2-Cache Lese-/Schreibzugriffe?

3.)

... Ne, letzter Beitrag zu dem Thema, natürlich mit entsprechenden Konsequenzen.

???
Welche Konsequenzen, und für wen oder was?

-- Boah, ich geb es zu, du REGST mich gerade sowas von auf ...

Während ich aus deiner Perspektive ein Vorbeireden oder eine falsche Einordnung meinerseits sehe, empfinde ich das hier dennoch als Überreaktion.
In keiner Hinsicht habe ich eine provokante Stellung bezogen oder mich an einem Nonsense-Loop beteiligt.
Insgesamt gab es gerade mal zwei Postings mit wenigen Sätzen, die als direkte Antwort von mir kamen.

 

[ETI1120]

AMD hat die Dokumentation der CDNA5 ISA veröffentlicht:

https://www.amd.com/content/dam/amd...stinct-cdna5-instruction-set-architecture.pdf

 

[ETI1120]

Es gibt ein interessantes Bit zur MI455X

Semianalysis behauptet dass AMD eine aktive Silizium Brücke verwendet.

https://x.com/i/status/2084459410265411615

Mal schauen ob sie Recht haben.

 

[Colindo]

@ETI1120 Kann gut sein. Die Verbindung zwischen den beiden FCDs ist jedenfalls sehr schnell, damit sie den VRAM-Zugriff über alle XCDs verteilen kann. Womöglich nur mit LSI Bridges möglich.

 

[Pringel]

Setzt sich da nicht langsam die Bezeichnung XGU durch?
(so bisschen abgekupfert von dem was Intel als xPU quaseln wollte).

AMD war schon mit den 300ern ziemlich gut. Die XGUs sind nicht mehr so das Thema. Pferdefuß war und ist die Vernetzung. Das ist die Stelle wo NV mit der Gesamtleistung punkten kann.
UltraEthernet badet schon viel aus. Da geht das meiste gegenüber InfiniBand brauchbar aufzuholen.

Im Gegensatz zu NVlink. Da ist mit UAlink noch einiges zu tun und als halbwegs gleichwertig lässt sich erst UALink 3.0 benennen (sagt Bowman selbst). UAlink ist grad die wichtigste Baustelle für AMD.

Deswegen auch, im Gegensatz zu UltraEthernet, jagt beim UAlink eine Spec die andere

 

[ETI1120]

Ich muss mir noch Mal alles in Puncto Advanced Packaging in Ruhe ansehen. Aktuell ist es mir zu warm um den Rechner anzuschmeissen.

Die Verbindung zwischen den Dies muss auf Silizium stattfinden, da nur so die gewünschte Verbindungsdichte und damit Bandbreite möglich ist. Die Bandbreite muss ausreichen um die HBM Stacks, die am anderen FCD angeschlossen sind, mit voller Geschwindigkeit ansprechen zu können. Deshalb setzt AMD bei den MI3xx Silizium Interposer ein.

Wie gesagt den Aufbau der MI455X muss ich mir noch Mal in reinziehen. Ich bin nicht sicher ob AMD die FCD mit einem Interposer oder mit Brücken verbindet. Ein aktiver Interposer wäre nichts neues aber natürlich wäre derselbe "Trick" den Semianalysis erwähnt auch mit einem Silizium Interposer möglich.

Es gibt genügend Patentanträge von AMD zu aktiven Siliziumbrücken, so dass die es keine Überschneidung wäre. Allerdings ist der Platz bei Siliziumbrücken sehr beschränkt.

 

[Pringel]

Gilt das dann nicht eh für die komplette 400er Serie? Oder wirklich nur bei 455X?

 

[ETI1120]

Deswegen auch, im Gegensatz zu UltraEthernet, jagt beim UAlink eine Spec die andere

Das größte Problem ist IMO dass keine UALink Switches verfügbar sind und dass deswegen UALink über Ethernet betrieben werden muss.

Und NVIDIA hat eben NVLink schon seit ein paar Generationen in Hardware realisiert.

Und beim Implementieren der Hardware stößt man AFAIU an Punkte, die in der Spezifikation nicht eindeutig geregelt sind. Dann muss man die Spezifikationen nach schärfen. Ob es darüber hinaus um neue Features oder höhere Performance geht habe ich nicht nachverfolgt.

Ergänzung (Dienstag um 11:33)

Gilt das dann nicht eh für die komplette 400er Serie? Oder wirklich nur bei 455X?

Außer den Daten hat AMD nichts zur MI430X gezeigt. So wie ich das verstehe ist alles bis auf die CCD dasselbe.

Ergänzung (Dienstag um 11:37)

Setzt sich da nicht langsam die Bezeichnung XGU durch?

Nicht dass ich müsste.

Die NVIDIA und AMD bleiben bei GPU um die Programmierbarkeit hervorzuheben. Google hat die TPUs und die anderen reden in letzter Zeit lieber über XPU anstatt ihre Teile ASIC nennen zu müssen.

 

[Pringel]

Das größte Problem ist IMO dass keine UALink Switches verfügbar sind und dass deswegen UALink über Ethernet betrieben werden muss.

Das ist nur die 1.0. 2.0 macht das bereits weg und ist auch schon durch (!) Ja, Broadcom versucht sich auch zu beeilen. Wird schon

Und beim Implementieren der Hardware stößt man AFAIU an Punkte, die in der Spezifikation nicht eindeutig geregelt sind.

Am Ende steht man eh im engsten Kontakt mit AMD und dann wird das so wie es notwendig ist. Die Spec werden während des Machens noch ergänzt bzw. für die nächste Rev. entsprechend exakter beschrieben.
Das ist noch alles recht lebendig, EBEN weil man sich Hals über Kopf beeilt.

Allen anderen möglichen Akteuren ist schon klar, daß man bis 3.0 sich nur anschauen sollte wie man ggf. den Anlauf nimmt, aber bis Broadcom mit AMD das erst in 2.0 nicht lauffähig haben, man sich dem mit Bedacht nähern sollte
Was auch gerecht ist, imho. Broadcom macht jetzt den größten Teil der Vorarbeit, können dafür also auch erstmal das ordentlichere Stück des Kuchen bekommen. Ist ja auch Eigeninteresse dabei. Nvidia gräbt denen mit dem Monotop im RZ das Wasser ab.

Außer den Daten hat AMD nichts zur MI430X gezeigt. So wie ich das verstehe ist alles bis auf die CCD dasselbe.

👍

Nicht dass ich müsste.

Du musst ja auch nicht, wenn du nicht magst Ich meine aber schon, das irgendwie mehrmals gesehen zu haben.
"xPU" ist wie die Blauen das so meinten, eine ganze Reihe von Sachen. Eher ein Oberbegriff.

Die NVIDIA und AMD bleiben bei GPU um die Programmierbarkeit hervorzuheben. Google hat die TPUs und die anderen reden in letzter Zeit lieber über XPU anstatt ihre Teile ASIC nennen zu müssen.

Ob sich die meisten denken könnten, das Ding wird wohl weniger flexibel sein, weil es XGU statt GPU heißt? Früher versuchte man schon mit GPGPU. Passt halt nur schlecht in die dreibuchstabigen Konventionen. Wie bei Geheimdiensten ja auch

 

[ETI1120]

Das ist nur die 1.0. 2.0 macht das bereits weg. Ja, Broadcom versucht sich auch zu beeilen. Wird schon ...
aber bis Broadcom mit AMD das in 3.0 nicht lauffähig haben, man sich dem mit Bedacht nähern sollte
Was auch gerecht ist, imho. Broadcom macht jetzt den größten Teil der Vorarbeit,

AFAIU ist Broadcom bei UALink nicht an Bord. Bestenfalls als UALink over Ethernet.

Es sind andere Unternehmen die UALink Switches Implementieren. Aber die sind für Helios noch nicht so weit.

Du musst ja auch nicht, wenn du nicht magst Ich meine aber schon, irgendwie schon mehrmals gesehen.
"xPU" ist wie die Blauen das so meinten, eine ganze Reihe von Sachen. Eher ein Oberbegriff (lanciert von Intel).

Ob sich die mesiten denken könnten, das Ding wird wohl weniger flexibel sein, weil es XGU statt GPU heißt? Früher versuchte man schon mit GPGPU. PAsst halt nur schlecht in die dreibuchstabigen Konventionen. Wie bei Geheimdiensten halt

Wie gesagt XGU ist nicht geläufig. Die anderen verwenden XPU.

Es war schon immer so dass Intel eigene Bezeichnungen prägen wollte und meistens damit scheitert.

Also ist es irrelevant was Intel irgendwie nennen will.

 

[Pringel]

@ETI1120
Weil irgendwann, meist 1x die Woche, ich mich auch mal von meiner strunzdummen Seite zeige
Man verzeiht. Letztens zu viel gleichzeitig gelesen. Astera meinte ich. Habe isch wegkorrigiert Sonst noch Upscale AI.
Wobei Broadcom auch im UAlink Konsortium dabei ist.
Der ASIC wird schon pfiffig sein. Keine Frage. Nvidia hat nur 2x etwas wirklich extrem wichtiges für sich eingekauft. Das war 1x 3Dfx und 1x Mellanox... Für 6.9 Mrd. Aus der heutigen Sicht quasi an NV verschenkt.

Ja, aber XGU kommt imho nicht von Intel. Das ist eh pillepalle, aber das ist auch langsam schon bisschen eigen, diese Teile noch GPU zu nennen. Persönlich, ist mir das aber auch egal. Kein Ding.

 

[ETI1120]

Astera meinte ich. Habe isch wegkorrigiert Sonst noch Upscale AI.

Die beiden habe ich IIRC auch auf der Liste.

Wobei Broadcom auch im UAlink Konsortium dabei ist.

Broadcom ist dabei und argumentiert aber IIRC, dass die eigene Implementierung von Ethernet UALink überflüssig macht

Nvidia hat nur 2x etwas wirklich extrem wichtiges für sich eingekauft. Das war 1x 3Dfx und 1x Mellanox... Für 6.9 Mrd. Aus der heutigen Sicht quasi an NV verschenkt.

Man muss aber auch sagen dass Mellanox ohne NVIDIA nicht diesen Impact gehabt hätte. D. h., der NVIDIA selbst hat den Zukauf so wertvoll gemacht.

Ich will nicht wissen was aus Mellanox geworden wäre wenn sie Intel den Zuschlag gegeben hätten.

aber das ist auch langsam schon bisschen eigen, diese Teile noch GPU zu nennen.

Es würde mich wundern, wenn AMD an der eingeführten Bezeichnung GPU etwas ändern.

Es gibt noch einiges an Übereinstimmung mit den Gaming GPUs und deshalb nimmt man halt GPU als Bezeichnung und nicht als Abkürzung.

 

[Pringel]

Broadcom ist dabei und argumentiert aber IIRC, dass die eigene Implementierung von Ethernet UALink überflüssig macht

JA NICHT. Bei Broadcom denke ich direkt an ein Trojanisches Pferd. Hier (für alle)
https://newsletter.semianalysis.com...-uec-ualink-vs-broadcom-scale-up-ethernet-sue

Was 1.0 ja an sich macht, aber irgendwie denken da wohl einige mehr an ein Trojanisches Pferd und lock-in.
AMD kann jedenfalls solche OCP Systemkriege nicht gebrauchen.

Man muss aber auch sagen dass Mellanox ohne NVIDIA nicht diesen Impact gehabt hätte. D. h., der NVIDIA selbst hat den Zukauf so wertvoll gemacht.

Ich will nicht wissen was aus Mellanox geworden wäre wenn sie Intel den Zuschlag gegeben hätten.

Sind die nicht mal Intel gewesen, so, im Groben? Wäre bestimmt genauso gelaufen wie mit Astera.

Ja stimmt schon, aber wenn NV das nicht dringend brauchen würde, dann würden sie es selbt machen. Mellanox hatte einen bestens ins Bild passenden Patentpool und sie hatten auch genug Fachmänner dabei, für das, was NV vorhatte.

Apropos. Während dessen Nvidia:
https://www.golem.de/news/strategis...erproduktion-fuer-nvidia-aus-2605-208409.html