Sommaire
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 LLM (large langage model) d’inférence 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 :
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. 🙂️
Connexion
