News AMD CDNA 2 Whitepaper: Mehr Details zum Compute-Monster Instinct MI200

[Colindo]

@Locuza Ah ok, da liegt der Fehler: Ich kann nicht lesen. Dann hätten wir es jetzt

 

[Oberst08]

Wo es bei mir aber gerade hängt: Eine FP64 Einheit kann doch gleichzeitig zwei Operationen mit FP32 ausführen. Ist es hier nicht irgendwie verschenkte Leistung nicht auf 2:1 zu gehen?

Steht im Text:

Mittels Rapid Packed Math (RPM) können, bei angepasstem Code, zwei FP32-Berechnungen gleichzeitig pro ALU durchgeführt werden.

Dann hat sie also 95,7 TFlops

 

[Onkel Föhn]

Und die Aktie steigt und steigt und steigt. Tolle News.

I like this 2

MfG Föhn.

 

[gedi]

Mir sind zwei Artikelfehler aufgefallen:

	AMD CDNA1	AMD CDNA2	Nvidia Turing	Nvidia Ampere
Datenformat	1. Gen Matrix Core	2. Gen Matrix Core	1. Gen Tensor Core	3. Gen Tensor Core
Matrix FP64 (FLOPS)	N/A	64	N/A	N/A
Matrix FP32 (FLOPS)	64	64	N/A	256
Matrix TF32 (FLOPS)	N/A	N/A	N/A	256
Matrix FP16 (FLOPS)	256	256	128	512
Matrix BF16 (FLOPS)	128	256	N/A	512
Matrix INT8 (OPS)	128	256	N/A	1024

Der INT8-Durchsatz ist bei CDNA2 nicht schneller geworden, bei CDNA1 lag dieser ebenso bei 256 ops pro Matrix-Core bzw. 1024 ops pro Compute Unit mit vier Matrix Cores.
Bei CDNA1 war nur BF16 half-rate im Vergleich zum FP16-Durchsatz.
Bezüglich Nvidia spricht der Text richtigerweise V100 an (Volta), in der Tabelle wurde aber Turing/Ampere niedergeschrieben.

In den Bezug auf den Durchsatz hat die Tabelle davor die richtigen Zahlen verwendet:

Datenformat	MI100	MI250X*	A100
Standard-ALUs
Vector FP64 (TFLOPS)	11,5	47,9	9,7
Vector FP32 (TFLOPS)	23,1	47,9	19,5
Vector FP32 RPM (TFLOPS)	N/A	95,7	N/A
Matrix-Einheiten
Matrix FP64 (TFLOPS)	N/A	95,7	N/A
Matrix FP32 (TFLOPS)	46,1	95,7	156
Matrix FP16 (TFLOPS)	184,6	383	312
Matrix BF16 (TFLOPS)	92,3	383	312
Matrix INT8 (TOPS)	184,6	383	624

Int8 - Schnittstellenspezifisch?

 

[Locuza]

Int8 - Schnittstellenspezifisch?

Ja, es hängt von der Software ab, welche Datenformate unterstützt werden und ob die Matrix-Einheiten verwendet werden.

 

[basix]

A100 kann doch auch FP64 via Tensor-Cores? 19.x TFlops FP64

 

[PS828]

@basix ist halt viel weniger als das Ding hier. Nvidia hat FP64 eigentlich immer vernachlässigt bis auf ganz wenige Ausnahmen eben weil es nicht immer benötigt wird

 

[Locuza]

A100 kann doch auch FP64 via Tensor-Cores? 19.x TFlops FP64

Korrekt, es sind 19.5 TFLOPs was den FP64-Matrix-Durchsatz angeht, genauso hoch wie der FP32 Vektor-Durchsatz.

Edit: Noch eine andere Sache, die Matrix-Einheiten von Nvidia unterstützen nicht direkt FP32-Matrix-Operationen.
Der angegebene Durchsatz von 153 TFlops basiert auf TF32 (Tensor Float 32), was ein 19-Bit Format ist, anders als der Name suggeriert.

 

[BDR529]

Hoffentlich kann AMD hier ordentlich nachziehen, damit Nvidia nicht weiterhin freche Preise im professionellen Bereich verlangen kann. Wer sich etwas mit der Materie auskennt, der wird genau wissen was ich meine. Leider müssen natürlich auch die Serverhersteller nachziehen. Ohne Zertifizierungen oder eine ausreichende Anzahl Serverhersteller, die dann auch Systeme mit diesen Karten anbietet, wird AMD leider nur sehr schleppend voran kommen.

 

[Colindo]

@basix @Locuza Die Tabelle aus dem Ampere Whitepaper kennt ihr ja wahrscheinlich

Sieht so aus, als hätten sie mich mit dem TF32 Tensor getäuscht, da habe ich wohl FP32 gelesen. Aber wer kann mir denn erklären, warum die Tensor Cores FP64 können, aber nicht FP32 mit mindestens der gleichen Geschwindigkeit? Man kann die Register doch einfach halb füllen, wie sonst auch?

 

[Ayo34]

Abgesehen davon das die Karte für den professionellen Einsatz gemacht ist, zeigt es deutlich, dass im Grafikkartenmarkt noch einiges drin ist. Bin wirklich auf die nächste Generation gespannt.

 

[Skysnake]

Nebenbei: Weißt Du vielleicht, woher das "4x4" kommt? Hat das was mit der weiten Verbreitung von SSE zu tun oder sowas?

Das 4x4 lässt sich halt schön realisieren und ergibt ein sauberes sheduling für die Werte. Das sind ja am Ende Schieberegister die entsprechend hardcoded verschaltet sind, damit am Ende ne Mateixoperarion bei raus kommt.

@PS828 FP128 wird im Whitepaper nirgendwo erwähnt

Ich hab nachgeschaut und nichts gefunden. Kannst du das mal bitte nachschauen? DAS wäre ein Mega Ding wenn die FP128 unterstützen würden. Das traut sich quasi keiner mehr.

@Colindo sowas ist bisher auch einfach CPU Gebiet und wird für sehr große zahlen benutzt die anders nicht in einer sinnvollen Numerik berechnet werden können. Mal sehen ob man in dem Zusammenhang hier noch was mitbekommt davon. Dieses FP64 Register bietet sich ja schon dafür an das Problem zu Teilen bzw die Zahl auf zwei Register aufzuteilen

FP128 braucht halt fast keiner und daher könnten x86 CPUs das noch nie. Die NEC Vektorsysteme und IBM Power konnten das genau wie manche anderen auch. Es war/ist aber soooo exotisch, das es sich nicht lohnt und man es lieber spart und die Leute die es wirklich brauchen halt in Software FP128 rechnen und einfach mehr Kisten kaufen fürs gleiche Geld.

@basix @Locuza Die Tabelle aus dem Ampere Whitepaper kennt ihr ja wahrscheinlich
Anhang anzeigen 1149140
Sieht so aus, als hätten sie mich mit dem TF32 Tensor getäuscht, da habe ich wohl FP32 gelesen. Aber wer kann mir denn erklären, warum die Tensor Cores FP64 können, aber nicht FP32 mit mindestens der gleichen Geschwindigkeit? Man kann die Register doch einfach halb füllen, wie sonst auch?

Naja, das ist ein anderer Verschaltungsaufwand für die Schieberegister. Das ist quasi der umgekehrte Fall von Rapid packed math.

So und jetzt noch was allgemeines. Ich bin leider nicht so glücklich über den Artikel. Die Erklärung mit full rate FP64 ist aus meiner Sicht einfach falsch. Man macht das normal nicht, weil es einfach ein zu hoher Aufwand in den ALUs ist. Warum? Nimm dir einfach nen Buch der technischen Informatik und schau dir da an, wie man FP ALUs überhaupt aus INT addieren und Multiplizierern verschiedener Breit baut. Angefangen beim 2Bit addierer/multiplizierer. Dann erkennst du auch, das es sehr wenig Aufwand ist aus einer FP64 ALU eine zu machen die 2xFP32 kann. Der Punkt mit den Registern ist davon völlig abgekoppelt. Wenn wie du ja hier siehst kann man auch rapidpackedmath machen. Das ändert an den ALUs erst mal nichts sondern an deren Anbindung ans Registerfile. Also die Anzahl der read write Ports.

So ich belasse es hierbei lieber mal, da es bei mir inzwischen auch bald 10 Jahre her ist das ich das selbst gemacht habe. Ich denke bis hier hin sollte es aber klar sein, was da Ursache und Wirkung ist.

Und ja mir ist bekannt das NVIDIA meint sie hätten dedizierte FP64 Alus in verschiedenen Produkten. Aber denen glaube ich das nicht, so lange es nicht bewiesen ist. Schauen wir mal was in 10-20 Jahren dazu noch kommt.

PS wenn es noch fragen gibt gerne per PM aber sonst artet das hier aus.

 

[Rage]

@Skysnake Ich bräuchte die Info zu den Tensorcores als verlässliche Quelle, wenn das geht

 

[PS828]

@Skysnake das mit FP128 bei CPUs bezog sich auch auf Software-Lösungen.

Aber es stimmt, wenn die Dinger hier das können wäre das besonders

 

[Skysnake]

@Skysnake Ich bräuchte die Info zu den Tensorcores als verlässliche Quelle, wenn das geht

Was meinst du?

@Skysnake das mit FP128 bei CPUs bezog sich auch auf Software-Lösungen.

Aber es stimmt, wenn die Dinger hier das können wäre das besonders

Nö, es ist nur interessant wenn es in Hardware wäre. Software sollten auch schon alle OpenCL GPUs können. Nur hat sich niemand den Stress gemacht das zu implementieren

 

[Rage]

@Skysnake Ich würde gerne einen Artikel über Tensoren und Tensorcores schreiben. "Tensor" ist so ein hippes Buzzword, dass ich da gerne etwas Licht ins Dunkel bringen würde. Dafür wäre es gut, mit verlässlicher Quelle was dazu sagen zu können, warum Tensorcores gerade das beschleunigen, was sie beschleunigen. Woher kommt gerade die Größe? Sind das spezielle Anforderungen verbreiteter Software? Lässt sich die Größe gut füttern? Oder ist es rein pragmatisch, weils halt gut so machbar ist?

 

[ETI1120]

Wo steckt man dieses Würfelformat (OAM) drauf?

Das "Würfelformat" ist Prozessor + Kühler(bleche)

Serve the Home hat ein paar Bilder der MI 250X, die sie auf der SC21 aufgenommen haben.

Auf diesen Bilder entfällt der Backstein, da hier eine Wasserkühlung verwendet wird.

Gerade wenn AMD mehr in Richtung KI vorstoßen möchte sind FP16 bis INT8 alles andere als unwichtig.

Natürlich kann man die brachiale Rechenleistung der MI 200 auch für Machine Learning verwenden, aber AMD hat die MI 200 mit dem Fokus auf HPC entwickelt. Aus dem ersten Abschnitt des Whitepapers zu den Matrixcores:
Die AMD CDNA™ 2 Architektur Matrix Core Technologie wurde ebenfalls verbessert, wobei der Schwerpunkt auf High-Performance Computing liegt. Die AMD CDNA 2 Matrix Core Technologie unterstützt jetzt Double-Precision-Daten, die für viele wissenschaftliche Berechnungsanwendungen entscheidend sind. Die Matrix-Matrix-Multiplikation ist eines der wichtigsten Primitive, die in HPC-Kernels genutzt werden können. Ihre beschleunigte Implementierung kann die Ausführung von HPC-Anwendungen, einschließlich des wichtigen High Performance Linpack (HPL), beschleunigen.

Übersetzt mit www.DeepL.com/Translator (kostenlose Version) Hervorhebung von mir

Natürlich ist der Markt für scientifc computing kleiner als der Markt für Machine Learning. Aber irgend wo musste AMD den Einstieg schaffen. Und dies gelingt nur, wenn man sich auf ein Ziel konzentriert. Die Aufträge für Frontier und El Capitan waren der Einstieg.

Es wird interessant sein zu sehen, wie sich CDNA 3 entwickelt:

• Den Fokus auf scientific computing beibehalten
• Die Stärken in scientific computing beibehalten aber den Fokus um machine learning erweitern

Allerdings sollte man auch berücksichtigen, dass AMD den Kauf von Xilinx anstrebt. Xilinx ist sowohl in HPC als auch in ML aktiv, hat aber eine komplett andere Herangehensweise an diese Märkte.
Serve the home berichtet über eine neue Beschleunigerkarte von Xilinx.

 

[Colindo]

Die Stärken in scientific computing beibehalten aber den Fokus um machine learning erweitern

Ich könnte mir auch vorstellen, dass man andere Matrix-Cores mit Fokus auf INT8 und FP16 entwickelt, die dann in RDNA3 einfließen können. Dann würden deren Workstation-Varianten auch für entsprechende Entwicklungen verwendet werden können. Damit wären dann CDNA und RDNA sehr deutlich voneinander abgegrenzt, was GPU-Compute bzw KI angeht.

 

[Skysnake]

Ich würde gerne einen Artikel über Tensoren und Tensorcores schreiben. "Tensor" ist so ein hippes Buzzword, dass ich da gerne etwas Licht ins Dunkel bringen würde.

Naja, der Begriff des Tensors kommt ja aus der Physik und da sind es halt einfach Matrizen mit gewissen Eigenschaften. Am Ende läuft es im wesentlichen auf BLAS raus. Also Matrix Matrix Operstionen. Mehr steckt da in diesem Zusammenhang mit IT eigentlich nicht dahinter. Mir wäre zumindest nicht bekannt, das man jetzt irgendwelche speziellen Besonderheiten in der Abgrenzung von Tensor und Matrix durch den Kontext der beiden Begriffe verwenden würde.

Dafür wäre es gut, mit verlässlicher Quelle was dazu sagen zu können, warum Tensorcores gerade das beschleunigen, was sie beschleunigen.

Im wesentlichen läuft es darauf raus einfachere Einheiten zu machen die nicht beliebige Operationen durchführen können sondern eben nur fest definierte Matrixoperationen.

Schau dir einfach mal an, was die ISA so an Instruktionen bereithält. Eine Sache wird da die Mateixmultiplikation sein. Und da hast du viel Datenreuse und eben ein fixes Schema wie darauf zugegriffen wird. Und genau dieses Schema ist halt in den Tensor Cores implementiert. Daher bekommst du die maximalen Flops auch nur raus, wenn du halt genau die Operation machst. Zudem hast du halt fixes Matrizengrößen von 4x4. Alles was du nicht brauchst weil dein Problem z.b. nur 3x3 ist wird entweder mit Einsen bzw Nullen aufgefüllt oder halt ausgeblendet. Man verliert meines Wissens aber eben an Durchsatz, weil man die Units nicht richtig nutzt, bzw die halt einfach zu start/unflexibel sind für allgemeinere Formate.

Woher kommt gerade die Größe?

Naja, 4x4 lässt sich schön. Darstellen in binär als auch thermocode. Zudem ist 4x4 nicht zu groß. Man hat also nicht oft viel Verschnitt durch eigentlich kleinere Matrizen.

5x5 wäre noch so was, aber das ist nicht so schön und hat ja schon 25 statt 16 Felder. Und 6x6 dann sogar schon 36.

Du siehst das wird einfach schnell viel zu groß. Vor allem weil man vor allem mit den kleinen Matrizen zu kämpfen hat bei den GPUs. Das bekommst du nur bedingt gut umgesetzt. Bzw es ist einfach lästig. Schau dir mal an wie die Performance für kleine Matrizen aussieht bei den blas libs. Die ist nicht so berauschend. Zudem findet man da immer mal noch Fälle wo Leute schneller sind als die BLAS lib. Man kann da halt manchmal einfach sehr spezielle Dinge machen, weil es halt genau noch in nen Cache oder das Registerfile passt. In Blas ist das aber doof, weil man dafür extra controlflow brüchte, der dann aber zu viel overhead erzeugen würde....

Sprich man nutzt hier halt auch einfach aus, das man das Problem das man löst sehr stark vereinfacht/limitiert. Es ist also sehr genau bekannt welche Art von Problem man genau lösen muss. Und das macht es halt einfacher die Hardware dafür zu bauen uns zu optimieren.

Sind das spezielle Anforderungen verbreiteter Software?

Und AI ist wohl 3x3 sehr beliebt. Dafür ist 4x4 eigentlich etwas zu groß, aber egal. 5x5 soll aber wohl auch in manchen Bereichen beliebt sein. Da geht man dann aber halt eher auf die normalen Units würde ich sagen.

Lässt sich die Größe gut füttern?

Siehe oben. Im Prinzip ein Jaien.

Oder ist es rein pragmatisch, weils halt gut so machbar ist?

Das sollte der Hauptgrundsein. Es ist halt ein tradeoff bezüglich der Implementierungskosten und des Nutzens. Und da ist 4x4 halt nen guter Sweetspot. Aber klar, wenn da genug Bedarf da ist könnte auch sein das man irgendwann mal 5x5 Units sieht, ich halt es aber für sehr u wahrscheinlich.

Alle Klarheiten beseitigt?

 

[ETI1120]

Ich könnte mir auch vorstellen, dass man andere Matrix-Cores mit Fokus auf INT8 und FP16 entwickelt, die dann in RDNA3 einfließen können. Dann würden deren Workstation-Varianten auch für entsprechende Entwicklungen verwendet werden können. Damit wären dann CDNA und RDNA sehr deutlich voneinander abgegrenzt, was GPU-Compute bzw KI angeht.

Matrix-Cores, die auf AI-Algorithmen und -Datentypen optimiert sind, halte ich auch für die Lösung.
Aber warum diese Matrix-Cores in RDNA3 einfließen lassen? Wenn AMD spezielle AI-Matrix-Cores entwickeln sollte, wird es IMHO eine dritte Architektur neben RDNA und CDNA geben. Aber hier werden die Teams von Xilinx ein gehöriges Wort mitreden.

Ich habe bei diesen Diskussionen um ML immer das Interview von Jim Keller bei anandtech im Ohr. Hier sagt Jim Keller:
Es gibt wirklich drei verschiedene Arten von Computern: CPUs, GPUs und AI. NVIDIA macht eine Art "Zwischending", bei dem sie eine GPU verwenden, um KI auszuführen, und sie versuchen, sie zu verbessern. Einiges davon funktioniert offensichtlich ziemlich gut, und einiges ist offensichtlich ziemlich kompliziert.

Tenstorrent, die Firma bei der Jim Keller eingestiegen ist, baut AI-Computer (Tensix-Cores), deren Kernstück Matrixeinheiten sind. Tenstorrent ist nur eines von vielen Startups die neue Wege beschreiben. Wobei Tenstorrent eine sehr gute Presse 1 2 hat.

Das anandtech Interview mit Ljubisa Bajic (Gründer und CEO) und Jim Keller (CTO) ist lesenswert.
Beide haben übrigens zuvor bei AMD zusammengearbeitet. Deswegen geht es in diesem Interview auch ein bisschen um AMD.