- AMD stärkt seine Rechenzentrums-GPU-Strategie rund um den AI-Software-Stack ROCm, um dem Nvidia-CUDA-Ökosystem etwas entgegenzusetzen
- ROCm hat sich von einem anfänglich einfachen Firmware-Bündel zu einer vollständigen Softwareplattform entwickelt und führt ein Release-Modell im 6-Wochen-Rhythmus ein, um eine stabile Nutzbarkeit sicherzustellen
- Mit OneROCm treibt AMD die Integration und Portabilität des AI-Stacks zwischen CPU, GPU und FPGA voran und steigert die Entwicklungseffizienz durch Code-Wiederverwendung auf Basis von Triton und MLIR
- ROCm macht alle Komponenten außer der Firmware Open Source, um die Innovationsgeschwindigkeit der Community zu nutzen, und wird auch auf Strix-Halo-Laptops und in der Windows-Version standardmäßig unterstützt
- AMD legt Wert auf Reaktionen auf Entwickler-Feedback und die Wiederherstellung des Community-Vertrauens und will ROCm zu einer nachhaltigen, entwicklerzentrierten Plattform für die kommenden 10 Jahre ausbauen
Die Entwicklung von AMD ROCm und die Strategie im Wettbewerb mit CUDA
- AMD treibt im Rechenzentrums-GPU-Markt den AI-Software-Stack ROCm als Kernstrategie voran, um dem CUDA-Ökosystem von Nvidia zu begegnen
- Anush Elangovan, Vice President für AI-Software, beschreibt die Entwicklung von ROCm als „einen Prozess wie das Besteigen eines Berges, bei dem man Schritt für Schritt vorankommt“, und betont kontinuierliche Verbesserungen und Integration
- Er kam durch die Übernahme des Startups Nod.ai zu AMD; das Nod-Team hat zu wichtigen Open-Source-Projekten wie Shark, Torch.MLIR und IREE beigetragen
- Mit ROCm verfolgt AMD die Integration des AI-Stacks zwischen CPU, GPU und FPGA (OneROCm), verkürzt den Software-Entwicklungszyklus auf 6 Wochen und strebt „ein Niveau an, bei dem Nutzer die Versionsnummer gar nicht mehr bewusst wahrnehmen müssen“
- ROCm bereitet sich derzeit auf einen Übergang zu AI-gestütztem Engineering vor und beschleunigt seine Expansion rund um das Open-Source-Ökosystem und die Entwickler-Community
Die Weiterentwicklung von ROCm und die Softwarestrategie
- ROCm bestand anfangs aus zusammengebündelten Firmware-Fragmenten, hat sich nach zweieinhalb Jahren Investitionen jedoch zu einer vollständigen Softwareplattform entwickelt
- Elangovan orientierte sich an der Entwicklungskultur des Google-Chrome-Teams mit dem Ziel eines regelmäßigen Release-Zyklus und einer stabilen User Experience
- ROCm hat sich als Software etabliert, die „einfach funktioniert“, und soll künftig in ein Release-Modell im 6-Wochen-Rhythmus übergehen
- AMD befindet sich im Wandel von einem hardwarezentrierten zu einem softwarezentrierten Unternehmen; als nächsten Wendepunkt sieht das Unternehmen AI-assisted engineering
Integration des AI-Stacks und Portabilität
- Mit OneROCm realisiert AMD die Integration des AI-Stacks über unterschiedliche Hardware wie CPU, GPU und FPGA hinweg
- Einige Komponenten bleiben zwar weiterhin hardwareabhängig, aber die gesamte Beschleunigung erfolgt über den ROCm-Stack, wodurch Portabilität erreicht wird
- Durch die Verbreitung des Triton-Frameworks werden Kompatibilitätsprobleme zwischen GPUs abgeschwächt
- Früher wurden CUDA-Kernel in HIP-Kernel umgewandelt, heute kann man Triton-Kernel schreiben, die sowohl auf AMD- als auch auf Nvidia-Hardware laufen
- AMD investiert aktiv in Triton sowie in die MLIR-Compiler-Infrastruktur und unterstützt durch die Pflege von Torch.MLIR das Retargeting von Code auf unterschiedliche Hardware
- Die meisten Inferenzkunden nutzen LLM-Frameworks wie vLLM und SGLang, weshalb Anfragen zur Umwandlung von CUDA-Code zurückgehen
- Wenn neue Attention-Algorithmen auftauchen, lassen sich Triton-basierte Kernel innerhalb von ein bis zwei Tagen optimieren
- HIPify wird weiterhin für HPC-Kunden angeboten; für das Schreiben neuer Kernel wird Claude AI zur Verifikation und Code-Erzeugung eingesetzt
Open-Source-Strategie
- ROCm veröffentlicht alle Komponenten außer der Firmware zu 100 % als Open Source
- Durch die Öffnung als Open Source kann die Plattform von der Entwickler-Community geprüft werden und zugleich von einer höheren Innovationsgeschwindigkeit der Community als bei AMD selbst profitieren
- Jeder kann sich an der gewünschten Stelle beteiligen, etwa bei Compiler oder Runtime, ohne durch die Kollaborationsgeschwindigkeit von AMD begrenzt zu sein
- AMD treibt den Ausbau der Entwickler-Community aktiv voran; auf Laptops mit Strix Halo wird ROCm standardmäßig unterstützt
- Updates für die Windows-Version von ROCm werden am gleichen Tag wie für die Instinct-Rechenzentrumshardware ausgeliefert
Entwickler-Community und Feedback-Kultur
- Elangovan legt Wert auf den direkten Austausch mit Entwicklern und sammelt über X (Twitter) Feedback in Echtzeit
- Er überwacht Schlüsselwörter wie „ROCm“, „ROCm sucks“ und „AMD software not working“ und antwortet direkt auf alle Beiträge
- Die meisten Probleme gehen auf mangelnde Schulung und Unterstützung zurück; auch anonymen Entwicklern gibt er direkt Ratschläge
- AMD hat auf GitHub mehr als 1.000 Beschwerden zu ROCm untersucht und innerhalb eines Jahres alle behoben
- Häufig wurden Unterstützungsanfragen für ältere Hardware gestellt; diese wird inzwischen von AMD oder der Community gewartet
- Durch dieses Vorgehen wurde das Vertrauen der Entwickler wiederhergestellt, und die Wahrnehmung, dass „AMD Probleme löst“, hat sich verbreitet
- Elangovan äußerte Erwartungen an die MI450-GPU (geplante Markteinführung in der zweiten Hälfte 2026) und betonte, ROCm zu einer für die nächsten 10 Jahre tragfähigen Plattform auszubauen
- Ziel ist ein stabiles Ökosystem, bei dem sich Entwickler auch beim Erscheinen neuer Hardware keine Sorgen machen müssen
Künftige Richtung und Philosophie
- Auf Basis seiner Erfahrungen aus der Zeit bei Nod.ai verweist Elangovan darauf, dass Compiler-Technologien inzwischen von nahezu allen Accelerator-Unternehmen übernommen wurden
- Er sagt, man müsse „mit Überzeugung Schritt für Schritt vorangehen“, und definiert die Entwicklung von ROCm als Ergebnis kontinuierlicher Umsetzung
- AMD will nicht bloß CUDA kopieren, sondern arbeitet an differenzierten ROCm-Funktionen und verfolgt langfristig das Ziel, sich als entwicklerzentrierte Plattform zu etablieren
2 Kommentare
Fangen wir doch erst mal beim Treiber an ...
Hacker-News-Kommentare
In der vergangenen Woche habe ich TheRock auf stagex portiert und versucht, ROCm mit einer auf musl/mimalloc basierenden Toolchain zu bauen
Der Grund ist, dass ich Binärdateien, die nur mit einem einzigen Compiler gebaut wurden, für sicherheits- und datenschutzkritische Workloads nicht vertrauen kann
Das Verpacken von mehr als 30 Abhängigkeiten und einem angepassten LLVM war ein Albtraum, aber heute Morgen habe ich es endlich geschafft, den Runtime-Build erfolgreich abzuschließen
Dass AMD-Hardware in einer vollständig offenen Umgebung funktioniert, macht Hoffnung für Hochsicherheits-Workloads
Ich habe mich durch den angepassten LLVM-Fork und mehrere Pakete gekämpft, es am Ende aber als Zeitverschwendung aufgegeben
Im Moment nutze ich llama.cpp mit Vulkan-Unterstützung und bin damit vollkommen zufrieden
Falls du das Build-Rezept teilen könntest, würde das vermutlich helfen, den letzten Schritt der Alpine-Portierung zu schaffen
Letztes Jahr habe ich im Vertrauen auf AMDs Zusagen meine Aktionärskampagne gestoppt, aber inzwischen habe ich das Gefühl, dass wirklich Handeln nötig ist
unlockgpu.com/action-plan
So darf das nicht sein, diese Arbeit sollte ganz klar nutzbar sein
Nvidia hat ebenfalls versprochen, seine Open-Source-Treiber zu verbessern
Persönlich finde ich es attraktiver, dass Intel 32 GB VRAM für etwa 1000 Dollar anbietet
Meinst du damit,
.o-Dateien zu mischen und mit verschiedenen Compilern zu linken?Ich frage mich, ob es sich tatsächlich um Workloads handelt, die das Problem aus Reflections on Trusting Trust praktisch umgehen wollen
Seit Februar bitte ich AMD darum, auf gfx1201 abgestimmte Tensile-Kernel in rcom-libs aufzunehmen, aber niemand weiß, wer zuständig ist
Selbst auf dem Entwickler-Discord kommt keine Antwort, was ziemlich frustrierend ist. Das wirkt wie ein Beispiel dafür, dass es bei AMD neben technischen Problemen auch organisatorische Engpässe gibt
zichguan-amd oder harkgill-amd könnten die richtigen Ansprechpartner sein
AMD hat bei ROCm noch immer mehrere Jahre Rückstand aufzuholen
Nicht einmal alle eigenen GPUs mit AI-Rechenleistung werden unterstützt, und selbst dort, wo Support vorhanden ist, gibt es viele Bugs
Der AMDGPU-Treiber für Linux ist seit 6.6 durchgehend instabil
Dass man nicht erkannt hat, wie wichtig AI werden würde, war ein klarer Fehler
Wenn AMD konkurrenzfähig würde, wäre das gut für die ganze Branche, aber diese Situation haben sie sich selbst eingebrockt
Schon zu ATI-Zeiten war man für fehlerhafte Treiber berüchtigt, und es wirkt, als habe sich diese Kultur auch nach der Übernahme durch AMD nicht geändert
Letztes Jahr hat AMD auf GitHub Beschwerden zu ROCm gesammelt und anschließend verkündet, alle 1000 Fälle gelöst zu haben
In der Praxis hat sich der Support für ältere Hardware aber kaum verbessert
Erst an dem Tag, an dem ROCm ab Veröffentlichung auf allen AMD-Karten unterstützt wird, werde ich dem Marketing glauben
Dass man früher sogar neue Karten wie die 400er-Serie fallen gelassen hat, war ein großer Fehler
Ich hoffe, das Management investiert stärker in den Software-Stack
ROCm wird auf normalen Consumer-GPUs, etwa einer RX 580, nicht unterstützt
Das Vulkan-Backend funktioniert dafür gut
Dass die GCN-Architektur inzwischen aus dem Support fällt, finde ich nachvollziehbar, aber bei den RDNA-Generationen bleibt mangelnder Support ein Problem
Aktuell sind nur RDNA3 und RDNA4 möglich, während CUDA noch immer Turing unterstützt
Siehe offizielle Dokumentation
Das Vulkan-Backend funktioniert gut, aber bis zum offiziellen Support hat es 1 bis 2 Jahre gedauert
Ich wünschte, jemand würde den ROCm-Stack aufräumen (clean-up)
Es sollte möglich sein, einfach
git clone --recurse-submodules rocmauszuführen und dann mit configure/make zu bauen, wobei fehlende Abhängigkeiten klar ausgegeben werdenMomentan wirkt es eher so, als hätte man verschiedene Komponenten ohne Struktur hingeworfen; eine konsistente Architektur ist nicht erkennbar
Ich bin im Team OpenVINO und SYCL gegen CUDA
Intels iGPUs und dGPUs sind in letzter Zeit preislich vernünftig geworden, und auch der Software-Support hat sich verbessert
Für CV- oder Data-Science-Workloads statt Gaming skaliert das ziemlich gut
Das ist mein Feedback zu ROCm an das AMD-Management
(1) Nur Server-GPUs zu unterstützen und Consumer-GPUs/APUs zu ignorieren, war ein strategischer Fehler
Die meisten Entwickler experimentieren zuerst auf ihrem privaten Laptop und skalieren später auf Server hoch
Wie bei CUDA sollte es auch auf Consumer-GPUs laufen, selbst wenn die Leistung geringer ist
(2) Die Politik, nur zwei Generationen zu unterstützen, ist aus Kundensicht nicht nachvollziehbar
Siehe offizielle Dokumentation
CUDA hält eine starke Abwärtskompatibilität aufrecht
(3) Sich nur auf Triton zu konzentrieren und HIP wie zweitklassig zu behandeln, ist die falsche Richtung
Es gibt nach wie vor viel HPC-, Simulations- und wissenschaftlichen Code auf C/C++-Basis
AMD-GPUs haben ihre Stärke bei FP64-Leistung, und so wirft AMD diesen Vorteil selbst weg
(4) Schließlich muss auch die Qualität des Packaging besser werden
Mit Distributions-Paketierern zusammenzuarbeiten verursacht keine großen Kosten und könnte gegenüber Nvidia einen Wettbewerbsvorteil bringen
Man kann Kernel direkt in Python, Julia und anderen Sprachen schreiben, und die Integration mit IDEs, Debuggern und Bibliotheken ist hervorragend
Wenn man sich das gesamte GPGPU-Ökosystem ansieht, kommen AMD und Intel bei der Vollständigkeit des Ökosystems noch nicht an CUDA heran
Die meisten Unternehmen entscheiden sich für ein Vendor-Installationsmodell wie
/opt/foo/Das macht es für Distributionen später einfacher, eigene Pakete daraus zu bauen
Aber um das zu verstehen, braucht man Leute mit Erfahrung im Open-Source-Ökosystem
Das Unternehmen konzentriert sich auf den Servermarkt und verzögert die Einführung von Consumer-GPUs mit viel VRAM
Wenn AMD diese Lücke gut nutzt, könnte das eine Chance sein
Zum Beispiel läuft es auf einer 7900 XT gut
AMD investiert nur keine Testressourcen, um es als „offiziell unterstützt“ zu kennzeichnen
Aus meiner früheren Erfahrung mit Compute-Shadern heraus sind CUDA, ROCm und OpenCV alle viel zu mühsam zu installieren
Die Abhängigkeiten sind groß, und CUDA allein umfasst 11 GB
Ich finde, man sollte einfach Vulkan verwenden. Es ist nicht plattformgebunden und „funktioniert einfach“
Allein Shader-Kompilierung und Ressourcen-Setup brauchen schon Hunderte Zeilen, und um GPU-Adressen zu handhaben, braucht man Erweiterungen
Früher gab es bei NVIDIA sogar einen Bug (?), bei dem der Wechsel in einen Grafikmodus 20 % mehr Leistung brachte