News GPU-Computing: AMDs HIP-SDK bringt Nvidia CUDA auf eigene GPUs

[DevPandi]

Klare langfristige Ziele zu setzen und auf diese konsequent schrittweise zuarbeiten war schon immer das was Nvidia ausgezeichnet hat. Und dafür muss man Jensen Huang respektieren.

Wobei NVIDIA auch die Übernahme von 3dfx damals sehr gut getan hat. 3dfx hat schon früh verstanden, dass der Software-Stack weit aus wichtiger ist, als die reihne Hardware.

3dfx hat entsprechend auch die Kultur zu NVIDIA mit genommen und bis heute sind einige der leitenden Entwickler von 3dfx auch heute noch leitende Entwickler bei NVIDIA.

Die Übernahme selbst würde ich eigentlich als Paradebeispiel einer gescheiterten Übernahme sehen. Man muss nur schauen wer alles vom Führungspersonal von ATI in den ersten 2 Jahren nach der Übernahme das Unternehmen verlassen hat. Das dürfte in den technischen Abteilungen nicht anders gewesen sei.

Da kam damals vieles zusammen. AMD hätte besser NVIDIA übernommen und die Lederjacke als Chef kommen lassen sollen. Das wäre lustig geworden heute.

Erst 2011 kam das erste Produkt mit CPU und GPU raus, erheblich verspätet. Ich habe nur Schlechtes und nichts Gutes über das Zusammenarbeiten zwischen Ex-AMD und Ex-ATI gehört.

Was zu dem Zeitpunkt nicht verwundert. Es sind hier wohl zwei Welten aufeinander geprasselt, die sich erst finden müssen. Sowas passiert oft bei Übernahmen, dass die bisherigen Kulturen erst mal im Konflikt stehen.

Das große Streichen hat erst 2009 begonnen, aber das dürfte die internen Probleme noch verschäft haben.

Bis 2009 war FireStream mit CTM auch durchaus eine "Gefahr" für CUDA, man merkte damals aber schon, dass ATi/AMD nicht so schnell weiter entwickelt hat wie NVIDIA mit CUDA. Die finanzielle Lage ab 2009 hat das alles dann verschärft.

Phil Rogers hat auch HSA unermüdlich promotet. Im Jahr 2015 hat AMD die Strategie bei der GPGPU Software auf ROCm umgestellt.

Was zu dem Zeitpunkt dann die einzige noch logische Schlussfolgerung war. NVIDIA hat mit CUDA den "Kampf" quasi gewonnen. FireSteam mit CTM hat AMD für OpenCL fallen lassen. OpenCL hat sich nicht so schnell und effektiv entwickelt wie CUDA, dazu hat NVIDIA wieder support Dev-Support geleistet, der bei OpenCL weitgehend fehlte und nach dem Apple auch noch OpenCL für Metal über Board geworfen hat, war es klar, was passiert.

AMD hat nicht die Ressourcen - wie z.B. Intel - um eine zweite API neben CUDA zu etablieren, also kam ja auch HIP, dass weitgehend die CUDA-API abbildet. Intel versucht nun seit einiger Zeit ihre OneAPI zu puschen, kommtt da aber Abseits der Märkte, die halbwegs "frei" von CUDA sind, weil hier die Frameworks genutzt werden und CUDA ein "Treiber" ist.

Im Oktober 2015 hat Phil Rogers AMD verlassen und im selben Monat bei Nvidia angefangen. Er ist heute Server Software Architect und Vice President of System Software bei Nvidia.

Ach, in dem Bereich wechseln die eh gefühlt hin und her. AMD hat ja heute auch einige ehemalige NVIDIA-Manager und Architekten und Co.

 

[ETI1120]

Wobei NVIDIA auch die Übernahme von 3dfx damals sehr gut getan hat. 3dfx hat schon früh verstanden, dass der Software-Stack weit aus wichtiger ist, als die reihne Hardware.

3dfx hat entsprechend auch die Kultur zu NVIDIA mit genommen und bis heute sind einige der leitenden Entwickler von 3dfx auch heute noch leitende Entwickler bei NVIDIA.

Nvidia hat AFAIK nur wenige Übernahmen getätigt. Sich aber die Ziele ihrer Übernahmen sehr gut ausgesucht. Während ATI praktisch die gesamte Konkurrenz aufgekauft hat.

AMD hätte besser NVIDIA übernommen und die Lederjacke als Chef kommen lassen sollen. Das wäre lustig geworden heute.

AFAIK war der Punkt, dass wegen der X86-Lizenz AMD Nvidia hätte übernehmen müssen, aber von den Finanzen eine Übernahme von AMD durch Nvidia sinnvoller gewesen wäre. Hinzu kam der Führungsanspruch von Jensen Huang.

Ich denke auch, dass AMD und Nvidia vor allem unter der Führung von Jensen Huang deutlich besser zusammengepasst hätten als AMD und ATI. ATI hätte alleine nicht bestehen können und wäre eventuell bei Intel gelandet.

AMD hatte das Problem dass die Nachfolge von Jerry Sanders nicht geklappt hat. Weder Hector Ruiz noch Dirk Meyer waren der Rolle des CEO wirklich gewachsen. Norod Forrester, der AMD in dieser Zeit als Kunde kannte sagt, dass AMD eine schlechte Execution hatte. Damit meint er dass man sich nicht auf AMD verlassen konnte.

Was zu dem Zeitpunkt nicht verwundert. Es sind hier wohl zwei Welten aufeinander geprasselt, die sich erst finden müssen. Sowas passiert oft bei Übernahmen, dass die bisherigen Kulturen erst mal im Konflikt stehen.

Aber es fällt im Vergleich auf, wie geräuschlos die Übernahme von Xilinx durch AMD vonstatten geht. Es wird angemerkt, dass AMD von der Übernahme von Xilinx profitiert, weil nur Embedded gewachsen ist. IMO hätte Xilinx alleine gar nicht so stark wachsen können.

Was zu dem Zeitpunkt dann die einzige noch logische Schlussfolgerung war.

Da sind wir einer Meinung.
Zu diesem Zeitpunkt hat man bei AMD wohl drei Dinge eingesehen:

1. Die Kopplung von CPU und GPU erfordert einen ausgereiften Softwarestack. Nur mit einer Programmier-Schnittstelle ist es nicht getan.
2. CUDA ist der Standard geworden und AMD kann auch mit OpenCL nicht dagegenhalten.
3. AMD hat nicht die Resourcen einen allumfassenden Softwearestack zu entwickeln. Nur durch konzentrieren aller Resourcen auf den HPC-Markt hat AMD eine Chance sich auch nur irgendwo zu etablieren.

Also hat AMD 2015 mit nur wenigen Resourcen wieder neu angefangen. Wichtige Meilensteine waren die Ausschreibungen von Frontier und El Capitan zu gewinnen.

Hat man in der Anfangszeit bei Frontier noch Kritik an der Reife des ROCm-Stacks mitbekommen, so scheint man inzwischen mit den Fortschritten zufrieden zu sein.

Der Haken an dieser Strategie war, dass AMD Nvidia alles außer dem HPC-Markt vollkommen überlassen hat.

Ach, in dem Bereich wechseln die eh gefühlt hin und her. AMD hat ja heute auch einige ehemalige NVIDIA-Manager und Architekten und Co.

Um was es mir ging, es lag nicht an Einzelpersonen wie Phil Rogers.

Ich habe das Gefühl, dass man mit zu wenig Resourcen zu viel erreichen wollte. In der Regel kommt dabei nichts fertiges raus. Weil sich das Ziel schneller bewegt als man vorankommt.