News AMD Instinct MI210: Halbiertes GPU-Doppel als PCIe-Karte mit 23 TFLOPS

[tomgit]

Na, sollten Sie mal machen, aber lassen wir denen mal etwas Zeit.

Naja, das war in den Release-Notes zu 5.0 und wir sind bei 5.0.2 angekommen... aber gut, man stößt ja auch bei Nvidia und Microsoft oft genug auf veraltete Dokumentation

Und sein wir mal ehrlich: Die meisten Entwickler in dem Bereich, die ohnehin auf Linux arbeiten, scheren sich nicht so sehr um den offiziellen Support während der Entwicklung auf ihren eigenen Rechnern und Co, sondern für die ist dann wichtig, dass dann auf den Systemen, wenn der Code ausgeführt wird, alles passt mit dem Support.

Würde ich nicht ganz so unterschreiben? Auch wenn ROCm als Layer gute Arbeit leisten sollte, ist es immernoch ein zusätzlicher Teil der Kette, welcher Probleme machen kann.
Ich mein, klar, ab einer gewissen Größe ist es dann auch beinahe egal, ob man die Software für CUDA anpasst oder einfach per Vorschlaghammer skaliert, Problem sind aber eher die Edge- und Client-Cases, wo AMD entweder fast keine oder gar keine Alternative anbieten kann. Nehmen wir doch mal die offiziell unterstützten RDNA-GPUs als Beispiel: Ja, die W6800 wird unterstützt (TIL ), aber das lässt dann auch wieder zig Grafikkarten von AMD außen vor. Würde ich als Unternehmen also einen Prototypen erstellen wollen, müsste ich mich a.) darauf einlassen, dass ich für die günstigste Alternative mindestens 2k€ hinzublättern habe und b.) dass der Layer keine Kompatibilitätsprobleme zu Nvidia-Frameworks hat. Und ob sämtliche Teile von Metropolis, des TAO Toolkits usw. drauf laufen, ist dann eben die nächste große Frage.

Intel versucht aktuell mit ihrer OneAPI die CUDA-Dominanz zu brechen - was Intel auch dazu bewegt für AMD GPUs zu optimieren, was irgendwie zeigt, wie Dominant NVIDIA wirklich ist.

Das ist aber wieder das nächste Problem. So geschlossen wie CUDA ist, ist es aber eine Architektur, die zumindest weitestgehend funktioniert und zueinander ebenso weitestgehend kompatibel ist (dass ältere CUDA-Versionen nicht neuere Frameworks unterstützen, ist mir bewusst )
Aber dann kommen eben Intel und AMD mit zig verschiedenen "offenen" Frameworks daher (Vulkan Compute, OpenVK, OneAPI, OpenCL (noch), und dann noch Microsofts eigenes DirectML-Süppchen), wo ich mir auch denken kann, es für die Entwickler schwierig ist sich darauf festzulegen. Selbst wenn es wieder nur Layer für CUDA wären, müsste man dennoch die Funktion verifizieren.

AMD geht mit ROCm einen Weg, den man in einer idealen Welt hätte nicht gehen müssen, weil die Entwickler CUDA den Finger gezeigt hätten und stattdessen OpenCL nutzen, aber so muss AMD die bittere Pille schlucken und muss CUDA weitgehend auf Radeons zum laufen bringen und das ist keine wirklich leichte Aufgabe.

Ich ging auch nicht davon aus, dass es eine einfache Aufgabe wäre Aber ich stimme dir zu, das Problem war halt nur, dass Nvidia zur richtigen Zeit die richtigen Investitionen tätigen konnte, um CUDA so dominant werden zu lassen. AMD war am Boden und Intel hatte einfach kein Interesse daran für nicht-CPUs etwas bereitzustellen. Entsprechend haben wir ja unseren Status Quo: Entweder CUDA oder halt über CPU, bzw. das bisschen etwas, woran Apple noch damals mitgearbeitet hatte.
Und letztere bekommen ja nicht einmal Tensorflow passend integriert (toll, läuft über CPU und GPU, und ignoriert die Neural Cores )

 

[DevPandi]

Naja, das war in den Release-Notes zu 5.0 und wir sind bei 5.0.2 angekommen... aber gut, man stößt ja auch bei Nvidia und Microsoft oft genug auf veraltete Dokumentation

Das mit veralteten Dokumentationen kenne ich quasi von allen Herstellern. Gut die AMD Seite ist aber auch nicht die erste Anlaufstelle. Wer sich da wirklich interessiert, schaut ja auch eher bei GitHub.

Das ist aber wieder das nächste Problem. So geschlossen wie CUDA ist, ist es aber eine Architektur, die zumindest weitestgehend funktioniert und zueinander ebenso weitestgehend kompatibel ist (dass ältere CUDA-Versionen nicht neuere Frameworks unterstützen, ist mir bewusst )

Ach, FireStream, OpenCL und ebenso jetzt DirectX Compute und auch Vulkan Compute funktionieren auch alle relativ gut.

Die Probleme liegen da an andere Stelle begraben und an diesen Stellen arbeitet nun Intel und AMD sowie auch Apple immer mehr. Gleich dazu mal mehr.

Aber dann kommen eben Intel und AMD mit zig verschiedenen "offenen" Frameworks daher (Vulkan Compute, OpenVK, OneAPI, OpenCL (noch), und dann noch Microsofts eigenes DirectML-Süppchen), wo ich mir auch denken kann, es für die Entwickler schwierig ist sich darauf festzulegen. Selbst wenn es wieder nur Layer für CUDA wären, müsste man dennoch die Funktion verifizieren.

Die offenen Frameworks waren nie wirklich das Problem und auch DirectCompute und DirectML ist nicht so wirklich das Problem. Und gerade bei Deep Learning/Maschine Learning muss ich dir an der Stelle auch etwas widersprechen, aber auch nur weil ich da in letzter Zeit mit immer mehr Entwicklern zutun habe:

Auch wenn NVIDIA es gerne so hätte, aber im ML-Bereich spielt CUDA eigentlich nur eine nachgeordnete Rolle, deswegen ist da für AMD und auch Intel eigentlich noch nicht Hopfen und Malz verloren. Die meisten Frameworks sind so ausgelegt, dass man verschiedene Backends wählen kann. Die Arbeit liegt hier eher bei den Entwicklern der Frameworks und Werkzeuge.

Anders sieht es ja bei den klassischen HPC-Aufgaben aus aus Bildbearbeitung, Film und Co. Da wird CUDA sehr gerne verwendet und ist auch dominierend, sieht man ja an Blender und Co.

Aber ich stimme dir zu, das Problem war halt nur, dass Nvidia zur richtigen Zeit die richtigen Investitionen tätigen konnte, um CUDA so dominant werden zu lassen

Wobei es nicht unbedingt etas damit zutun hatte, dass AMD am Boden lag, sondern das AMD damals noch zu sehr sich darauf verlassen hat, dass ja gute Hardware reicht und die Entwickler ja anpassen würden.

ATi ist vor NVIDIA mit ihrem FireStream auf den Markt gekommen und hatte damals auch schon entsprechende Arbeit geleistet. Nur hat ATi als auch AMD dann zwar die Hardware weiter verbessert und auch die API, hat aber etwas unterschätzt: Man braucht auch passende Tutorials und man muss den Entwicklern unter die Arme greifen.

NVIDIA hat - auch mit der Übernahme von 3dfx - neben Marketing eine weitere Sache gelernt und setzt diese seit gut 20 Jahren auch konsequent um: Schickt Entwickler zu den Firmen, die die Leute ausbilden und auch dabei helfen und im Zweifel: Setzt die Funktion um!

Und das beste ist: NVIDIA supportet einen dabei auch noch sehr stark und das oft sogar auf eigene Kosten, weil NVIDIA wusste, dass sich diese Investitionen bezahlt machen, wenn man dann mehr Hardware absetzt.

AMD ist erst jetzt - als Fr. Su übernommen hat - langsam aufgewacht und hat gemerkt, dass man nicht nur Hardware und die offenen Schnitstellen bieten muss, sondern dass man Entwickler auch ausbilden muss und Firmen unterstützen. Noch muss AMD da einiges nach holen, aber sie holen auf und mit Xilinx haben sie da auch weitere Kompetenz bekommen, die genau das ja auch macht.

Es setzt langsam - weniger bei "Nerds" - auch bei Firmen langsam erneut ein, dass man sich nicht zu sehr von einer Firma abhängig machen darf, weil man sonst irgendwann auf Gedeih und Verderb dieser Firma ausgesetzt ist.

Ich selbst habe diese Erfahrung bereits sehr schmerzhaft machen dürfen, in dem wir von einer Firma so abhängig waren, dass am Ende nur ein Friss oder Stirb gab von Seiten der Firma aus und wir unter sehr großen Schmerzen uns nach OpenSource umgesehen haben und dafür auch an Entwickler entsprechend Gelder bezahlt haben, dass wir NIE wieder von einer Firma abhängig und Erpressbar sind.

 

[tomgit]

Auch wenn NVIDIA es gerne so hätte, aber im ML-Bereich spielt CUDA eigentlich nur eine nachgeordnete Rolle, deswegen ist da für AMD und auch Intel eigentlich noch nicht Hopfen und Malz verloren. Die meisten Frameworks sind so ausgelegt, dass man verschiedene Backends wählen kann. Die Arbeit liegt hier eher bei den Entwicklern der Frameworks und Werkzeuge.

Ja und nein. ML ist ja nicht nur Large Scale oder Scalability, sondern auch Prototypen, Studien und Implementierungen. Etwa bei der Verwendung von OpenCV hab ich feststellen dürfen, dass ich entweder auf CUDA zurückgreifen kann oder die (allermeisten) Anwendungen auf die CPU zurückgreifen. OpenCL gab es noch, aber das war Intel-GPUs vorbehalten.
Bei Large Scale Lösungen sieht es natürlich anders aus.

Anders sieht es ja bei den klassischen HPC-Aufgaben aus aus Bildbearbeitung, Film und Co. Da wird CUDA sehr gerne verwendet und ist auch dominierend, sieht man ja an Blender und Co.#

Wobei hier ja witzigerweise Rendering-Farmen wieder primär auf CPU-Cluster-Lösungen zurückgreifen

Es setzt langsam - weniger bei "Nerds" - auch bei Firmen langsam erneut ein, dass man sich nicht zu sehr von einer Firma abhängig machen darf, weil man sonst irgendwann auf Gedeih und Verderb dieser Firma ausgesetzt ist.

Wird aber auch mal (wieder) Zeit.
Leider stelle ich es ebenfalls bei den "Nerds" fest, wie viele hier eine proprietäre/abhängige Lösung bevorzugen würden, weil wenn etwas hinüber ist, gibt es weniger Stellen zum Anlaufen. Die negativen Seiten werden dann halt nicht gesehen oder bewusst ignoriert.

 

[ETI1120]

Wobei es nicht unbedingt etas damit zutun hatte, dass AMD am Boden lag, sondern das AMD damals noch zu sehr sich darauf verlassen hat, dass ja gute Hardware reicht und die Entwickler ja anpassen würden.

Wobei beides sehr gut zusammenpasst. Kaum Budget für Softwareentwicklung und eben hoffen dass es auch ohne massive Investitionen in Software funktioniert. Hier lag der Fehler in den Jahren 2010 bis 2015. Allerdings hat man in diesem Zeitbereichg auch bei der Treiberentwicklung für Linux kürzen müssen.

Allerdings war es 2015 auch für AMD offensichtlich, dass es ohne einen Softwarestack nicht funktionieren kann. Und damals hat AMD angefangen an ROCm zu arbeiten. Aber zu diesem Zeitpunkt waren die Entwicklungsbudgets auf dem Tiefpunkt und der Fokus lag eindeutig auf Zen.

Was man bei der ganzen Geschichte nicht vergessen darf, ist dass AMD 2 Mal den für die Softwareentwicklung Verantwortlichen verloren hat. 2015 an Nvidia ein paar Jahre später an Intel.

Ich selbst habe diese Erfahrung bereits sehr schmerzhaft machen dürfen, in dem wir von einer Firma so abhängig waren, dass am Ende nur ein Friss oder Stirb gab von Seiten der Firma aus und wir unter sehr großen Schmerzen uns nach OpenSource umgesehen haben und dafür auch an Entwickler entsprechend Gelder bezahlt haben, dass wir NIE wieder von einer Firma abhängig und Erpressbar sind.

Aber das Problem war doch, dass es für Nvidia lange Zeit keine Konkurrenz gab. Es gab zu CUDA + Nividia-Hardware keine Alternative. Nvidia hat schon dafür gesorgt dass OpenCL zwar funktioniert hat, aber mit der Leistung der CUDA-Toolkette nicht mithalten konnte.

AMD und Intel konnten nichts bieten was eine offene Schnittstelle erstrebenswert macht.

Das beginnt sich jetzt zu ändern. Die Frage ist ob nur die Opensource-Community oder auch die Softwareanbieter die Alternativen zu CUDA unterstützen wird.

@tomgit: Das Problem mit dem offiziellen Support ist, dass man einerseits alle Karten explizit testen muss und andererseits alle Probleme die sich mit unterschiedlicher Hardware ergeben auch lösen muss. Und hier ist die Frage in was investiert man als Firma.

Das Unterstützen der Konsumerkarten ist kritisch. Es geht nicht nur darum dass eine Firma ein paar Euro sparen kann. Es geht um Schüler, Studenten und Universitäten. Hier ist preiswerte Hardware der Türöffner zu einer neuen Generation an Softwareentwickler. Bridgeman hat es verstanden. Haben es die Verantwortlichen bei AMD auch?

 

[Fegr8]

Naja die Consumerkarten kriegen ja jetzt HIP (Teilmenge von ROCm und das Gegenstück zu CUDA) aber die Softwarehersteller sind halt wieder extrem langsam wenn es von AMD kommt. Blender hat mit HIP gezeigt wie OpenCL einfach zu viele Schwächen hatte und CUDA damit lange Zeit konkurenzlos war. Jetzt hoffe ich das Adobe und Co. auch irgendwann HIP umsetzten werden und zwar zeitnah!