News AMD Instinct MI350 Serie: 288 GByte HBM3E, CDNA-4-Architektur und bis zu 1.400 Watt

[DevPandi]

@racer3 Nein, weil AMD bei CDNA alles "gekillt" hat, was speziell nur für die Grafikdarstellung benötigt wird. Darunter Fallen Textureinheiten, ROP (Raster-OPeration-Units), Geometriy-Processor. CDNA ist durchgängig auf HPC-Berechnungen ausgelegt.

AMD wird aber mit RDNA 5 / UDNA CDNA und RDNA wieder zusammenführen. Meine Schätzung ist, dass RDNA als Grundaufbau genommen wird und dann aktuelle Eigenheiteten wie die Matrix-Kerne dann nach RDNA überführt werden.

 

[ETI1120]

@DevPandi
Enosemi bietet AFAIU den Physical Layer

Enosemi ist spezialisiert auf Co Packages Optics sie haben Transmitter und Receiver Chiplets für 16 x 112G dazu kommt noch einiges an IP.

Die RX und TX chiplets sind in Produktion aber der Großteil der IP ist verifiziert aber noch nicht in Produktion i.

Die Foundry ist übrigens GF.

So wie ich es verstehe braucht AMD Broadcom um das Infinity Fabric auf das Rack auszuweiten, Broadcom soll die Switches bereitstellen. Das wurde im Dezember 2023 verkündet. Dann wurde das zu UALink ausgeweitet. Wobei UALink auf 212,5 GT/s je Lanes setzt.

ULS sind die UA Lin Switches.

Würde sich von dieser Basis auch eine Desktop Grafikkarte ableiten lassen oder sind das unterschiedliche Welten? Es ist ja immer noch von GPUs die rede. Frage für einen Freund 🙃

Von der MI250 gibt es eine PCIe Steckkarte.

https://www.amd.com/en/products/accelerators/instinct/mi200/mi210.html

Die MI300X gibt es bisher nur als OAM module. Und das wird wohl auch bei der MI350X der Fall sein.

Falls die Frage war ob man Games darauf laufen lassen kann --- nein. Bei den AI Beschleunigern fehlt die gesamte Fixed Function Hardware (TMU, ROP) der Gaming GPUs. Von den Treibern fangen wir gar nicht erst an.

Bei AMD sind diese Producte übrigens unter Accelerators und nicht unter Graphics einsortiert:

Ein bisschen seltsam ist übrigens die Übernahme des Teams hinter Untether AI. Die Firma gibt es weiterhin, aber sie ist nicht in der Lage die bisherigen Produkte anzubieten und zu supporten.

AMD hat Brium gekauft als die noch im Stealth Mode waren. Deshalb gibt es zu Brium nur das was im AMD Corporate Blog zu Brium steht.

https://www.amd.com/en/blogs/2025/amd-acquires-brium-to-strengthen-open-ai-software-ecosystem.html

 

[Wurstpeller]

Wäre die Leistung dieser AMD Instinct MI350 ausreichend für Cyberpunk 2077 Phantom Liberty für 4K240fps + Ultra Setting während ich in Dogtown mit dem Auto umher fahre ?

 

[stefan92x]

@Wurstpeller Keine RT-Einheiten.
Keine Einheiten um wirklich ein Bild auszugeben.

Der Teil, der mit einer normalen GPU vergleichbar ist dürfte schnell genug sein - aber es fehlt einfach noch ganz viel an Fähigkeiten, was eine Radeon hat, die Instinct aber nicht.

 

[ETI1120]

Ach ja AMD holt weiter Leute:
https://x.com/realSharonZhou/status/1932817096510931380?t=NKe_XuZiFtiVqde1A0LzcQ&s=19

Sie war auch schon bei AI Events von AMD.

 

[input_iterator]

Nicht zwingend, im Superpod werden 567 GPUs (Nvidias Zählweise) über ein zweites Layer NV-Link vernetzt.

Da es ja um die MI360 Serie geht, bin ich von AMD ausgegangen.

 

[lynx007]

Und was macht man bei über 72 GPUs? Da muss man dann wie bei AMD auch aufs Ehternet zugreifen?

Clustern! Scalliert aufgrund der höheren Latenz aber nicht gut. Oder man greift zu Cerebras. Was aber wieder richtung Mainframe geht, wo man sich die Software selber Schreiben darf damit es richtig funktioniert. Das ist dann richtig teuer und eine sehr spezielle Lösung. Stichwort: Mainframe.

https://en.wikipedia.org/wiki/Cerebras

Deshalb verdient sich NV auch gerade nen Wolf, weil sie praktisch alternativlos sind.

 

[Shoryuken94]

Meine Schätzung ist, dass RDNA als Grundaufbau genommen wird und dann aktuelle Eigenheiteten wie die Matrix-Kerne dann nach RDNA überführt werden.

Das sollte dann eine ähnliche Startegie sein, den Nvidia mit Turing gemacht hat? Bzw eine Rückbesinnung richtung GCN.

 

[ETI1120]

@Shoryuken94 CDNA ist GCN plus Matrixkernen, bisher liefen alle CDNA unter GFX9 wie auch Vega.

 

[DevPandi]

Das sollte dann eine ähnliche Startegie sein, den Nvidia mit Turing gemacht hat? Bzw eine Rückbesinnung richtung GCN.

Ich glaube nicht, dass mit UDNA "GCN" zurück kommt vom Aufbau her.

Leider hat sich in den letzten Jahren durch die Aufsplittung von GCN in CDNA und RDNA da ein Narrativ gebildet, dass so nicht richtig ist: GCN wäre gut für Compute, RDNA gut für Grafik. Das ist so aber nicht richtig. RDNA 1 war damals in OpenCL und Co langsamer, was zu großen Teilen den "fehlenden" Shadern geschuldet war. Mit 2560 Shandern in den neuen Vec32 konnten weniger Wave64-Fronten allgemein abgearbeitet werden und noch mal weniger durch den neuen Aufbau. Gleichzeitig ist aber der FP-Output auf die Anzahl der Shader nicht wirklich gesunden.

2560 / 32 = 80 Wave64-Fronten, 2560 / 16 = 160 Wave64-Fronten. Aber 2 Takte gegen 4 Takte. Vega 64 und Vega 7 waren primär schneller, weil sie mit den 4096 Kernen eben 256 Wavefronten bearbeiten konnten in 4 Taktzyklen, statt "nur" 80 in 2 Taktzyklen. Der Output war allgemein größer.

Allerdings arbeitet Nvidia mit Warp32 und viele - auch im HPC-Markt - viele Workloads eben auf Warp32 optimiert und bei Warp32 - AMD nennt das dann Wave32 - ist RDNA gegenüber GCN im Vorteil. Dazu kommt, dass Wave64 in 1 - 2 Takten bearbeitet werden - je nach Belegung der Operation.

AMD hatte 2019 mit Erscheinen von RDNA bereits angekündigt, dass früher oder später CDNA und RDNA wieder zusammen geführt wird und RDNA eben keine "HPC"-Schwäche hat.

Wir werden also bei RDNA 5 / UDNA also eher sehen, dass die CU/WGP von RDNA übernommen werden, und aktuell die CDNA-Entwicklungen in die mit RDNA geschaffene Struktur übergehen.

Das sind natürlich nur Vermutungen, will AMD aber auch im HPC-Markt Nvidia stärker angreifen, müssen sie eine gewisse strukturelle Nähe zu Nvidia einhalten, damit Code mit HIP und ROCm relativ einfach auch transformiert werden kann. Denn die vielen Entwickler werden nicht für "GCN" und "RTX" optimieren, die werden im Zweifel immer RTX wählen und AMD müsste dann mit dem Hip-Transpiler den Code von Warp32 auf Wave64 optimieren und DAS funktioniert immer nur bis zu einem gewissen Grad gut.

 

[Piktogramm]

Wir werden also bei RDNA 5 / UDNA also eher sehen, dass die CU/WGP von RDNA übernommen werden, und aktuell die CDNA-Entwicklungen in die mit RDNA geschaffene Struktur übergehen.

Hättest du bitte noch eine Vermutung, wie der FP64-Durchsatz bei UDNA geregelt sein wird? GPUs für den Endkundenmarkt sind ja bereits länger mit 1:16 FP32 zu FP64 Leistung ausgestattet, während bei CDNA 1:2 bzw. bei Matrixperationen 1:1 bei FP64 angesagt ist.

Ich sehe da alsbald eine Dreiteilung. GPUs mit einem Schwerpunkt auf FP[4;6;8;16] für neuronale Netzwerke, FP32 für Grafik und FP64 für Simulation.

 

[ETI1120]

@DevPandi
Könnte darauf hinweisen dass Du richtig liegst:

https://x.com/Kepler_L2/status/1933118158207963285?t=sIB79xLtt4TvxDJTuqAWvg&s=19

 

[DevPandi]

Hättest du bitte noch eine Vermutung, wie der FP64-Durchsatz bei UDNA geregelt sein wird?

Es spricht eigentlich in der Regel nichts dagegen, dass AMD ihre Matrix-Kerne als auch Vecktor-ALUs einmal "vereinheitlicht", gleichzeitig jedoch auf dieser Basis "zwei" Ableitungen vornimmt für Radeon und Instinct.

Der "logische" Aufbau zwischen einer Vec32, die FP32 und FP16 sowie eben FP8, FP4 beherrscht und einer die zusätzlich noch FP64 beherrscht, ist ja weitgehend gleich. In der Softwareprogrammierung kann man ja auch mit Templates arbeiten, die die eigentliche Logik beinhalten, dann aber für Unterschiedliche-Datentypen genommen werden. FP64 zusätzlich wird ja erst im Chip relevant, wenn die Bits in der Vec-ALU sowie Register-File und Co vorhanden sein muss.

Man wird allerdings abwarten müssen.

Könnte darauf hinweisen dass Du richtig liegst:

Für mich gibt es da noch ein Punkt: AMD hat den Radeon-Treiber und MESA ja für Wave32 ertüchtigt. Wenn man bei UDNA/RDNA 5 wieder zurück auf GCN geht, wäre das nach knapp 8 Jahren wieder ein umfassender Treiber umbau. Nvidia hat halt den Vorteil, das die quasi seit Tesla/GeForce 8800 GTX mit Warp32 fahren und darauf den Treiber auch optimiert haben.

Mit dem Rückgang auf GCN würde man das, was sich AMD seit 2019 nun erarbeitet hat an Optimierungen, wieder über Board werfen. In meinen Augen wäre das schon fast Selbstmord.

 

[ETI1120]

FP64 zusätzlich wird ja erst im Chip relevant, wenn die Bits in der Vec-ALU sowie Register-File und Co vorhanden sein muss.

IIRC geisterte vor zwei Monaten durchs Netz, dass es einen Parameter geben soll

Man wird allerdings abwarten müssen.

Vielleicht wissen wir schon nachher mehr.

Für mich gibt es da noch ein Punkt: AMD hat den Radeon-Treiber und MESA ja für Wave32 ertüchtigt. Wenn man bei UDNA/RDNA 5 wieder zurück auf GCN geht, wäre das nach knapp 8 Jahren wieder ein umfassender Treiber umbau. Nvidia hat halt den Vorteil, das die quasi seit Tesla/GeForce 8800 GTX mit Warp32 fahren und darauf den Treiber auch optimiert haben.

Der erforderliche Umbau könnte auch ein Grund dafür gewesen sein, dass AMD bei CDNA GCN fortgeführt hat. Bei der Aufholjagd für HPC wäre dieser Umbau in den Treibern eventuell zu zeitraubend gewesen. Bei HPC waren die Auslastungsprobleme eventuell nicht so gravierend, dass man damals dem Weg von RDNA folgen musste. Aber irgendwann ...

 

[Piktogramm]

Der "logische" Aufbau zwischen einer Vec32, die FP32 und FP16 sowie eben FP8, FP4 beherrscht und einer die zusätzlich noch FP64 beherrscht, ist ja weitgehend gleich.

Bei dem bisschen Grundlagenkram der mit bekannt ist zur Implementierung von FPUs in Gattern kann ich den "weitgehend gleich"-Teil nicht nachvollziehen.

Quelle: https://www.cs.umd.edu/~meesh/411/CA-online/chapter/floating-point-arithmetic-unit/index.html
Edit: Und das ist nur die Multiplikation, alles mit Addition wird bei Floats ja schnell aufwendiger.

Mir ist auf die Schnelle nicht ersichtlich, wie da "weitgehend gleich" zustande kommt. Da muss man nach meinem Verständnis für jeden Datentyp schon einige Gatter zusätzlich aufwenden mit jedem zu unterstützendem Datentyp. Da wir derzeit FP4, 2x FP6, 2x FP8, 2x FP16, FP19 (Tensorfloat), FP32 und FP64 etabliert haben sehe ich da allerhand zusätzliche Komplexität.

 

[DevPandi]

Mir ist auf die Schnelle nicht ersichtlich, wie da "weitgehend gleich" zustande kommt.

Nun ja, für die meisten Datentypen teilt sich Radeon und Instinct ja die Fähigkeiten bei den VALU. So kannst du auch in modernen Sprachen zur Hardware-Entwicklung Code kapseln und vererben aber auch Teile zusammen zu führen.

So wäre es durchaus möglich - ich komm jetzt mal aus meiner Programmierung - eine Klasse als VALU zu haben, die dann alles bis FP32 implementiert und dann eine Ableitung die noch FP64 hinzufügt.

 

[Piktogramm]

@DevPandi
Beim Schreiben von Code (egal ob Software, oder Hardwarebeschreibung) sehe ich das ja noch. Bei der Synthese sehe ich aber nicht, wie da die Unterstützung von zig Datentypen nicht einen deutlichen Mehrbedarf an Gattern bedingt.
Naja, wir werden sehen was es geben wird und an sich ist mein Kopf eh gerade zu breiig um mir ein entsprechendes Paper zu geben..🫩

 

[DevPandi]

Bei der Synthese sehe ich aber nicht, wie da die Unterstützung von zig Datentypen nicht einen deutlichen Mehrbedarf an Gattern bedingt.

Das ist aber auch das was ich meinte.

Auf Codeebene werden sie CDNA und RDNA zusammen führe, werden dann aber eben für Instinict und für Radoen unterschiedliche Chips daraus ziehen.

 

[ETI1120]

Die Zeiten um Prozessoren auf Gatterebene anzuschauen sind eigentlich vorbei. Die Blöcke die man anspricht haben eine gewaltige Anzahl an Transistoren.

Für RDNA2 und RDNA3 habe ich Daten, für RDNA4 leider nicht, auch nichts zu CDNA:

https://x.com/Locuza_/status/1602396626412503040/photo/1

Die Transistorzahl je WGP von RDNA3 hat gegenüber RDNA2 massiv zugelegt.