Diskussion zu: Hardware- und Nachrichten-Links des 6. August 2021

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-6-august-2021

[Thomas Gräf]

Wiedermal spannende News, die man auch iwie sehr gerne liest.:smile:

[Lehdro]

Logische Schlußfolgerung von AMDs Chipletstrategie: Alles ist skalierbar, auch Cachedies. Macht sogesehen sehr viel Sinn den auch komplett modular zu fertigen. Nächster Schritt wäre die Cache Dies von GPU und CPU kompatibel zu machen - 1 Die für alles.

[Gast Ritis]

das ist noch alles zu viel ins blaue hinein, hochgradig spekulativ.

ich will folien leaks oder codezeilen sehen die etwas belegen könnten….

[Leonidas]

@Gast Ritis:

Folien sehen wir sicherlich nicht vor Mitte 2022. Codezeilen vielleicht etwas früher.

[tEd]

Es gibt ja noch die Patente.

[Complicated]

Ich denke hier ist das betreffende Patent:
https://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/News/GPU-Chiplets-Neues-AMD-Patent-aktives-Bridge-Design-integrierter-Cache-1369799/
Demnach würde das aktive Bridge-Chiplet dabei als Die-to-Die-Interconnect mit hoher Bandbreite zwischen den GPU-Chiplet-Dies dienen, während es auch als eine Art Speicherquerverstrebung ("memory crossbar") mit einem gemeinsamen, vereinheitlichten Last-Level-Cache (LLC) arbeiten würde. Dieser würde wiederum die Inter-Chiplet-Kommunikation ermöglichen und Chiplet-übergreifende Synchronisationssignale weiterleiten. Mit dem LLC ist in diesem Fall der L3-Cache gemeint, der in der aktuellen RDNA2-Architektur als "Infinity Cache" bezeichnet wird.

AMD erklärt in dem Patent, dass jegliche Inter-Chiplet-Kommunikation über das aktive Bridge-Chiplet geleitet würde, das für den Zugriff auf Speicherkanäle auf einzelnen GPU-Chiplets erforderlich wäre. Darüber hinaus würde sich der gesamte Active-Bridge-Cache ähnlich wie ein monolithischer GPU-Cache verhalten, statt auf einzelne Chiplet-Caches zu setzen: Der Speicher wäre als ein einziges Register adressierbar, was dafür sorgen würde, dass aus Sicht der Software-Entwickler keine Chiplet-spezifischen Überlegungen notwendig sind.

Hier ist wohl das "active bridge-chiplet" der entscheidende Faktor.
https://www.freepatentsonline.com/y2021/0097013.html
Accordingly, as discussed herein, an active bridge chiplet deploys monolithic GPU functionality using a set of interconnected GPU chiplets in a manner that makes the GPU chiplet implementation appear as a traditional monolithic GPU from a programmer model/developer perspective. The scalable data fabric of one GPU chiplet is able to access the lower level cache(s) on the active bridge chiplet in nearly the same time as to access the lower level cache on its same chiplet, and thus allows the GPU chiplets to maintain cache coherency without requiring additional inter-chiplet coherency protocols. This low-latency, inter-chiplet cache coherency in turn enables the chiplet-based system to operate as a monolithic GPU from the software developer's perspective, and thus avoids chiplet-specific considerations on the part of a programmer or developer.

[Leonidas]

Die Patente helfen weiter. Aber nicht immer ist klar, was dafür für HPC und was für Gaming gedacht ist.

[Complicated]

Beides - daher habe ich dies ja zitiert:
The scalable data fabric of one GPU chiplet is able to access the lower level cache(s) on the active bridge chiplet in nearly the same time as to access the lower level cache on its same chiplet, and thus allows the GPU chiplets to maintain cache coherency without requiring additional inter-chiplet coherency protocols. This low-latency, inter-chiplet cache coherency in turn enables the chiplet-based system to operate as a monolithic GPU from the software developer's perspective, and thus avoids chiplet-specific considerations on the part of a programmer or developer.
Die Unterteilung in Chiplets spielt in dem Moment keine Rolle mehr auf Softwareebene- das war ja die Herausforderung für Chiplet-GPUs, die es zu lösen galt. Die GPU muss für Entwickler genau so angesprochen werden wie eine monolithische GPU, auf der anderen Seite mussten die Latenzen für Inter-Chiplets-Kommunikation kaschiert werden, wie Sie beim ersten Zen-Design noch großen Einfluss hatten auf Gaming.

Das heisst vor allem, dass die GPUs mit jeglichen Spielen, die älter sind, keine Probleme haben sollten, ohne Anpassungen zu benötigen in Software/Patches, für das Chiplet-Design. Möglicherweise hängt es mehr am eingesetzten Packaging/Fertigungsverfahren als der Architektur, welcher Schwerpunkt zuerst angegangen wird.

Allerdings wurden ja Aldebaran (CDNA2) schon für dieses Jahr bestätigt. Dort sollen ja 2 GPUs zum Einsatz kommen und die Interconnect Fortschritte wurden explizit erwähnt: https://www.computerbase.de/2021-05/amd-cdna2-veroeffentlichung-mit-grossen-aenderungen-spaeter-im-jahr/
Für die zweite Generation stellt AMD vor allem Optimierungen am Interconnect vor, die die Zusammenarbeit zwischen CPUs und GPUs deutlich verbessern sollen. AMD spricht dabei sogar von einem großen Schritt an Innovationen im Bereich der Datacenter.
Ich vermute, dass die Technologie auch erst mal eine Weile durch die Medien gehen muss, damit der Endkunde da zum Marktstart auch weiß was die Angaben auf der Packung bedeuten für die Performance.

[Gast Ritis]

die aus heutiger Sicht für mich etwas abwegige Behauptung sind die vielen einzelnen Cache Chiplets. Eine Segmentierung des LLC scheint nicht im Sinne einer simplen Speicherverwaltung, noch einer simplen Fertigung. Es sollte nicht wie HBM off Die am Controller bzw xGMI sondern wie V-Cache als 3d Sandwich aufgebaut sein. Der Cache müsste an der Data Fabric zwischen SI und L2 angebunden sein.
Nach dem Zen3 Beispiel wäre das doch eher 64MB on Die und dann ein TSV Stapel Cache oben drauf mit x zus Layern. Bei 2x64 dann jew. 128MB mehr.
Als separates Chiplet doch sicher nur eines, meinetwegen auch gestapelt mit 2 GMI, je eines an die Data Fabric des GPU Chiplet….

[iamthebear]

1.) Dass die MCDs direkt unter den GCDs liegen macht Sinn. Dadurch müssen die Signal von GCD zu MCD nur einige Mikrometer vertikal transportiert werden. Statt z.B. 20mm vertikal am Board von Chip zu Chip.
Ich schätze einmal, dass hier eine ähnliche Technologie wie beim VCache von Zen 3 verwendet wird, nur dass statt mehreren Caches nun Cache + Logik verbunden werden.

Das heißt jedoch umgekehrt, dass weniger Chipfläche zur Abgabe der Verlustleistung zur Verfügung steht.
Navi 21 hat in Summe ca. 500mm² Cache, wobei hier grob 100mm² auf den Infinity Cache enthallen sollten.
Bei Navi 31 mit 3 facher FP32 Anzahl gehe ich von in etwa 2x350mm² für die GCDs und 300mm² für die MCDs aus. Ich denke, dass wir es hier mit maximal 4 MCDs zu tun haben. Kleinere Dies machen denke ich keinen Sinn.

2.) Etwas seltsam finde ich, dass das Speicherinterface im GCD liegt und somit die Hälfte der Speicherzugriffe über ein fremdes GCD laufen müssen. Es wäre doch wesentlich naheliegender diese im MCD zu plazieren und die ankommenden Daten vom VRAM gleich parallel an das GCD und den Cache weiter zu leiten.
Entweder skaliert das Speicherinterface unter 5nm so gut, dass man es nicht in 6nm fertigen wollte oder es hat thermische Gründe, dass man das Speicherinterface (das ja auch einiges verbraucht) nicht unter den heizenden Shadern des GCD plazieren wollte.

[Complicated]

die aus heutiger Sicht für mich etwas abwegige Behauptung sind die vielen einzelnen Cache Chiplets. Eine Segmentierung des LLC scheint nicht im Sinne einer simplen Speicherverwaltung, noch einer simplen Fertigung. Die Behauptung vieler einzelner Cache-Chiplets wurde nirgendwo aufgestellt.
https://www.computerbase.de/2021-04/gpus-im-chiplet-design-amd-patente-bringen-den-cache-ins-spiel/
Der Cache wandert auf die Brücke

Die Besonderheit der „Active Bridge“ besteht darin, dass der L3-Speicher direkt auf der Brückenverbindung und nicht mehr auf dem entsprechenden GPU-Chiplet untergebracht werden soll. Das erklärt auch die aktive Auslegung der Brücke.

Zudem ist die Größe des L3-Cache damit durch die Größe der „Active Bridge“ beliebig skalierbar und ermöglicht Lösungen für Systeme respektive GPUs und Beschleunigern mit wenigen (1 bis 2) oder vielen (3 und mehr) GPU-Chiplets.

Der L3-Cache ist damit auch von der Hitzeentwicklung und dem Stromverbrauch der GPU-Chiplets entkoppelt. Ob der Cache damit tatsächlich besser gekühlt werden kann oder einfach die dezentrale Hitzeentwicklung von Vorteil ist, geht aus der Patentschrift indes nicht hervor.
Die "Active Bride´" ist unter den Chiplets verbaut wie ein Interposer.
https://pics.computerbase.de/9/8/0/5/6-bdd27f887373a9aa/7-630.50d4b26a.png
https://pics.computerbase.de/9/8/0/5/6-bdd27f887373a9aa/5-1080.34003ada.jpg

2.) Etwas seltsam finde ich, dass das Speicherinterface im GCD liegt und somit die Hälfte der Speicherzugriffe über ein fremdes GCD laufen müssen.
Ich denke nicht, dass dies der Fall ist. Laut Dokumenten wird ein GCD als primär definiert zur Anbindung an CPU/Speicher.
Neben einer sogenannten „Active Bridge“, einen aktiven Silizium-Die, der die Verbindung unter den GPU-Chiplets übernimmt, wird einmal mehr ein über alle Chiplets kohärenter L3-Cache sowie ein „Primary Chiplet“ beschrieben, wodurch Programme die GPU auch weiterhin als eine Einheit wahrnehmen.

[Cyberfries]

Die Behauptung vieler einzelner Cache-Chiplets wurde nirgendwo aufgestellt.

Von Bondrewd und Kepler auf beyond3d und Twitter.

Die "Active Bride´" ist unter den Chiplets verbaut wie ein Interposer.

Finde den Begriff nicht gut. Ein Interposer müsste mindestens so groß sein wie die darauf platzierten Chips,
die Active Bridge sollte aber kleiner sein - sich mit den GCD nur teilweise überlappen.

Laut Dokumenten wird ein GDC als primär definiert zur Anbindung an CPU/Speicher.

Dein Bild zeigt doch genau das? - SI im GCD. Ob das sinnvoll ist ist ein anderes Thema....

------------------------------
Ob MCD und Active Bridge tatsächlich das gleiche sind?
Ich hatte zuletzt bereits die Vermutung aufgestellt, dass es neben GCD und MCD noch ein weiteres Element gibt:
Ein ABD (Active Bridge Die) auf das die MCDs gestapelt werden.
In dem Fall wären SI und Cache-Verwaltungs im ABD und MCDs reiner Cache. Könnte erklären warum die Gerüchteküche abwechselnd schreibt:
"Kein SI im GCD" und "Kein SI im MCD"

[Complicated]

SI im GDC - nur einer ist der primäre Controller. Der andere hat keine direkte CPU/Speicher-Anbindung.
Ich denke hier ist das von AMD angewandte Packaging-Verfahren von TSMC beschrieben:
https://www.anandtech.com/Show/Index/16031?cPage=2&all=False&sort=0&page=1&slug=tsmcs-version-of-emib-lsi-3dfabric
https://images.anandtech.com/doci/16031/Advanced%20Packaging%20Technology%20Leadership.mkv_snapshot_11.38_%5B2020.08.25_ 14.14.11%5D.jpg
InFO is TSMC’s fan-out packaging technology, where a silicon die from a wafer is picked out and placed on a carrier wafer, upon which the further bigger structures such as the copper RDL (Redistribution layer), and later the carrier substrate is built upon.

TSMC’s variant of InFO with integration of an LSI is called InFO-L or InFO-LSI, and follows a similar structure with the new addition of it integrating this new local silicon interconnect intermediary chip for communication between two chips.

https://images.anandtech.com/doci/16031/Advanced%20Packaging%20Technology%20Leadership.mkv_snapshot_16.44_%5B2020.08.25_ 14.14.27%5D.jpg

Von Bondrewd und Kepler auf beyond3d und Twitter.
Nicht hier im Thread, ist mein Kontext solange keiner zitiert oder verlinkt ;)

[amdfanuwe]

Die Patente helfen weiter. Aber nicht immer ist klar, was dafür für HPC und was für Gaming gedacht ist.
AMD geht schrittweise vor. Würde mal sagen CDNA2 ist aktuell mit passiver Bridge in Produktion.
RDNA3 kommt dann Ende nächstes Jahres mit aktiver Bridge.
Eines nach dem anderen.

Interessant finde ich die letzten Bilder in den Patenten:
Passiv Bridge:
https://cdn.videocardz.com/1/2021/01/AMD-GPU-Chiplets-FIG5.png
Besteht der Aldeberan Chip womöglich aus 4 Chiplets auf passiver Bridge mit zusammen 128 CUs und HBM und in MI200 werden 2 solcher Chips verbaut?

Aktive Bridge:
https://cdn.videocardz.com/1/2021/04/AMD-Active-Bridge-Chiplet-Patent-Fig5-768x494.png
Hier sind es 3 GPU Chiplets. Die active Bride 118 könnte auch nur jeweils 2 Chiplets miteinander Verbinden, für 3 GPU Chiplets bräuchte man dann eben 2 Bridges.

[Complicated]

Es ist immer eine Bridge die den Cache beinhaltet bei AMD, die unterschiedlich groß dimensioniert ist, wenn ich das richtig interpretiere. Also nicht wie EMIB.

[iamthebear]

Ich denke nicht, dass dies der Fall ist. Laut Dokumenten wird ein GCD als primär definiert zur Anbindung an CPU/Speicher.

Von Computerbase wurde das Patent so interpretiert:

Die Anbindung an den VRAM ist nach wie vor auf dem GPU-Chiplet und nicht auf der „Active Bridge“ untergebracht, während die Verbindung zwischen Brücke und Chiplet über TSVs („Through Silicon Vias“) erfolgt, die durch das Chiplet laufen. Die Brücke selbst besitzt keine Vias, nur Strukturen und Leiterbahnen auf der Oberseite.

Das deckt sich auch mit den Leaks.

Ich muss sagen, dass mit den letzten Leaks das Patent immer mehr als konkreter RDNA 3 Bauplan erscheint und weniger als theoretisches Konstrukt.

Ich denke jedoch, dass das bloß der Anfang ist und der Trend bei RDNA 4 dazu gehen wird statt 3-4 unterschiedlicher DIEs nur mehr GCD und MCD aufzulegen und die jeweiligen Chiplets von Mainstream bis Ultra High End aus denselben Chips in unterschiedlicher Anzahl aufzubauen.

Generell zweifle ich immer noch ein bisschen an 2 verschiedenen High End GCDs (Navi31 und Navi32). Gerade bei Navi 31 werden die verkauften Stückzahlen echt überschaubar bleiben.

[Complicated]

Ich glaub auch nicht an 2 verschiedene GCDs. Wobei die Bridge grösser ausfallen muss bei mehr Cache/GCDs.

[CD-LABS]

Ich halte es angesichts solcher Gerüchte immer noch für Wahnsinn, dass AMD anscheinend an GDDR festhalten möchte. Da betreiben sie derartigen Aufwand um Speicher zu optimieren und nutzen dann keinen HBM?
Chiplet-GPU ohne Hochkapazitätsstapelspeicher ist in meinen Augen das gleiche wie ein niedrigeffizientes Passivnetzteil:
Irgendwie möglich ist es, aber sinnvoll ist es nicht.

[bad_sign]

Ich halte es angesichts solcher Gerüchte immer noch für Wahnsinn, dass AMD anscheinend an GDDR festhalten möchte. Da betreiben sie derartigen Aufwand um Speicher zu optimieren und nutzen dann keinen HBM?
Chiplet-GPU ohne Hochkapazitätsstapelspeicher ist in meinen Augen das gleiche wie ein niedrigeffizientes Passivnetzteil:
Irgendwie möglich ist es, aber sinnvoll ist es nicht.
HBM ist teuer und nur in geringen Mengen verfügbar.
Falls AMD 64MB Caches produziert und bei Zen V3 und RDNA3 nutzen kann, dann haben sie die Möglichkeit RDNA noch kleiner zu machen und gleichzeitig deutlich effizienter
Es kommen bestimmt hunderte dieser 64 MB Slizes aus einem Waver und auch die Ausbeute von 300mm² Chips ggü. 500 mm² dürfte locker das doppelte sein (pro Waver).
Und RDNA hats ja gezeigt, man braucht nur wenig schnellen Speicher und viel langsamen, also warum nur sehr teuren und raren sehr schnellen Speicher wählen?

[CD-LABS]

(...) Falls AMD 64MB Caches produziert und bei Zen V3 und RDNA3 nutzen kann, dann haben sie die Möglichkeit RDNA noch kleiner zu machen und gleichzeitig deutlich effizienter
Es kommen bestimmt hunderte dieser 64 MB Slizes aus einem Waver und auch die Ausbeute von 300mm² Chips ggü. 500 mm² dürfte locker das doppelte sein (pro Waver).
Und RDNA hats ja gezeigt, man braucht nur wenig schnellen Speicher und viel langsamen, also warum nur sehr teuren und raren sehr schnellen Speicher wählen?
Die Cache-DIEs lohnen sich auf jeden Fall gegenüber einem monolithischen Design mit entsprechend vergrößertem Cache. Das steht nicht zur Debatte.
HBM ist teuer und nur in geringen Mengen verfügbar.(...)
Und RDNA hats ja gezeigt, man braucht nur wenig schnellen Speicher und viel langsamen, also warum nur sehr teuren und raren sehr schnellen Speicher wählen?
Es wird viel Aufwand dafür betrieben, die unterschiedlichen Chiplets möglichst gut miteinander arbeiten zu lassen, sie nah an einander heranzurücken. Und dann sollen ausgerechnet die GCD vom Haupt(video)speicher weiter entfernt als zwingend notwendig sein?
Speicher nah heranzuschaffen ist der am besten beherrschte Schritt im Chipletdesigns. Ihn liegen zu lassen ist Blödsinn. Außerdem benötigt AMD dann nicht zig HBM-Stacks und entsprechend viel Interposermaterial, sondern könnte sich gerade in dem Punkt auch mit weniger zufriedenstellen.

[Gast Ritis]

Die Behauptung vieler einzelner Cache-Chiplets wurde nirgendwo aufgestellt..

Du musst halt schon den Artikel hier lesen und nicht andere News bemühen...

Und dies dann in Chip-technisch mehrfacher Ausfertigung, sprich im eigentlichen sind es mehrere MCDs pro Grafikchip. Inwiefern AMD dann offiziell hierfür die Mehrzahl benutzt oder Marketing-technisch von nur "einem MCD" sprich, ist noch nicht heraus. Wie kleinteilig es wird, ist genauso bekannt – aber die Wortwahl seitens Bondrewd läßt wohl darauf schließen, dass es definitiv mehr als zwei Cache-Dies sind, wahrscheinlich eher in Richtung 4 oder 8 Cache-Dies

[Complicated]

Danke Dir, das hatte ich überlesen, daher ist mir der Kontext entgangen.
Ist ja eher Leonidas Interpretation in dem Fall.

[Leonidas]

Naja, eigentlich ist die Original-Aussage klar: "Two GCD and fuckton of MCD."

[Complicated]

Daraus ergibt sich doch nicht:
aber die Wortwahl seitens Bondrewd läßt wohl darauf schließen, dass es definitiv mehr als zwei Cache-Dies sind, wahrscheinlich eher in Richtung 4 oder 8 Cache-Dies
Wo nimmst du die Anzahl Cache-Dies her? Das hat weder mit der Anzahl der GCD noch MCD zu tun.

Laut AMD Patent ist das eine "bridge", die je nach Bedarf unterschiedlich in Cache/Größe ist, damit mehr GCD obendrauf Platz finden können und miteinander Kohärenz herstellen beim LLC.

[Leonidas]

"Fuckton" sind nicht nur 2. 4 oder 8 ist daher wahrscheinlich, weil zu viele werden es auch nicht sein. Dies ist natürlich nur eine Überlegung.

[Complicated]

Ich denke ich interpretiere das "fuckton" nicht auf die Anzahl der Dies, sondern die Menge des Caches in der Bridge/MCD. Wenn das wie bei TSMC gefertigt wird, dann ist das Wafer-on-Wafer. Da entstehen vorher keine Dies:
https://3dfabric.tsmc.com/english/dedicatedFoundry/technology/SoIC.htm#SoIC_WoW
https://3dfabric.tsmc.com/site_img/dedicatedFoundry/services/WLSI_SoIC-WoW_1.png

Hier muss man sich vielleicht andere Bezeichnungen überlegen zur Unterscheidung. EMIB-Bridges werden ja auch nicht als Die bezeichnet. Das hier sind aktive Bridges mit Cache bestückt auf einem MCD.

Die fertigen GCDs (rot) kommen dann auf den MCD (grau), wie auf der ersten Grafik (a) mit 2 oder 4 GDCs
Navi33 könnte wie auf (b) dargestellt aussehen:
https://3dfabric.tsmc.com/english/dedicatedFoundry/technology/SoIC.htm#SoIC_CoW
https://3dfabric.tsmc.com/site_img/dedicatedFoundry/technology/SoIC/SoIC-chips.jpg

Das würde dann identische GCDs bedeuten und unterschiedliche MCDs, je nach SKU. Eigentlich genial, da die Komplexität der aktiven Bridge+Cache deutlich kleiner sein sollte und verschiedene Dies hier weniger kosten. Vor allem ist dann wieder Salvage von teildeaktivierten GDCs möglich.

[Gast Ritis]

Ich denke ich interpretiere das "fuckton" nicht auf die Anzahl der Dies, sondern die Menge des Caches in der Bridge/MCD.

So hätte ich diese englische Phrase auch interpretiert. Eine Tonne Cache ist sehr viel gemessen in MB, eher nicht gemessen an Chiplets.
Unterschiedliche MCDs wären IMHO nur notwendig um SKUs zu unterscheinden, nicht um ein SKU zusammen zu stellen.

[Leonidas]

Ok, ich habe mich möglicherweise da zu sehr in eine Richtung treiben lassen. Bondrewd verwendete kurz zuvor auch das Wort "MCDs" (also Mehrzahl) ... aber das könnte natürlich auch einfach nur unterschiedliche MCDs für N31 und N32 bedeuten, keine Mehrzahl pro Grafikchip.

Warten wir es mal ab. Rein technisch hat die Mehrzahl allerdings höhere Chancen, da AMD gern diese kleineren Chiplets auflegt, gerade wenn jene funktional identisch sind (siehe 3D V-Cache).

[Gast]

Ich denke ich interpretiere das "fuckton" nicht auf die Anzahl der Dies, sondern die Menge des Caches in der Bridge/MCD.

Also so wie es geschrieben wurde bezieht sich das "fuckton" doch ziemlich eindeutig auf die Anzahl der DIEs, ansonsten hätte er "a fuckton of cache" geschrieben.

[Leonidas]

Wenn man den MCD als Cache ansieht, klappt es allerdings mit der anderen (sprachlichen) Auslegung. Beides ist denkbar.

[Complicated]

Es gibt halt keine Cache Dies, wenn sie Wafer-on-Wafer nutzen um die Bridge/Cache auf den MCD zu integrieren. Erst mit dem "Dicing for Packaging" entsteht der komplett Integrierte MCD-Die.

https://3dfabric.tsmc.com/site_img/dedicatedFoundry/services/WLSI_SoIC-WoW_1.png