News ROCm-Treibersupport für GPUs: AMD bietet Entwicklern nach Schlagabtausch eine Wunschliste

[Rockbreak]

AMD hat die letzten Jahre schon viel richtig gemacht, sieht man ja wie gut sie wieder dastehen

Äh ja das liegt aber eher an ihren Cpus und nicht an ihren Gpus

 

[edenjung]

Semianalysis redet von Training, AMD fokussiert sich auf Inferenz, was der größere Markt zu sein scheint. Das ist irgendwo ein Äpfel mit Birnen Vergleich wenn Du mich fragst.

Switchen nicht alle mittlerweile zu Inferenz, weil man beim normalen Training ein Plateau erreicht hat was die Leistungsfähigkeit angeht?

 

[stefan92x]

Äh ja das liegt aber eher an ihren Cpus und nicht an ihren Gpus

Zum Teil auch an denen. Aber sie sind eben in Sachen HPC viel besser aufgestellt als in Sachen AI oder Gaming, nur ist HPChalt eine relativ kleine Nische. Fünf der Top 10 Supercomputer (unter anderem die beiden schnellsten) nutzen halt AMD Instinct, drei setzen auf Nvidia, einer auf Intel und einer auf Fujitsu.

 

[pseudopseudonym]

Wie man sich AMD Grafikkarten schönreden kann, verstehe ich nicht. Bis auf den Preis, finde ich die absolut unattraktiv.

Du hast dir mit dem Preis die Antwort doch selbst gegeben. Für mich kommt dann noch der Linux-Support dazu.

Was sonst soll ich im Desktop-Betrieb mit etwas Casual-Gaming attraktiv oder unattraktiv finden oder mir schönreden müssen? Mit CUDA habe ich auch seit Jahren nichts gemacht (aber mal auf meiner RX480 etwas rumprogrammiert, geht auch). Was soll ich also vermissen?

 

[Replay86]

AMD hat ATI 2006 übernommen und ATI hat bereits 1987 seine ersten Grafikkarten produziert. Nvidia wurde 1993 gegründet und 1995 seine erste GPU produziert. Das ist 8 Jahre später als ATI (nun AMD).

Das ist jetzt warum wichtig?
Nvidia hat sie alle überlebt. Nvidia hat 90% Marktanteile.

 

[captain kirk]

Man kann von geohot ja halten was man will, aber finde es gut dass er seine oftmals fundierte Meinung AMD schön kundtut. AMD GPU seitig krankt seit jeher an der Software, CPUs gehen dafür umso besser.

Nicht nur krankt es an der Software, deren militante Apologeten, fordern auch regelmäßig vom Mitbewerber ein, das dieser seine zu Recht Geschützen proprietären Software , für diese Faulpelze für Lau anbietet

Schön das da mal jemand Klartext redet , und den Elefant im Raum benennt , anstatt die ganzen Neidhammel, die NVIDIA dann immer angreifen, obwohl sie für ihre Produkte abliefern

 

[pseudopseudonym]

Nicht nur krankt es an der Software, deren militante Apologeten, fordern auch regelmäßig vom Mitbewerber ein, das dieser seine zu Recht Geschützen proprietären Software , für diese Faulpelze für Lau anbietet

Puh, das klingt für mich etwas komisch. Fängt ja schon damit an, dass ein Mitbewerber nicht einfach NVIDIAs Software auf seine Hardware mal so eben anpassen könnte.

Das viel größere Thema bei Software wie CUDA ist aber, dass du als Entwickler richtig dick Geld investierst, um dann auf einer Basis aufzubauen, die du nicht kontrollieren kannst. Das ist nicht nur ein Risiko, das schränkt auch die Möglichkeiten zur Problemlösung in Problemfällen ein, weil du dann eben als Basis für dein System eine Blackbox hast. Da hat es wenig mit Militanz oder Faulpelztum zu tun, dass du das nicht haben willst.

 

[BAR86]

Wie lange ist es her, dass ich hier in den News gelesen habe: AMD möchte sich mehr um die Software kümmern?
Scheint wohl ein längerfristiges Ziel zu sein.
Wie werden sehen...

Das will ich hoffen, gute Software, Ökosysteme etc das dauert JAHRE

 

[Scie]

Das ist jetzt warum wichtig?

Ich habe nur auf einen Vorposter geantwortet, dass es AMD (hier ATI) länger gibt.

 

[Stuffz]

AMD hat die letzten Jahre schon viel richtig gemacht, sieht man ja wie gut sie wieder dastehen. Aber das sie hier im Enterprise Umfeld den Schuss noch nicht gehört haben erstaunt mich. Das ist doch mittlerweile keine neue Erkenntnis, dass das Softwareökosystem fast wichtiger ist, als die Hardware 🤷‍♂️

Jo. Der Software-Support ist definitiv under-staffed. AMD hat einige Jahre lang viel richtig gemacht, aber zur Zeit sieht es mau aus. Und das sage ich als Linux-Benutzer! Ich kann Bugs melden, und die werden ignoriert, nicht sinnvoll verarbeitet, d.h. mit irgendeinem Label versehen und nach /dev/null (zudeutsch: Sanktnimmerleintstag) verschoben. Das macht gerade keinen Spaß.

Ergänzung (21. Januar 2025)

Du hast dir mit dem Preis die Antwort doch selbst gegeben. Für mich kommt dann noch der Linux-Support dazu.

Genau. Die Typen von der grünen Partei schwimmen doch schon in Dollars, guter Linux-Support kann ihnen derweil doch sch...gal sein.

 

[ETI1120]

Im Prinzip hat Semianalysis (die beste Semi HW/SW Analysebude der Welt)

Semianlysis hat im Umfeld von AI gute Kontakte und hat sich da wohl auch Kompetenz erarbeitet.

Was allerdings von Hardware selbst angeht, ist die Ahnung von Semianalysis begrenzt. Ja es ist für seine Hauptclientel Wallstreet Broker sicher brauchbar, aber wenn es um die Technik an sich geht, eher weniger. Das sieht man schon am Wirren Zeugs mit dem Semianalysis versucht hat zu erklären was es mit Zen 4c auf sich hat.

Bei Hardware Analyse führt an TechInsights kein Weg vorbei. Allerdings ist alles bis auf teaser hinter der Bezahlschranke. Und die ist hoch.

Es ist immer wieder faszinierend, wie inkompetent gewisse überbezahlte Personen in so riesigen Unternehmen sein können. Das soll keine Verallgemeinerung werden, aber wenn man anfängt, auf Twitter solche Diskussionen zu führen und auch noch diese Umfrage zu starten ...

Das ganze hat eine Vorgeschichte. Letztes Jahr hat sogar Lisa Su mit eingemischt.
Raja Koduri hat sich sehr wohlwollend über TinyGrad geäußert.

Aber George Hotz liebt es, Konflikte öffentlich auszutragen.

Ohne mich jetzt hier um Details gekümmert zu haben, AMD hat eine Roadmap wo sie hinwollen. Da sind die großen FrameWorks drauf. Da ist der Fokus auf CDNA.

Also genau genommen ist OpenCL die "offene" Version von CUDA. CUDA war vorher da.

Die nicht so gut funktionierende offene Version, ...
https://x.com/RajaXg/status/1812721241985610147


Ein wichtiger Aspekt aus den Ausführungen:

Ein weiterer Aspekt von CUDA, der nicht allgemein geschätzt wird. Das CUDA Programmiermodell ist eine echte Abstraktion des NVIDIA GPU HW-Ausführungsmodells. Hardware und Software werden gemeinsam entwickelt und sind sehr eng miteinander verflochten. Während viele CUDA-ähnliche SPMD-Modelle mit dem Versprechen der Portabilität aufkamen (OpenCL, Sycl, OpenMP, HIP-RocM....), war es nahezu unmöglich, eine Leistungsportabilität zu erreichen (es sei denn, Ihre Architektur ist eine exakte Nachbildung des CUDA-GPU-Ausführungsmodells). Da Programmierer, die sich an GPUs heranwagten, in erster Linie Beschleunigung anstrebten, konnten sich Sprachen und Tools, die nicht dazu beitragen, eine gute Leistung zu erzielen, nicht gegen CUDA durchsetzen.

Da Hard- und Software gemeinsam entwickelt werden ist es eben kein Zufall, dass so eine Kompatibilitätsliste herauskommt, sondern die logische Konsequenz

AMD hat sich viel zu lange allein auf die von Hardware konzentriert. Und an Software erst in der zweiten Linie gedacht. Und das fällt AMD wieder und wieder auf die Füße.

Es ist eines der wichtigsten Features die Nvidia bietet, dass man die Software auf einem Client rechner mit einer Gaming Grafik programmieren und testen kann und anschließend die Software auf einem Server ausrollen kann. Dies ist mit AMD Grafikkarten momentan nicht möglich.

Nvidia hatte eine großen Vorsprung was den Softwarestack anbelangt. Was Supercomputer anbelangt hat AMD zusammen mit den Partnern einiges aufgeholt. Die Trennung von CDNA und RDNA hat jedoch die Folge, dass AMD auf dem Client nur bedingt vom Erfolg bei den Superrechnern profitiert.

 

[b.a.r.m.anh]

Man könnte auch mal darauf eingehen, was ROCm überhaupt ist. Früher gab es ja zB AMD Stream. Zudem gibt es OpenCL, was auch auf CPUs, iGPUs und Nvidia-GPUs läuft. Soll ROCm also einfach performanter sein als OpenCL, weil es mehr Hardware-Details ggü der Software offenlegt, um die Aufgabenverteilung zu optimieren, oder was bringt ROCm ggü OpenCL?

Opencl auf der cpu ist bei AMD schon ewig tot. Die liefern noch nicht mal mehr Treiber für Windows. Wer das nutzen will muss sich auf seinem tollen AMD system direkt von Intel die passenden Treiber ziehen ... Ein hoch auf die x86 Kompatibilität. Früher waren die wenigstens noch im Adrenalin pack drinnen.

 

[Oberst08]

Aber sie sind eben in Sachen HPC viel besser aufgestellt als in Sachen AI oder Gaming[...]

Sagt wer? MI300 wurde z.B. von Microsoft, Meta und OpenAI gekauft, und nicht zu knapp. AMD hat sich damit einen guten Happen vom KI Kuchen geholt:
https://www.heise.de/news/AMD-Aktie-bricht-trotz-hohem-KI-Umsatz-ein-9999269.html
Klar, noch deutlich weniger als NVidia. Aber wenn man bedenkt, wo AMD vor wenigen Jahren war und was hier teilweise geschrieben wird. Manche kommen halt mit den Stammtisch Sprüchen von vor 5 Jahren. AI auf AMD Consumer Karten geht heutzutage auch auf Windows, auch wenn manche noch meinen, dass AMD Karten kein AI können und wenn, dann nur in Linux.

AMD hat seine KI Beschleuniger (Instinct-Reihe) auf Inferencing optimiert und bietet da z.B. laut Microsoft (war glaube ich Rajat Monga, der das in einer Rede gesagt hatte) das in Preis/Leistung bessere Produkt. Das war allerdings noch die alte Generation, also CDNA3 und Hopper. Entsprechend wird sich das mit den neuen Produkten auch wieder bewegen.

Aber Stand heute ist AMD bezüglich Compute und KI deutlich weiter, als den meisten NVidia Usern klar ist. Die verstehen auch den Sinn der Wunschliste nicht: AMD möchte damit feststellen, welche alte Architektur noch ROCm Support erhalten soll. Alles seit RDNA2 kann die Runtime ausführen. Wer Software mit ROCm entwickeln will, der braucht entweder RDNA3 oder Navi21. Insofern ist auch klar, dass RDNA3.5 und RDNA4 vollen (also Runtime und SDK) ROCm Support erhalten werden. Dass RDNA3.5 in der Liste steht, liegt nur daran, dass es die APUs noch nicht gibt und die User die Dinger für KI haben wollen. Entsprechend wird AMD sich dann feiern lassen, dass sie auf die User gehört haben, wenn die Dinger auf den Markt kommen. War aber sicher schon vorher geplant, ist halt dann toll für's Marketing.

 

[ETI1120]

ROCm auf Consumer-GPUs ist süß aber bewegt nicht wirklich die Euros if you ask me..

ROCm auf den Consumer-GPUs und APUs ist nicht süß, sondern notwendig, wenn AMD langfristig Erfolg haben will.

 

[MaverickM]

Sehr erfreuliche Entwicklung. Hoffen wir, dass ROCM bald richtig abhebt!

Wie lange ist es her, dass ich hier in den News gelesen habe: AMD möchte sich mehr um die Software kümmern?
Scheint wohl ein längerfristiges Ziel zu sein.

War erst vor ein paar Monaten. Und natürlich ist das ein langfristiges Ziel. Das passiert nich von Heute auf Morgen, vor allem nicht im AI-Bereich.

 

[stefan92x]

Sagt wer? MI300 wurde z.B. von Microsoft, Meta und OpenAI gekauft, und nicht zu knapp. AMD hat sich damit einen guten Happen vom KI Kuchen geholt:

Das hab ich ja auch nicht bestritten. Aber es ist doch so: Die größten Flaggschiff-AI-Cluster nutzen alle Nvidia - aber AMD ist halt eine brauchbare Alternative. Jedoch nutzen die größten HPC-Cluster AMD - und Nvidia ist eine brauchbare Alternative.

Da finde ich schon richtig zu sagen, dass AMD im HPC-Markt eine bessere Position hat als im AI-Markt.

 

[DITTY]

Ach Kinners, was CUDA, RoCm und OpenCL betrifft bitte nicht so viele Halbwahrheiten verbreiten.

1.) OpenCL ist keine freie Version von CUDA und CUDA ist keine NVIDIA-Only-Version von OpenCL.

2.) CUDA gibt es nicht länger als OpenCL. OpenCL ist definitiv von allen Accelerator/GPGPU-API-Standards und Semi-Standards wie CUDA die älteste und von Anfang an offene, freie, standardisierte und herstellerübergreifende API für Unified (Compute) Shader, um anders als früher mit nur je einem Teil an Pixel-, Cortex-, Vertex- und Geometrie-Shadern, nun mit deutlich mehr vereinheitlichten Shadern (Unified Shader, in der Entwicklung auch Device Kernel) man nicht nur spezifische, sondern auch allgemeine Berechnungen auf API-kompatibler Hardware (neben CPUs eben auch die Co-Prozessoren wie (GP)GPUs und heute auch NPUs) ausführen kann.

OpenCL ist ein Standard, der neben den anderen ähnlichen Standards:

• OpenMP (für Shared Memory Parallelisierung für Multi-Core-CPUs, heute auch für GPGPUs),
• OpenACC (wie OpenMP bloß mit Fokus auf Accelorators wie GPGPUs),
• OpenGL/ES,
• Vulkan und
• der neueste Shit, der all das vereinen soll: SYCL,

… ein Standard für General Purpose Computing der Khronos Group, der im Übrigen sowohl u.a. Intel, als auch AMD/ATI als auch NVIDIA angehören.

Vorreiter der Unified Shader war übrigens Microsoft mit DirectX 10.x ab Windows Vista mit einer rein softwarebasierten Abstraktion. NVIDIA waren dann die Ersten, die dieses Konzept des Unified Shaders wenig später in Hardware gegossen haben (NVIDIA GTx 8x00er-Generation sowie die zugehörigen Tesla-Karten; bei NVIDIA CUDA-Cores genannt) und dazu eine API sowie ein ganzes Framework und Ökosystem dazu drum herum gebaut haben (CUDA 1.0), damit man Device Compute Shader ohne separate Shader-Sprache als fast normale Funktionen in herkömmlichen Programmiersprachen entwickeln und nutzen kann (bei CUDA: Fortran, C und C++, über Cython auch nutzbar in Python, was besonders für KI-Libs in Python wichtig ist).

OpenCL ist auch nicht tot, sondern wird ebenfalls von NVIDIA wie auch AMD und Intel (oneAPI) unterstützt.

Der Unterschied liegt hierbei darin, dass NVIDIA seine Treiber einerseits deutlich mehr für die CUDA-API optimiert hat und 3rd-Party-Software-Projekte für die CUDA-Implementierung seit über 10 Jahren intensiv unterstützt hat.

Das, was aber am meisten bei OpenCL kränkelt, ist der abartig ekelhafte API-Umfang und die Syntax mit der Entwickler konfrontiert werden. Zwar wirklich frei, offen und auf CPUs und GPUs gleichermaßen nutzbar, aber leider eben unnötig komplex beim Entwickeln.
NVIDIA hat bei CUDA hier mehr abstrahiert, wodurch weniger Boilerplate-Code für denselben Zweck nötig ist.

Parallel zu den ersten CUDA-API-Generationen kam der OpenMP-Standard. Zunächst nur für MultiCore-CPU-Entwicklung in Fortran und C/C++, kamen in späteren OpenMP-Versionen auch stark abstrahierte und vereinheitlichte APIs dazu, um Device Compute Shader ähnlich einfach wie bei CUDA zu entwickeln und das herstellerübergreifend. Hierfür wurde eigentlich der OpenACC-Standard geschaffen, wobei dessen Daseinsberechtigung weiter hinterfragt werden darf, wenn OpenMP diverse Features davon nachimplementiert bekam und bei Compilern weiter verbreitet ist.

3.)
Und so fragmentierte sich der DEV-Markt nach Standard-APIs und SDKs, wohingegen NVIDIA seit jeher hauptsächlich einheitlich auf ihre CUDA-API und dessen Ökosystem setzen (obwohl sie auch parallel dazu OpenCL und OpenMP unterstützen). Gewisse Teile des CUDA-Compilerbackends (nvcc) wurden im Rahmen von Clang/LLVM sogar als OSS freigegeben, weshalb man tatsächlich auch CUDA-Code für AMD/ATI-GPGPUs bauen kann. Die CUDA-API und ihre Weiterentwicklung ist jedoch weiterhin propritär.

Neben Bestrebungen von Intel mit der oneAPI und Bestrebungen der Khronos Group mit der OpenCL-, OpenMP- und Vulkan-API, hat AMD/ATI mit der RoCm-API eine freie und herstellerübegreifende Reimplementierung der CUDA-API forciert. Genauer gesagt ist hier die Rede von der Hip-API, wohingegen RoCm dazu ein Ökosystem zur Hip-API für AMD/ATI-Hardware aufbauen soll mit angepassten und optimierten 3rd-Party-Libs, Treibern und Unterstützung für 3rd-Party-Projekte. Und genau hier mangelt es noch sehr stark am Ausbau dessen und Support für viele andere weit verbreitete Projekte (bspw. BLAS, PyTorch), bei diesen adäquat zum CUDA-Backend, auch das Hip- bzw. RoCm/Hip-Backend oder gar SYCL-Backend zu implementieren. Hier hat NVDIA mittels einheitlicher API, Treiber-Optimierung, Dokumentation, Schulungen, Dev Note-Konferenzen und entsendete Entwickler zu anderen Unternehmen und Software-Projekten seit mind. 2008 wesentlich mehr Vorarbeit geleistet als AMD oder Intel, weshalb viele viele Games, Frameworks, 3rd-Party-Lib’s, 2D/3D/Physik-Engines und Windows über die Zeit zunächst oder hauptsächlich die CUDA-API neben OpenMP mit implementierten bzw. dafür und für NVIDIA-Hardware optimierten, wohingegen AMDs RoCm/Hip-Initiative erst seit wenigen Jahren allmählich anfängt nachzuziehen. Dazu kommt, dass die Hip-API lange Zeit noch lange nicht hinreichend Feature-Complete zur CUDA-API war. Das ist sie auch heute noch nicht, ist aber auch nicht für ähnliche Leistung wie bei CUDA erforderlich. Die Hip-API bietet heute die meisten relevanten Reimplementierungen der CUDA-API-Features (Funktionen), wodurch man locker 90-95% sämtlichen bisherigen CUDA-Codes durch HIP-Code ersetzen kann (in den meisten aller Fälle lediglich durch reine geringfügige Umbenennungen von Funktionsnamen, bspw. vormals cuFoo() hin zu hipFoo() ). Das schöne dabei ist, dass Hip-Code, da herstellerübergreifend, ebenfalls für NVIDIA-Hardware gebaut und genutzt werden kann und dass ohne nennenswerte oder gar keine Leistungsverluste, je nachdem für welche Hip-Backend-Config der Entwickler sich entscheidet:
(a) Hip-Native (Kompilierung per AMDs RoCm/Hip-Compiler für Intel-, AMD-, NVIDIA-Hardware) oder
(b) Hip-Compatible (AMDs RoCm/Hip-Kompilierung für Intel- und AMD-GPUs, CUDA-nvcc-Kompilierung für NVIDIA-Hardware).

RoCm/Hip integriert also auf Wunsch auch die originale CUDA-API mittels CUDA-SDK und nvcc-Compiler von NVIDIA, falls NVIDIA-Hardware verbaut ist. Dann gibt es auch keine Leistungseinbußen bei der Ausführung desselben Hip-Codes auf NVIDIA-Hardware im Vergleich zu CUDA-Code auf NVIDIA-Hardware.

Bei Letzterem erhält man u.U. ohnehin erst dann noch mehr Leistung, wenn neueste CUDA-APIs zum Einsatz kommen, für die es noch keine Hip-API-Reimplementierungen gibt. Das betrifft aber die allerwenigsten Software-Produkte/-Projekte, weshalb dies in der Praxis recht irrelevant ist und Hip immer mehr feature complete zu CUDA wird. Möglich ist dies, da auch NVIDIA für CUDA das Clang/LLVM-Compiler-Backend nutzt wie auch RoCm/Hip.

Entwickler brauchen mit RoCm/Hip also nur noch eine Code-Basis, ohne groß alles neu machen zu müssen und können dennoch in den allermeisten aller Fälle die volle Leistung von NVIDIA-Hardware dank CUDA-Integration nutzen, nur können sie denselben Code eben auch auf Intel- und AMD-Hardware beschleunigt ausführen.
Zusammen mit OpenMP und RoCm/Hip mit CUDA-Integration fahren Software-Entwickler aktuell also am besten.

4.) Und um dem Ganzen noch eine Krone aufzusetzen: „mit CUDA erschlägt man alle NVIDIA-GPUs der letzten 12 Jahre) und man könne heute einfach eine der ersten CUDA-ready-GPGPUs von NVIDIA hernehmen“ –

Nein, kann man nicht, denn es gab im Laufe der Zeit auch Breaking Changes zwischen Major-Versionen des CUDA-SDKs oder neuere CUDA-APIs sind exklusiv nur für neuere NVIDIA-Hardware. Neuere CUDA-APIs stehen so nicht auf diversen älteren NVIDIA-GPUs zur Verfügung. Möchten Software-Entwickler dennoch mehrere und ältere CUDA-Generationen unterstützen, müssten sie wieder mehrere CUDA-SDKs und damit verschiedene Code-Pfade implementieren, was sich kaum noch Software-Projekte antun, weshalb sie immer mehr anfangen ältere CUDA-Zöpfe abzuschneiden, da diese auch von NVIDIA und den meisten Compiler-Projekten nicht mehr unterstützt werden. Es ist also fraglich, ob bestimmte ältere CUDA-SDKs überhaupt noch mit neuesten Compilern gebaut werden können, zumal sie auch ungefixt bleiben.

Der Trend geht daher in Richtung offener Standards vereint unter einem Hut:
(a)
RoCm/Hip:
für Intel-, AMD- und ältere NVIDIA-Hardware) mit CUDA-Integration (für neuere NVIDIA-Hardware) gepaart mit OpenMP.

(b) oneAPI (maßgeblich für Intel-Hardware, aber auch geöffnet für AMD, NVIDIA und Qualcomm-Technik)

(c) SYCL (vereint verschiedene Backends gleichzeitig: OpenMP, RoCm/Hip mit CUDA-Integration und OpenCL für Legacy):
Für CPUs, GPGPUs und NPUs.

Da CUDA in (a) und (c) mit integriert werden kann, gibt es kaum mehr Gründe bei reinem CUDA-Code zu bleiben und mehr Pro-Argumente, bestehenden CUDA-Code zu Hip zu migrieren.

(d) Vulkan.

(e) wGPU-API (mit neuer einheitlicher Herstellerübegreifender Shader-Sprache).

Fazit:
Tatsächlich kann man weiterhin OpenCL nutzen und damit auch ordentliche Performance-Boosts erzielen, die ähnlich zu Hip/CUDA sind. Auch hat man damit wirklich eine wahrhaftig hersteller- und plattformübergreifende standardisierte API, die tatsächlich auf sämtlicher Hardware (CPU wie auch GPGPUs) verschiedener Hersteller seit mind. 2008 läuft. Aber den komplexeren Entwicklungs- und Wartungsaufwand solche Quelltexte mit OpenCL-API zu erstellen (die tatsächlich alles Relevante der anderen APIs seit bereits über 12 Jahren abdeckt) und zu pflegen, tun sich die meisten Entwickler zurecht nicht mehr an, wenn man genauso freie, offene Standards wie OpenMP und oneAPI zur Verfügung hat, die vielen üblichen OpenCL- Boilerplate-Code per Design abstrahiert und die man für modernes GPGPU-Computing integriert über RoCm/Hip und / oder SYCL mit voller Hardware-Leistung abrufen kann und das mit nur noch einer einzigen Code-Basis, statt verschiedener Code-Pfade.

Es gilt nun seitens AMD, Intel und den diversen Compiler-Projekten, auf die meisten relevanten 3rd-Party-Software-Projekte zuzugehen und sie fit für das RoCm/Hip-, und SYCL- und wGPU-Backend zu machen. Dann braucht es auch keine CUDA-exklusiven Code-Pfade/-Implementierungen mehr, da einerseits CUDA sich auch nahtlos in RoCm/Hip integriert und andererseits die wGPU-Shader-API aktuell am sinnvollsten erscheint, um noch mehr Runtimes und Programmiersprachen wie C#, Kotlin, WebAssembly und Rust für Unified (Compute) Shader-General Purpose Computing abzudecken, denn OpenCL, OpenMP, RoCm/Hip, CUDA und SYCL haben auch heute noch allesamt einen gravierenden Nachteil: sie sind mit Ausnahme von Fortran (CUDA) auf C/C++ beschränkt. Kann man zwar mittels FFI auch bedingt in diversen Programmiersprachen nutzen, die die C-ABI implementieren (Cython/Python, Rust, C#, Java/Kotlin, Fortran, etc.), aber die Abhängigkeit zu C/C++-Code und -Compilern im Backend braucht es dann trotzdem. Direkt nativ in anderen Programmiersprachen wie Python, R, C#, Java/Kotlin, Swift, Go, Rust etc. nutzbar sind diese technischen API-Backends nämlich nicht.

Cheers.

 

[icemanspirit]

@DITTY vieles richtig beschrieben, doch vieles auch schon wieder überholt

OpenMP GPU in LLVM wurde mittlerweile in LLVM Offload umbenannt um sich dynamischer entwickeln zu können ist aber von Grund auf eher für HPC konzipiert, und die Anforderungen die hier das Department of Energy für seine Großrechner wie Frontier, und El Capitan hat. Machine Learning Frameworks integrieren hiermit nicht.

In Machine Learning Frameworks spielen HIP, SYCL, und wGPU keine Rolle. PyTorch z.B. geht direkt auf Triton welches dann durch MLIR hindurchsendend entweder auf Nvidia kompiliert, oder auf AMD. JAX erlaubt Ähnliches. ROCm-only Backends gibt es in der Form nicht wirklich. Triton hatte einen großes Rewrite gemacht in welchem es ein AMD-Backend hinzufügte und hieraus ziehen Machine Learning Projekte ihr Backend. Aber das ist es in etwa.

Direkt webGPU, ROCm, oder SYCL schreibt in dem Bereich keiner. In HPC spielen alle von Dir genannten Technologien eine Rolle, aber das ist im Vergleich zum Machine Learning Markt mittlerweile ein eher kleinerer Bereich.

 

[Oberst08]

Da finde ich schon richtig zu sagen, dass AMD im HPC-Markt eine bessere Position hat als im AI-Markt.

Ich finde es schwierig, die Märkte zu vergleichen. HPC ist ein viel kleinerer Markt. AMD macht mehr Umsatz über AI als HPC. Aber wenn es um Marktanteile geht, hast du Recht, da hat AMD im HPC Markt natürlich deutlich mehr, da ist man ja auch mit MI300X führend und Blackwell hat daran scheinbar nichts geändert: NVidia gibt für 2xGrace CPUs mit 2xBlackwell GPUs eine FP64 Leistung von je 90TFlops in den Shadern und in den Tensor-Kernen an. Das ist nicht viel mehr als die 163TFlops einer MI300X. Mit einem Epyc dazu kommt man vermutlich schon auf die Leistung von Blackwell, nur halt mit halber Stückzahl an Chips.

 

[Balikon]

Wie lange ist es her, dass ich hier in den News gelesen habe: AMD möchte sich mehr um die Software kümmern?

197 Tage seit Ankündigung.

Scheint wohl ein längerfristiges Ziel zu sein.

Ja.