ROCm défie CUDA : « avancer pas à pas »
(eetimes.com)- AMD renforce sa stratégie GPU pour les datacenters autour de ROCm, sa pile logicielle IA, afin de rivaliser avec l’écosystème Nvidia CUDA
- ROCm est passé d’un simple assemblage initial de firmware à une plateforme logicielle complète, et adopte un cycle de publication de 6 semaines pour garantir une utilisation plus stable
- Avec OneROCm, AMD cherche à unifier la pile IA et à assurer la portabilité entre CPU, GPU et FPGA, tout en améliorant l’efficacité du développement grâce à la réutilisation de code basée sur Triton·MLIR
- ROCm est open source dans tous ses composants sauf le firmware, ce qui lui permet de tirer parti du rythme d’innovation de la communauté, et il est aussi pris en charge par défaut sur les PC portables Strix Halo et la version Windows
- AMD met l’accent sur la prise en compte des retours des développeurs et le rétablissement de la confiance de la communauté, avec pour objectif de faire de ROCm une plateforme durable centrée sur les développeurs pour les 10 prochaines années
L’évolution de ROCm chez AMD et sa stratégie de concurrence face à CUDA
- AMD fait de ROCm, sa pile logicielle IA, un axe stratégique majeur pour répondre à l’écosystème CUDA de Nvidia sur le marché des GPU pour datacenters
- Anush Elangovan, vice-président en charge des logiciels IA, décrit le développement de ROCm comme « une ascension de montagne, un pas après l’autre », soulignant l’importance de l’amélioration continue et de l’intégration
- Il a rejoint AMD après le rachat de la startup Nod.ai, dont l’équipe a contribué à plusieurs projets open source majeurs comme Shark, Torch.MLIR et IREE
- Avec ROCm, AMD cherche à unifier la pile IA entre CPU, GPU et FPGA (OneROCm), tout en ramenant le cycle de développement logiciel à 6 semaines, avec l’objectif d’atteindre un niveau où « l’utilisateur n’a même plus besoin de prêter attention à la version »
- ROCm se prépare actuellement à une transition vers une ingénierie assistée par l’IA, tout en accélérant son expansion autour de l’écosystème open source et de la communauté de développeurs
Les progrès de ROCm et la stratégie logicielle
- À ses débuts, ROCm n’était qu’un assemblage de plusieurs morceaux de firmware, mais après deux ans et demi d’investissements, il est devenu une plateforme logicielle complète
- Elangovan dit s’être inspiré de la culture de développement de l’équipe Google Chrome pour viser des cycles de publication réguliers et une expérience utilisateur stable
- ROCm est désormais un logiciel qui « fonctionne tout simplement », et doit prochainement passer à un cycle de publication de 6 semaines
- AMD est en train de passer d’une entreprise centrée sur le matériel à une entreprise centrée sur le logiciel, et considère comme prochaine étape clé l’ingénierie assistée par l’IA
Intégration de la pile IA et portabilité
- Avec OneROCm, AMD met en place une intégration de la pile IA entre différents matériels comme les CPU, GPU et FPGA
- Certains composants restent encore dépendants du matériel, mais toute l’accélération passe par la pile ROCm, ce qui garantit la portabilité
- La diffusion du framework Triton réduit les problèmes de compatibilité entre GPU
- Par le passé, les noyaux CUDA étaient convertis en noyaux HIP, mais il est désormais possible d’écrire des noyaux Triton exécutables à la fois sur AMD et Nvidia
- AMD investit activement dans Triton et dans l’infrastructure de compilation MLIR, et prend en charge la maintenance de Torch.MLIR afin de permettre le retargeting du code vers divers matériels
- La plupart des clients en inférence utilisent des frameworks LLM comme vLLM et SGLang, ce qui réduit les demandes de conversion de code CUDA
- Lorsqu’un nouvel algorithme d’attention apparaît, il est possible d’optimiser un noyau basé sur Triton en un ou deux jours
- HIPify reste proposé pour les clients HPC, tandis que Claude AI est utilisé pour la validation et la génération de code lors de l’écriture de nouveaux noyaux
Stratégie open source
- ROCm publie 100 % de ses composants en open source, à l’exception du firmware
- Cette ouverture permet à la fois de bénéficier de la validation de la communauté de développeurs et de tirer parti d’un rythme d’innovation communautaire plus rapide que celui d’AMD
- Chacun peut contribuer au niveau souhaité, qu’il s’agisse du compilateur, du runtime ou d’autres composants, sans être limité par la vitesse de collaboration d’AMD
- AMD pousse activement l’élargissement de la communauté de développeurs, et ROCm est pris en charge par défaut sur les PC portables équipés de Strix Halo
- Les mises à jour de la version Windows de ROCm sont déployées le même jour que celles du matériel de datacenter Instinct
Communauté de développeurs et culture du feedback
- Elangovan accorde une grande importance à la communication directe avec les développeurs et collecte des retours en temps réel via X (Twitter)
- Il surveille des mots-clés comme « ROCm », « ROCm sucks » ou « AMD software not working », et répond personnellement à chaque publication
- Selon lui, la plupart des problèmes viennent d’un manque de formation et d’assistance, et il apporte lui-même des conseils, y compris à des développeurs anonymes
- AMD a enquêté sur plus de 1 000 réclamations liées à ROCm sur GitHub, et les a toutes résolues en moins d’un an
- Beaucoup concernaient des demandes de prise en charge d’anciens matériels, désormais maintenus soit par AMD, soit par la communauté
- Cette réaction a permis de restaurer la confiance des développeurs et de diffuser l’idée que « AMD résout les problèmes »
- Elangovan affiche aussi son enthousiasme pour le GPU MI450, prévu pour le second semestre 2026, et souligne sa volonté de faire de ROCm une plateforme pérenne pour les 10 prochaines années
- L’objectif est de bâtir un écosystème stable dans lequel les développeurs n’auront pas à s’inquiéter de l’arrivée de nouveaux matériels
Orientation future et philosophie
- En s’appuyant sur son expérience chez Nod.ai, Elangovan évoque des cas où des technologies de compilation ont été adoptées par presque toutes les entreprises d’accélérateurs
- Il affirme qu’« il faut avancer pas à pas avec conviction », définissant la progression de ROCm comme le résultat d’une exécution continue
- AMD ne cherche pas seulement à reproduire CUDA, mais développe aussi des fonctionnalités ROCm différenciantes, avec l’ambition à long terme de s’imposer comme une plateforme centrée sur les développeurs
2 commentaires
Déjà, les pilotes...
Réactions sur Hacker News
La semaine dernière, en portant TheRock vers stagex, j’ai essayé de compiler ROCm avec une toolchain basée sur musl/mimalloc
parce qu’on ne peut pas faire confiance à des binaires construits avec un seul compilateur pour des workloads où la sécurité et la confidentialité sont cruciales
Emballer plus de 30 dépendances et un LLVM custom a été un vrai cauchemar, mais ce matin j’ai enfin réussi à compiler le runtime
Le fait que le matériel AMD fonctionne dans un environnement entièrement ouvert donne de l’espoir pour des workloads à haute sécurité
J’ai réussi à passer le fork LLVM custom et plusieurs paquets, mais j’ai fini par abandonner car c’était une perte de temps
J’utilise maintenant llama.cpp avec support Vulkan, et ça me convient très bien
Si tu pouvais partager la recette de build, ça aiderait sans doute à franchir la dernière étape du portage vers Alpine
L’an dernier, j’ai arrêté ma campagne d’actionnaire en croyant aux promesses d’AMD, mais j’ai maintenant le sentiment qu’il faut vraiment agir
unlockgpu.com/action-plan
Ça ne devrait pas se passer comme ça, ce travail devrait clairement être exploitable
Nvidia a aussi promis d’améliorer ses pilotes open source
Personnellement, je trouve plus attirant le fait qu’Intel propose 32 Go de VRAM autour de 1 000 dollars
Tu parles de lier ensemble des fichiers
.oproduits par différents compilateurs ?Je me demande si c’est un workload qui cherche réellement à éviter le problème de Reflections on Trusting Trust
Depuis février, je demande à AMD d’inclure des kernels Tensile optimisés pour gfx1201 dans rcom-libs, mais personne ne sait qui en est responsable
Même sur le Discord des développeurs, je n’ai pas de réponse, c’est frustrant. Au-delà du problème technique, ça ressemble aussi à un exemple de goulot d’étranglement organisationnel chez AMD
zichguan-amd ou harkgill-amd sont peut-être les bonnes personnes
AMD a encore plusieurs années de retard à rattraper sur ROCm
Même tous ses propres GPU capables de faire tourner des charges IA ne sont pas supportés, et quand ils le sont, il y a beaucoup de bugs
Le pilote AMDGPU pour Linux est instable depuis la 6.6
Ne pas avoir vu venir l’importance de l’IA était clairement une erreur
Ce serait bénéfique pour tout le secteur si AMD devenait compétitif, mais c’est une situation qu’ils ont eux-mêmes provoquée
Déjà à l’époque d’ATI, ils avaient une mauvaise réputation à cause de pilotes bourrés de bugs, et cette culture ne semble pas avoir changé après le rachat par AMD
L’an dernier, AMD a collecté sur GitHub les plaintes liées à ROCm, puis a annoncé avoir résolu les 1 000 cas
Mais en réalité, le support de l’ancien matériel a à peine progressé
Le jour où ROCm sera supporté dès la sortie sur toutes les cartes AMD, là seulement je pourrai croire au marketing
Abandonner à l’époque des cartes pourtant récentes comme la série 400 a été une grosse erreur
J’aimerais que la direction investisse davantage dans la stack logicielle
ROCm n’est pas supporté sur les GPU grand public classiques, par exemple une RX 580
En revanche, le backend Vulkan fonctionne bien
Je pense qu’il est normal que l’architecture GCN ne soit plus supportée, mais pour la génération RDNA, le manque de support reste un problème
Actuellement, seuls RDNA3 et RDNA4 sont possibles, alors que CUDA supporte encore Turing
Voir la documentation officielle
Le backend Vulkan marche bien, mais il a fallu attendre 1 à 2 ans pour avoir un support officiel
J’aimerais qu’ils fassent un clean-up de la stack ROCm
Qu’on puisse simplement faire
git clone --recurse-submodules rocm, puis compiler avec configure/make, et que les dépendances manquantes soient signalées clairementAujourd’hui, on a plutôt l’impression qu’ils ont juste empilé plusieurs composants sans structure, sans qu’une architecture cohérente n’apparaisse
Je suis dans l’équipe qui oppose OpenVINO et SYCL à CUDA
Les iGPU et dGPU d’Intel ont récemment des prix raisonnables et le support logiciel s’est amélioré
Pour des workloads de vision par ordinateur ou de data science, plutôt que du gaming, ça scale assez bien
Voici le feedback sur ROCm que j’aimerais transmettre à la direction d’AMD
(1) Le fait de ne supporter que les GPU serveur et d’ignorer les GPU/APU grand public a été une erreur stratégique
La plupart des développeurs expérimentent d’abord sur leur laptop personnel avant de passer ensuite à l’échelle sur des serveurs
Comme CUDA, il faut que ça tourne aussi sur les GPU grand public, même avec des performances moindres
(2) La politique consistant à ne supporter que deux générations est déraisonnable du point de vue client
Voir la documentation officielle
CUDA maintient une forte rétrocompatibilité
(3) Se concentrer uniquement sur Triton et traiter HIP comme un produit de second rang est une mauvaise direction
Il existe encore énormément de code HPC, de simulation et de calcul scientifique en C/C++
Les GPU AMD ont pour point fort les performances FP64, et c’est presque comme s’ils jetaient eux-mêmes cet avantage
(4) Enfin, il faut améliorer la qualité du packaging
Collaborer avec les mainteneurs de paquets des distributions ne coûte pas grand-chose et pourrait donner un avantage concurrentiel face à Nvidia
On peut écrire directement des kernels dans divers langages comme Python, Julia, etc., et l’intégration avec les IDE, les débogueurs et les bibliothèques est excellente
Si on regarde l’ensemble de l’écosystème GPGPU, AMD et Intel n’ont toujours pas rattrapé CUDA sur la maturité de l’écosystème
La plupart des entreprises choisissent un mode d’installation fournisseur du type
/opt/foo/Cela permet ensuite aux distributions de faire leur propre packaging plus facilement
Mais pour comprendre cela, il faut des personnes qui ont de l’expérience dans l’écosystème open source
Ils retardent la sortie de GPU grand public avec beaucoup de VRAM en se concentrant sur le marché serveur
Si AMD exploite bien cette fenêtre, ça peut devenir une opportunité
Par exemple, ça tourne très bien sur une 7900 XT
C’est juste qu’AMD n’investit pas les ressources de test nécessaires pour l’étiqueter comme « support officiel »
Pour avoir déjà travaillé avec des compute shaders, je trouve que CUDA, ROCm et OpenCV sont tous beaucoup trop pénibles à installer
Les dépendances sont lourdes, et CUDA pèse 11 Go
Je pense qu’il vaut mieux simplement utiliser Vulkan : pas de dépendance à une plateforme, et « ça marche, tout simplement »
Rien que la compilation des shaders et la configuration des ressources demandent déjà des centaines de lignes, et manipuler des adresses GPU nécessite des extensions
Je ne vois pas pourquoi ça devrait prendre des heures
Avant, il y avait même chez NVIDIA un bug(?) où passer en mode graphique donnait 20 % de performances en plus