Nous avions appris avant l’été que la pile graphique d’AMD serait désormais entièrement libre et qu’AMD abandonnait ses derniers pilotes propriétaires au sens de privateur, mais AMD s’est également séparé du pilote libre AMDVLK au profit du pilote libre RADV de Mesa !

L’ombre de Valve plane sur les pilotes graphiques AMD sous Linux. Ici une Steam Deck de 2022 et une AlienWare Alpha (Steam Machine originelle de 2015) en variante AMD, fonctionnant toutes deux avec RADV.
Le 17 novembre 2025, avec la sortie de la version 25.20.3, RADV est devenu le pilote Vulkan universel pour les cartes AMD sous Linux. Cette dépêche vous emmène sur les traces du pilote RADV et comment celui-ci a remplacé AMDVLK, remémore l’aventure d’ACO pour battre LLVM, raconte comment un changement récent du pilote Linux amdgpu active la prise en charge de Vulkan sur de nombreux matériels anciens, et soyons fou, vous explique comment installer RADV sur une Xbox.
Sommaire
- Dans le dernier épisode…
- AMDVLK cétékoi
- RADV vs AMDVLK, ACO vs LLVM
- L’agonie d’AMDVLK
- Ci-git AMDVLK
- La mort de PAL
- Mais concrètement, ça change quoi pour moi ?
- RADV, le pilote graphique de votre prochaine console de jeu
- RADV sous Windows ?
- amdgpu mon amour
Dans le dernier épisode…
Précédemment, dans la dépêche du 3 juillet dernier La pile graphique d’AMD sous Linux est désormais complètement libre nous découvrions qu’AMD était sur le point de se défaire de ses derniers pilotes graphiques propriétaires. C’est désormais chose faite !
Mais il y a un rebondissement ! En effet l’annonce portait sur l’abandon des pilotes « propriétaires » (AMD proprietary OpenGL and Vulkan drivers). L’adjectif « propriétaire » pouvait s’entendre dans le sens de « contraire de libre », et donc, à code fermé.
Nous savions donc que le pilote à code fermé Vulkan AMDVLK-Pro était poussé vers la sortie. Cette affirmation et cette interprétation laissait ouverte la possibilité que le pilote Vulkan libre AMDVLK puisse survivre. Mais l’adjectif « propriétaire » pouvait aussi s’entendre dans le sens de « non-communautaire » ou « propre à AMD », et le temps a parlé : pour AMDVLK aussi, c’est fini. AMDVLK ne fait plus partie de la Suite Radeon Software for Linux.
L’appellation historique AMDGPU-Pro de la suite Radeon Software for Linux tient toujours même quand il n’y a plus de code propriétaire car le suffixe « Pro » signifie « professionnel ». Tous les pilotes distribués dans la suite Radeon Software for Linux font l’objet d’un support professionnel, et cela inclus désormais RADV qui remplace AMDVLK et sa variante AMDVLK-PRO.
Le choc des simplifications… On peut se demander si après Vulkan, la prochaine technologie à passer intégralement chez Mesa serait OpenCL ⁉
AMDVLK cétékoi
AMDVLK (AMD VuLKan) était le pilote Vulkan maison de AMD. Historiquement AMDVLK était un pilote Vulkan propriétaire qu’AMD promettait de libérer (et qu’ils ont libéré). Ce fut le tout premier pilote Vulkan pour cartes AMD sous Linux, et donc un composant incontournable de l’écosystème vidéoludique sous Linux.
AMDVLK avait été libéré, mais AMD maintenait en parallèle la version propriétaire que l’on peut appeler par convenance AMDVLK-Pro, et qui était généralement en avance sur AMDVLK concernant les fonctionnalités implémentées, et possiblement la prise en charge du matériel dans certains cas.
La mort d’AMDVLK-Pro était certaine, le futur d’AMDVLK était lui, incertain.
Valve avait de son côté investi dans le développement d’un autre pilote Vulkan pour carte graphiques AMD : RADV. RADV est développé communautairement au sein de Mesa, mais initialement financé par Valve. Mesa étant très bien intégré dans les distributions Linux (de multiples composants Mesa sont déjà requis de toute façon !), RADV est le pilote distribué par défaut sous Linux. AMDVLK avait conservé son avance sur RADV pendant un temps, mais ça fait déjà un moment que RADV n’a plus à rougir de la comparaison. RADV étant mieux intégré qu’AMDVLK et de bonne qualité, AMDVLK devenait moins pertinent.
RADV vs AMDVLK, ACO vs LLVM
Mais surtout, RADV devenait meilleur qu’AMDVLK. Par exemple un compilateur de shader nommé ACO a été développé pour RADV, et il est désormais utilisé dans d’autres pilotes AMD chez Mesa comme le pilote OpenGL RadeonSI. ACO (pour Amd COmpiler) est beaucoup beaucoup plus rapide que le compilateur LLVM utilisé par AMDVLK. ACO a été écrit pour faire mieux que LLVM, c’est son but premier.
Cerise sur le gâteau, faisant partie de Mesa, ACO rend plus facile de compiler les composants AMD de Mesa sans avoir à se soucier des compatibilité de versions avec LLVM. Mais le but premier d’ACO, c’est d’être plus performant et plus efficace que LLVM pour le cas particulier des cartes graphiques.
À l’origine tous les pilotes pour cartes graphiques AMD utilisaient LLVM comme compilateur de shaders : les pilotes Vulkan RADV et AMDVLK, le pilote OpenGL RadeonSI, le pilote OpenCL RustiCL et le pilote ROCm pour nommer des pilotes libres, mais aussi les pilotes AMD propriétaires OpenGL OGLP et OpenCL basés sur Orca ou PAL. LLVM était le compilateur de shader utilisé par tous ces pilotes.
Attention, il ne s’agit pas ici du compilateur utilisé pour compiler ces pilotes pour qu’ils tournent sur votre machine, par exemple pour compiler RADV pour un processeur amd64. Non il s’agit ici du compilateur utilisé par le pilote lui-même pour compiler le code natif qui va s’exécuter sur la carte graphique, ce qu’on appelle un « shader » dans le domaine graphique, ou un « kernel » dans le domaine du calcul. Ce sont des programmes qui s’exécutent dans la carte graphique, et LLVM était le compilateur utilisé pour l’architecture amdgcn.
ACO est venu bouleverser tout cela, et ACO est carrément plus rapide que LLVM. ACO est non seulement plus rapide à compiler des shaders (temps de chargement plus court), mais le code compilé s’exécute plus vite (meilleures performances d’éxécution). Il est probablement inutile pour AMD d’investir dans le portage d’AMDVLK sur ACO, alors qu’il suffit de se focaliser sur RADV.
L’agonie d’AMDVLK
Bien que l’annonce d’AMD fut ambiguë concernant le devenir d’AMDVLK (celui-ci n’était pas mentionné du tout), dans les faits ça faisait longtemps qu’on n’avait pas vu une nouvelle version d’AMDVLK. Le temps passant, cela laissait deviner que celui-ci aussi voyait sa fin très proche, et qu’il était peut-être déjà mort.
Sur le dépôt amdvlk pour Ubuntu hébergé par AMD sur repo.radeon.com, les plus récents paquets sont datés d’avril 2025 avec la version 2025.Q2.1.
Sur le dépôt amdgpu pour Ubuntu hébergé par AMD sur repo.radeon.com, les plus récents paquets sont distribués pour la version 6.4.3 de la suite AMDGPU-Pro en août 2025, aucune version plus récente de la suite AMDGPU-Pro ne fournit de pilote AMDVLK.
La dernière version publiée sur GitHub est la version 2025.Q2.1 datée du 30 avril 2025 (ça fait déjà plus de six mois).
L’avant dernier commit sur le dépôt datait de mars et donc contribuait à la version 2025.Q2.1. Le dernier commit est daté du 15 septembre 2025 et ajoute à la documentation un lien redirigeant vers l’annonce de l’abandon d’AMDVLK.
Ci-git AMDVLK
AMDVLK est finito. Publiée le 15 septembre 2025 sur la forge GitHub d’AMDVLK, l’annonce intitulée « AMDVLK open-source project is discontinued » est on ne peut plus explicite : « Le projet open source AMDVLK a été abandonné ».
L’annonce peut se traduire ainsi :
Afin de rationaliser le développement et de renforcer notre engagement envers la communauté open-source, AMD unifie sa stratégie en matière de pilotes Linux Vulkan et a décidé de mettre un terme au projet open source AMDVLK, afin d'apporter tout son soutien au pilote RADV en tant que pilote Vulkan open-source officiellement pris en charge pour les cartes graphiques Radeon.
Cette consolidation nous permet de concentrer nos ressources sur une unique base de code hautement performante qui bénéficie du travail incroyable de l'ensemble de la communauté open-source. Nous invitons les développeurs et les utilisateurs à utiliser le pilote RADV et à contribuer à son avenir.
Ça faisait un moment que certains constataient le fait qu’AMD ne publiait plus de nouvelles versions d’AMDVLK et donc, on commençait à s’en douter, mais cela n’avait pas encore été annoncé officiellement.
Les notes de version de Radeon Software for Linux 25.20.3 annoncent la prise en charge effective de RADV. L’annonce discutée dans la précédente dépêche à l’occasion de la version 25.10.1 n’était encore qu’une annonce pour le futur, maintenant c’est fait.
Étonnamment cette nouvelle annonce ne mentionne pas AMDVLK, mais cette version ne fournit plus AMDVLK, et ça faisait un moment qu’on pouvait voir la chose venir.
Un point intéressant à noter dans cette nouvelle annonce, est que pour contourner un bug ils recommandent d’installer la version 32-bit du pilote Vulkan fourni par leur suite Radeon Software for Linux, et ce pilote est… le pilote Mesa, comme l’indique le nom explicite mesa-amdgpu-vulkan-drivers:i386. Et le pilote Mesa, c’est RADV. Cette formulation peut paraître cryptique pour le néophyte, mais sans ambiguïté quand on sait décoder les termes : le pilote Vulkan est celui de Mesa.
Ainsi donc, sans mentionner explicitement le retrait d’AMDVLK, AMD mentionne que leur pilote Vulkan est désormais RADV.
La mort de PAL
Comme de nombreux pilotes AMD historiques pour Linux, AMDVLK était basé sur un unique pilote utilisable sur d’autres systèmes d’exploitation, comme Windows. Et en effet, AMDVLK utilisait PAL (Platform Abstraction Library), qui comme son nom l’indique est une bibliothèque d’abstraction de plateforme.
C’est PAL qui permettait à AMD de porter ses pilotes OpenCL, OpenGL et Vulkan sous Windows et Linux. Leur proposition OpenCL fait désormais partie de la suite ROCm et utilise donc le backend ROCr au lieu de PAL. Leur proposition OpenGL et Vulkan ne sont plus ni OGLP ni AMDVLK et leurs remplaçants RadeonSI et RADV n’utilisent pas PAL.
Ainsi AMDVLK était le dernier consommateur de PAL. C’est donc sans surprise que le 15 septembre 2025, le même jour que l’annonce de l’abandon d’AMDVLK, le dépôt PAL a été archivé, ce qui — dans le jargon de GitHub — signifie qu’il est placé en lecture seule pour consultation uniquement. PAL n’est plus développé. PAL aussi est finito.
Goodbye old pal! Salut mon pote !
Mais concrètement, ça change quoi pour moi ?
RADV est le pilote Vulkan pour les cartes AMD sous Linux. Vulkan est une interface de programmation graphique pour effectuer le rendu 3D très efficacement, utilisé désormais à la place d’OpenGL dans de très nombreux logiciels, en particulier les jeux, mais pas seulement. Par exemple le composant GSK de la bibliothèque GTK utilisée par de nombreux logiciels y compris l’environnement de bureau GNOME peut déjà utiliser Vulkan pour le rendu. La bibliothèque Qt peut aussi faire le rendu d’interfaces QML avec Vulkan.
Vulkan prend aussi en charge les « compute shaders » qui permettent d’exploiter une carte graphique pour d’autres calculs que du rendu graphique. En général les éditeurs de logiciels préfèrent utiliser des API comme CUDA pour Nvidia, HIP (ROcm) pour AMD, OneAPI pour Intel, ou MUSA pour Moore Threads, car ces API viennent avec beaucoup de bibliothèques (ce sont des écosystèmes complets), une intégration très poussée, et sont très performantes. Mais si Vulkan Compute a un écosystème moins riche, Vulkan Compute profite du fait que Vulkan est bien plus universel. La spécification OpenCL est aussi pensée pour être universelle, mais en pratique, il est plus courant de trouver une implémentation Vulkan disponible sur une machine.
Par exemple dans le domaine de l’IA, le moteur d’inférence de LLM (large langage model) llama.cpp peut utiliser Vulkan en utilisant le cadriciel Kompute, ce qui rend ce logiciel massivement portable ! Si votre carte graphique est une carte AMD, alors vous pourrez utiliser llama.cpp avec RADV !
De même, le logiciel de transcription vocale whisper.cpp peut utiliser Vulkan et donc RADV. Ceux qui ont visité en décembre dernier le salon Open Source Expérience ont pu voir au stand Videolan une démonstration de la future version 4.0 de VLC qui intégrera whisper.cpp pour tricoter automatiquement des sous-titre pour vos films et séries préférés. Ça veut dire qu’avec le pilote Vulkan RADV et la généralisation du pilote noyau amdgpu (voir ci-après), cette fonctionnalité de VLC pourrait tourner sur toutes les cartes AMD depuis la première génération GCN (il y a 14 ans), à condition cependant que la mémoire vidéo soit suffisante…

VLC + whisper.cpp + RADV + amdgpu = sous-titres automatiques. Ici une AMD R9 280X (HD 7970 rafraîchie) avec architecture GCN1 Tahiti (j’ai vérifié que whisper.cpp fonctionne dessus avec RADV).
Ce que l’abandon d’AMDVLK signifie aussi, c’est qu’AMD est désormais fortement impliqué dans la maintenance et le développement de RADV. Quand AMD avait annoncé qu’ils prendraient en charge officiellement RADV, cela garantissait qu’ils allaient participer au développement et à la maintenance de celui-ci, mais il était toujours possible qu’une partie des ressources soit affectée à AMDVLK.
Aujourd’hui c’est sûr : plus aucun développeur de chez AMD ne travaille sur AMDVLK pour Linux, toutes les ressources Vulkan pour Linux chez AMD sont entièrement affectées au développement et à la maintenance de RADV.
Comme expliqué dans la précédente dépêche sur le sujet, RADV est fourni par défaut dans toutes les distributions de bureau Linux. Le fait qu’AMD soutienne officiellement le développement de ce pilote est une garantie pour les utilisateurs que ce pilote soit au niveau de leurs attentes, et le fait qu’AMD affecte toutes ses ressources Vulkan pour Linux sur ce pilote augmente encore cette garantie.
Nous pouvons donc refaire le tableau récapitulatif de compatibilité des pilotes AMD pour Linux, en retirant simplement la ligne AMDVLK :
| GCN1 | GCN2 | GCN3 | GCN4 | GCN5 | RDNA1 | RDNA2 | RDNA3 | RDNA4 | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Noyau | Linux amdgpu | 🐧️ | ⭐️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ |
| Vulkan | Mesa RADV | 🐧️ | ⭐️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ |
| OpenGL | Mesa RadeonSI | 🐧️ | ⭐️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ |
| VA-API | Mesa RadeonSI | 🐧️ | ⭐️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ |
| OpenCL | Mesa RustiCL | 🐧️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | ✅️ | |
| OpenCL | AMD ROCm | ⭐️ | ❌️ | ❌️ | ❌️ | ❌️ | ❌️ | ❌️ | 🧐️ | 🧐️ | 🧐️ | |
| HIP | AMD ROCm | ⭐️ | ❌️ | ❌️ | ❌️ | ❌️ | ❌️ | ❌️ | 🧐️ | 🧐️ | 🧐️ |
✅️ = Pilote fonctionnel.
🧐️ = Pilote fonctionnel pour une sélection de modèles.
❌️ = Pilote non-fonctionnel.
🐧️ = Pilote empaqueté en standard dans les distributions Linux usuelles.
⭐️ = Pilote faisant partie de la suite officielle Radeon Software for Linux.
RADV, le pilote graphique de votre prochaine console de jeu
L’acquisition d’ATI par AMD en 2006 faisait partie de la stratégie « Fusion » d’AMD : acquérir et intégrer les compétences graphiques d’ATI pour pouvoir fusionner les puces graphiques et les processeurs AMD et diriger le développement conjoint de ces composants pour pouvoir le vendre comme un produit unique et fortement intégré. Cette stratégie a été très payante dans le domaine des consoles de jeu vidéo : AMD domine le marché des consoles.
Ce qui se passe c’est que depuis 2013, les fabricants de console achètent le processeur qui est intégré avec la carte graphique :
AMD domine le marché des consoles de jeu vidéo.
À cela s’ajoute un changement de paradigme : la majorité des modèles de console qui sortent sont désormais des PC tournant sous Linux ou sous Windows. Nous parlons bien ici de modèles, pas de nombre de ventes par modèle. Microsoft et Sony font des ventes confortables de Xbox Series X/S ou de PlayStation 5 et Nintendo inonde le marché de ses Switchs. Ces consoles utilisent des systèmes spécifiques et privateurs (Microsoft utilise une variante de Windows, Nintendo et Sony se basent sur FreeBSD), mais dès que vous sortez de ces modèles, tous les modèles que vous trouverez tournent sous GNU/Linux ou Windows.
La tendance a commencé en 2020, d’abord avec la Chuwi AerobBox, une console chinoise tournant sous Windows et qui serait secrètement un dérivé de la Xbox One, suivie franchement de l’Atari VCS 400/800 en 2020 (sous Linux), suivie par la Steam Deck de Valve en 2022 (également sous Linux). La Steam Deck a atteint un succès suffisamment critique pour déclencher une explosion de nouvelles consoles produites par une multitude de fabricants : Asus ROG Ally, Lenovo Legion Go, Acer Nitro Blaze… Toutes ces machines sont compatibles PC et qu’elles soient installées par défaut avec Linux ou Windows selon le modèle, vous pourrez installer Linux sur celles-ci. Excepté la MSI Claw 7/8 qui a tenté l’expérience Intel (c’est très courageux après 24 ans d’absence d’Intel dans ce marché), toutes ces machines sont propulsées par un APU AMD, une puce intégrée mêlant CPU et GPU AMD. Si l’Atari VCS est une console de salon, toutes ces autres consoles sont des machines portables dans la lignée de la Switch.
L’année 2026 verra l’arrivée de la Steam Machine (la vraie, pas la tentative échouée de 2015), l’offre de Valve pour concurrencer le marché des consoles de salon à côté des Xbox Series et PlayStation 5. Cette concurrence se fait désormais sur le positionnement : le salon. Comparées à ces autres machines, la Steam Machine fera partie d’une nouvelle génération de consoles.
Les Xbox Series et PlayStation 5 faisaient partie de la génération « Zen 2 en CPU et RDNA 2 en GPU » qui était la reine des années 2020. Mais en 2026 la Steam Machine fera partie de la génération suivante fondée sur les architectures Zen 4 en CPU et RDNA 3 en GPU : en plus d’apporter des améliorations naturelles à ces composants, c’est la génération qui introduit AVX512 dans les consoles.
L’offre de Microsoft pour cette nouvelle génération est l’Asus ROG Xbox Ally X sortie ce 16 octobre 2025. L’Asus ROG Xbox Ally X tourne sous Windows, est compatible PC et vous pouvez l’utiliser sous Linux. Si vous achetez la plus récente console de marque Xbox — la première Xbox pour cette nouvelle génération de consoles — vous pouvez installer Linux et dans ce cas, RADV sera votre pilote graphique. Vous pouvez dès aujourd’hui utiliser RADV sur une console Xbox officielle, il vous suffit de démarrer la ROG Xbox Ally X sur une clé USB Linux… Trop simple ! À ce niveau de simplicité l’accroche dans le chapô relève presque du putaclic (assumé 😄️).
RADV sous Windows ?

AMD utilise AMDVLK sous Windows, pourrait-il être remplacé par RADV là aussi ?
Comme écrit plus tôt le pilote AMDVLK était partagé avec d’autres systèmes d’exploitation, comme Windows.
La solution AMDVLK était pertinente pour AMD car ils pouvaient ainsi mutualiser leurs efforts. Mais se pose alors la question : s’ils souhaitent continuer à mutualiser leurs efforts, pourraient-t-ils remplacer leur pilote Windows par RADV et profiter en-même temps de toutes les améliorations apportées par la communauté ?
Techniquement, c’est possible, et ça a déjà été tenté. Pas par AMD mais par un développeur de chez Collabora. En juillet 2024 Faith Ekstrand a proposé un merge request à Mesa pour porter le pilote RADV sous Windows. En octobre 2024 lors de l’XDC (X.Org Developer's Conference), Faith Ekstrand avait présenté l’avancement de son travail lors de sa conférence « A little Windows with your Mesa » [pdf] et a fait une démonstration technique en montrant une démo Vulkan tourner sous Windows 11 avec RADV.
En l’occurrence il s’agit de faire fonctionner RADV sur WDDM (Windows Driver Display Model) au lieu du DRM (Direct Rendering Manager) de Linux.
Il s’agit pour le moment d’une démonstration, le code n’a pas été fusionné dans Mesa, et le fil de discussion de cette merge request n’a pas bougé depuis 2024.
Mais cela prouve que oui c’est tout à fait faisable, et que si AMD le souhaite, ils savent même à qui demander pour que cela devienne une réalité, il leur suffit de contracter avec Collabora à cette intention.
amdgpu mon amour
Les cartes graphiques AMD modernes, c’est-à-dire à partir de l’architecture GCN (RDNA est une évolution de GCN), peuvent toutes utiliser le pilote noyau amdgpu. Les cartes les plus récentes requièrent amdgpu, mais les cartes les plus anciennes peuvent utiliser soit l’ancien pilote radeon, soit le pilote amdgpu plus moderne. Jusqu’à très récemment sous Linux les cartes de génération GCN1 et GCN2 utilisaient encore le pilote radeon par défaut.
Le pilote amdgpu est requis pour faire autre chose que de l’OpenGL. Si vous utilisez le pilote radeon, RADV ne fonctionne pas (pas de Vulkan pour vous !). RustiCL ne fonctionne pas (pas d’OpenCL pour vous), et OpenGL ne propose pas une implémentation aussi complète. Par exemple vous pourriez n’avoir qu’OpenGL 4.1 au lieu d’OpenGL 4.5.
Utiliser le pilote amdgpu et donc débloquer toutes ces fonctionnalités de Mesa est une simple option de démarrage, mais puisque cette option n’est pas activée par défaut, la plupart des utilisateurs de ces cartes n’utilisent donc pas Vulkan.
Un gros travail a été fait pour s’assurer que le pilote amdgpu soit au même niveau que le pilote radeon pour ces anciennes carte, et à partir de la version 6.19 du noyau Linux, toutes les cartes GCN sans exceptions utilisent le pilote amdgpu. Cela signifie que tout le monde ayant une carte graphique AMD de génération GCN ou suivante aura accès à RADV et donc à Vulkan sans rien configurer !
Dans tous les cas, utiliser amdgpu était nécessaire pour utiliser Vulkan avec ces cartes, AMDVLK aussi ne fonctionnait qu’avec amdgpu.
Ça fait longtemps que les utilisateurs de ces cartes utilisent RADV avec amdgpu, car AMDVLK avait abandonné ces cartes depuis longtemps. Par exemple la prise en charge des cartes GCN 1 à 3 avait été abandonnée par AMDVLK après la version 2021.Q2.5, et donc en 2021. La prise en charge des cartes GCN 4 et 5 avait été quand à elle abandonnée après la version 2023.Q3.3, et donc en 2023.
RADV était déjà la meilleure solution pour les utilisateurs de ces cartes, car c’était le pilote Vulkan le plus à jour. Mais jusqu’à maintenant les utilisateurs de carte GCN 1 et 2 devaient modifier leur configuration d’amorçage pour profiter de RADV et donc de Vulkan !
Cette situation est désormais terminée ! Timur Kristóf de chez Valve a travaillé dur pour compléter et fiabiliser la prise en charge GCN 1 et 2 dans le pilote amdgpu. Il a présenté ce travail en novembre lors de la XDC 2025 pendant sa conférence « A love song for gamers with old GPUs » [pdf, blog]. Une « pull request » été ensuite été proposée par le mainteneur Alex Deucher pour faire d’amdgpu le pilote par défaut à partir du noyau Linux 6.19.
Timur Kristóf ne s’arrête pas en si bon chemin, et pour ceux qui lisent l’anglais, Phoronix rapporte la progression incroyable qu’il apporte à amdgpu :
- 01/01/2026 : More Improvements To Old AMD GPU Support On Linux Are Planned For 2026
- 19/01/2026 : New Patches From Valve Bring AMDGPU Power Management Improvements For Old GCN 1.0 GPUs
- 29/01/2026 : Valve Developer Improves Aging AMD APUs On Linux With VRR, DP/HDMI Audio, HDR & Atomic
- 21/02/2026 : Linux 7.0 Lands More AMDGPU Fixes For Old Radeon Hardware
- 22/02/2026 : Yet Another Fix Coming For Older AMD GPUs On Linux - Thanks To Valve Developer
AMD abandonne peut-être son pilote (AMDVLK)… mais c’est parce que le pilote AMD (RADV) est vraiment très bon. 😉️
Et tout ceci a été rendu possible par l‘initiative amdgpu qu’AMD a initié en 2014, il y a 12 ans ! Grâce à ce pilote noyau taillé comme la brique fondamental de tout ce qui peut être fait avec une carte AMD, toutes sortes de pilotes divers et variés ont pu être écrits, comme RADV et d’autres. 🙂️

# Comment ça se programme ?
Posté par jch . Évalué à 5 (+4/-0).
Comment ça se programme ?
Supposez que j'écris un programme de traitement d'audio en C, et il s'avère qu'il est un petit peu trop lent. Je décide d'accélérer la boucle interne en AVX2, ça améliore un peu les performances, mais clairement c'est une application pour le GPU.
Pour NVidia, c'est facile, dix lignes de boilerplate CUDA qui copie le clip audio vers la mémoire « globale » (la VRAM), je recompile ma boucle interne pour le GPU, et j'ai fini.
Comment je fais pour que ça marche aussi sur AMD ? Points en plus si ça inclut les iGPU Intel (les derniers modèles sont carrément compétitifs, au moins en puissance de calcul).
[^] # Re: Comment ça se programme ?
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 7 (+4/-0).
Il me semble que tu peux faire ça avec OpenMP et le compilateur Clang d’AMD.
En gros il suffirait d’ajouter des
#pragma ompà ton code et d’utiliser-fopenmp --offload-arch=<l’architecture AMD>à la ligne de commande clang, ou quelque chose comme ça.Mais ça c’est une fonctionnalité de ROCm, et le sujet de la dépêche c’est RADV et donc en partie Vulkan compute. Et Vulkan compute c’est pas aussi intégré. En gros l’état des choses c’est que pour le codeur Vulkan compute c’est plus compliqué, mais pour l’utilisateur c’est mieux parce que ça marche partout.
Alors que les trucs à la ROCm, bah ça marche surtout sur la machine du développeur en mode chezmoiçamarche™. CUDA a en partie le même problème, mais son écrasante domination et la maturité du bousin, contrairement à ROCm, fait que ça marche quand même mieux chez les autres.
Typiquement pour Whisper, j’ai arrêté d’utiliser ROCm, ça marchait sur une carte et demi. Et en plus ça mettait des plombes rien qu’à démarrer le python… Alors qu’avec whisper.cpp en Vulkan sur RADV, ça marche partout. Pour l’utilisateur c’est royal.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Comment ça se programme ?
Posté par jch . Évalué à 2 (+1/-0).
Ah, j'avais oublié le offload d'OpenMP (j'avais appris OpenMP à l'époque de la version 2, et je ne me suis toujours pas habitué à l'idée que ça marche aussi pour les GPU). Je n'ai pas réussi à trouver d'étude qui explique quels sont les cas dans lesquels ça marche bien, mais ça vaut probablement la peine d'essayer.
Peut-être faudrait-il que j'essaie encore, mais pour moi, c'est inutilisable. L'API est encore plus complexe que celle d'OpenCL, sans bonne raison, et le langage de shading n'est pas adapté pour le calcul.
Oui, les gens de whisper.cpp ont fait du bon boulot, leur implémentation Vulkan a des performances comparables à leur version Cuda. Mais au prix de combien d'années d'efforts!
[^] # Re: Comment ça se programme ?
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0).
il y a peut-être des trucs intéressants sur https://gpuopen.com/learn/developing-vulkan-apps/ ?
tu fais comment pour chercher des exemples représentatifs pour se mettre le pied à l'étrier ?
[^] # Re: Comment ça se programme ?
Posté par jch . Évalué à 3 (+2/-0).
Je ne suis pas spécialiste, j'espère que quelqu'un de compétent me corrigera.
Le bon cas, c'est tous les algos trivialement parallélisables, sans divergence, et sans trop de pression sur la mémoire. Le hachage parallèle (hashcat), l'évaluation Monte Carlo, ou, pour faire une jolie démo, l'ensemble de Mandelbrot. (C'est assez impressionnant, Mandelbrot sur un GPU, même sur un iGPU de base, c'est instantané.)
Le moyen cas, c'est quand ça reste parallélisable sans divergence, mais c'est les temps de transfert qui dominent. C'est tout ce qui est convolutions, produits scalaires (donc réseaux de neurones), produits de matrices, etc. Ça inclut les filtres d'images et de vidéo, dont il y a plein d'exemples dans les sources de mpv. La difficulté, c'est les accès à la mémoire, l'architecture de la mémoire dans les GPU est complètement expicite, à la différence des CPU il faut gérer le cache manuellement. Et pour ce genre d'algorithmes, il faut un GPU discret, ça ne marche pas du tout sur les iGPU.
Le cas amusant, c'est quand intuivivement il y a des dépendances, mais des gens plus intelligents que moi arrivent quand-même à paralléliser. Il y a des gens qui font des tris sur GPU, l'algorithme du scan, etc. J'essaie de lire les articles à ce sujet, mais pour le moment ça me dépasse.
[^] # Re: Comment ça se programme ?
Posté par BAud (site web personnel) . Évalué à 2 (+1/-1).
j'aurais préféré des URL ;-) bon, j'ai cherché un peu…
avec https://duckduckgo.com/?q=mandelbrot+set+equation+gpu+compute+vulkan&t=ftsa&ia=web
je trouve
https://vulkano.rs/05-images/04-mandelbrot.html code d'un bouquin d'API Vulkan en Rust avec le code https://github.com/vulkano-rs/vulkano-book/blob/main/chapter-code/05-images/mandelbrot.rs sous licence libre MIT et Apache 2.0
https://github.com/pjhusky/vulkan-compute-tests "simple démo" licence libre MIT
https://asher-siddique.medium.com/generating-the-mandelbrot-set-using-cuda-cefacf1a0157 Mandelbrot mais avec CUDA, pas trouvé de licence :/
https://mandelbrot-metal.com/gallery utilisation du framework Metal d'Apple sur iPad et iPhone (c'est portable ?), pas trouvé de licence :/ https://mandelbrot-metal.com/gpu-pipeline c'est ballot, ça revient sur CPU pour plus de précision o_O
https://github.com/cledant/vk_mandelbrot visualisation en Vulkan/C++, licence MIT, date de 4 ans…
faudrait voir côté G'MIC, Xaos, gnofract4d, MathMod, Zhu3d voire vkQuake ce que ça peut donner ;-)
# J'envisage sérieusement d'abandonner Nvidia pour ma prochaine carte Video
Posté par syj . Évalué à 5 (+4/-0).
Hello,
Merci pour l'article.
Perso ,je n'en peux plus des pilotes NVidia qui me font planter l'upgrade ma Ubuntu.
Je pense sérieusement à passer sur AMD pour ma prochaine carte vidéo.
[^] # Re: J'envisage sérieusement d'abandonner Nvidia pour ma prochaine carte Video
Posté par Axone . Évalué à 5 (+3/-0).
C'est exactement ce que j'ai fait il y 2-3 ans. J'en avais marre des mises à jour du système qui ne se passait pas toujours bien à cause de la carte NVIDIA. Je suis alors passé sur AMD et quelle sérénité depuis… Je suis sous opensuse tumbleweed
# Juste une remarque à deux balles
Posté par Miguel Moquillon (site web personnel) . Évalué à 3 (+2/-0).
Article très intéressant est, à mes yeux, bien complets.
Une petite remarque : llama.cpp n'est pas un LLM. C'est un moteur d'inférence de LLM, à l'origine écrit par Georgi Gerganov pour faire tourner le LLM de Meta Llama en local, sur des machines "basiques".
[^] # Re: Juste une remarque à deux balles
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 3 (+0/-0).
Bien vu ! En effet un « LLM d’inférence » ne veut rien dire, on dit bien un « moteur d’inférence ». =)
Si un modéro peut corriger:
J’ai remarqué que beaucoup disent simplement « moteur d’inférence LLM » mais l’absence de préposition semble être un anglicisme. D’autres préfèrent la préposition « pour » en disant « moteur d’inférence pour LLM ».
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Juste une remarque à deux balles
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Corrigé, merci.
# La temporalité
Posté par Narann (site web personnel) . Évalué à 1 (+0/-0).
Si je me souviens bien de la temporalité :
J’ai plus les sources, mais j’avais vu une conférence du dev de RADV.
[^] # Re: La temporalité
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Oui RADV a été initié par David Airlie avec l’aide de Bas Nieuwenhuizen :
Au final, la « pression » c’est qu’AMD a carrément lâché son propre pilote (mais l’avaient quand même libéré depuis longtemps)
L’histoire a montré que c’est AMDGPU-PRO qui a été abandonné en faveur de RADV, et pas l’inverse. 🙂️
Cela me fait remarquer que RADV aura dix ans cet été (déjà !), et me rappelle que RADV était initialement inspiré de anv, le pilote Vulkan pour Intel de chez Mesa (développé par Intel). Donc AMD vient de basculer sur un pilote qui a historiquement un héritage technique Intel:
Croustillant. 😄️
ce commentaire est sous licence cc by 4 et précédentes
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.