URL: https://linuxfr.org/news/la-pile-graphique-d-amd-sous-linux-est-desormais-completement-libre Title: La pile graphique d’AMD sous Linux est désormais complètement libre Authors: Thomas Debesse BAud, Benoît Sibaud, cli345, Voltairine et NeoX Date: 2025-05-30T19:02:56+02:00 License: CC By-SA Tags: amd, carte_graphique et pilote_libre Score: 3 À l’occasion de la sortie de la version 25.10.1 de la suite _Radeon Software for Linux_ du 21 mai 2025, AMD a annoncé que la série 25.10 est la dernière à livrer des composants logiciels propriétaires. Ces composants propriétaires étaient déjà optionnels depuis bien longtemps, la plupart des utilisateurs de cartes AMD ne s’en servait déjà pas, et le plus grand nombre ignorait peut-être jusqu’à l’existence de certains d’entre eux… Ce jalon est l’accomplissement de 18 années d’un travail acharné commencé en 2007 avec la publication de documentations des cartes graphiques ATI après le rachat par AMD… Les plus anciens se souviendront de _RadeonHD_… Et désormais, ce sont les derniers bouts de logiciel propriétaire qui sont poussés vers la sortie. [![Autocollant LinuxFr.org cartes AMD par Thomas Debesse](https://dl.illwieckz.net/b/linuxfr.org/pilotes-amd-libres/20250702-235207-000.autocollant-linuxfrorg-cartes-amd.thomas-debesse.720.jpg)](https://dl.illwieckz.net/b/linuxfr.org/pilotes-amd-libres/20250702-235207-000.autocollant-linuxfrorg-cartes-amd.thomas-debesse.jpg) _Nos logiciels libres sont plus sereins lorsqu’ils reposent sur des pilotes libres…_ ---- [Radeon™ Software for Linux® 25.10.1 Release Notes (Annonce)](https://www.amd.com/en/resources/support-articles/release-notes/RN-AMDGPU-UNIFIED-LINUX-25-10-1.html) ---- # L’offre complètement libre de pilotes graphiques AMD sous Linux Voici comment se composera très bientôt l’offre officielle de pilotes graphiques AMD pour Linux : Noyau|Vulkan|OpenGL|HIP|OpenCL -|-|-|-|- Linux amdgpu|AMD AMDVLK ou Mesa RADV|Mesa radeonsi|AMD ROCm|AMD ROCm OpenGL et Vulkan sont des interfaces de programmation (API) graphiques, VA-API est une interface de programmation multimédia, et HIP et OpenCL sont des interfaces de programmation pour le calcul spécialement conçues pour satisfaire aux particularités architecturales des cartes graphiques. Il est à noter que même si vous n’utilisez pas la suite _Radeon Software for Linux_, votre distribution vous fournit déjà le pilote Linux et les pilotes Mesa mentionnés. - **Pilote noyau** * Linux _amdgpu_ pour les cartes GCN1 et suivantes (pilote officiel). - **Pilote graphique Vulkan** * AMD _AMDVLK_ pour les cartes RDNA1 et suivantes (pilote officiel) ; * Mesa _RADV_, pour les cartes GCN1 et suivantes (pilote officiel). - **Pilote graphique OpenGL** * Mesa _RadeonSI_ pour les cartes GCN1 et suivantes (pilote officiel). - **Pilote multimédia VA-API** * Mesa _RadeonSI_ pour les cartes GCN1 et suivantes (pilote officiel). - **Pilote de calcul HIP** * AMD _ROCm_ pour une sélection de cartes RDNA2 et suivantes (pilote officiel), _il n’existe pas d’autre implémentation de pilote HIP pour les autres cartes_. - **Pilote de calcul OpenCL** * AMD _ROCm_ pour une sélection de cartes RDNA2 et suivantes (pilote officiel) ; * Mesa _RustiCL_ pour les cartes GCN1 et suivantes. Ces pilotes concernent donc les cartes GCN et RDNA. La famille de cartes _GCN_ pour « _Graphics Core Next_ » sont les cartes sorties à partir de la série HD 7000 en 2012, aussi nommées « _Southern Islands_ » et qui ont inspiré le nom du pilote _RadeonSI_. La famille _RDNA_ pour « _Radeon DNA_ » ([ADN](https://fr.wikipedia.org/wiki/Acide_d%C3%A9soxyribonucl%C3%A9ique) Radeon) est une évolution de cette micro-architecture GCN et les cartes RDNA1 commencent avec les modèles RX 5000 en 2019 et les cartes RDNA2 avec les modèles RX 6000 en 2020. Le tableau suivant se limite aux générations de cartes graphiques pour lesquelles il existe au moins un pilote fonctionnel faisant partie de la suite officielle _Radeon Software for Linux_. Il s’agit donc seulement de compatibilité technique. Les générations et modèles officiellement pris en charge par le support commercial d’AMD est évidemment plus restreint, et plus fluctuant, et puis ça dépend de l’API… La compatibilité technique effective intéressera probablement plus le lecteur. |||||GCN1|GCN2|GCN3|GCN4|GCN5|RDNA1|RDNA2|RDNA3 |-|-|-|-|-|-|-|-|-|-|-|- |**Noyau**|Linux amdgpu|⭐️|🐧️|✅️|✅️|✅️|✅️|✅️|✅️|✅️|✅️ |**Vulkan**|AMD AMDVLK|⭐️||❌️|❌️|❌️|❌️|❌️|✅️|✅️|✅️ |**Vulkan**|Mesa RADV|⭐️|🐧️|✅️|✅️|✅️|✅️|✅️|✅️|✅️|✅️ |**OpenGL**|Mesa RadeonSI|⭐️|🐧️|✅️|✅️|✅️|✅️|✅️|✅️|✅️|✅️|✅️ |**VA-API**|Mesa RadeonSI|⭐️|🐧️|✅️|✅️|✅️|✅️|✅️|✅️|✅️|✅️ |**HIP**|AMD ROCm|⭐️||❌️|❌️|❌️|❌️|❌️|❌️|🧐️|🧐️ |**OpenCL**|AMD ROCm|⭐️||❌️|❌️|❌️|❌️|❌️|❌️|🧐️|🧐️ |**OpenCL**|Mesa RustiCL||🐧️|✅️|✅️|✅️|✅️|✅️|✅️|✅️|✅️ ✅️ = Pilote fonctionnel. 🧐️ = Pilote fonctionnel pour une sélection de modèles. ❌️ = Pilote non-fonctionnel. ⭐️ = Pilote faisant partie de la suite officielle _Radeon Software for Linux_ (pour RADV : après les versions 25.10). 🐧️ = Pilote empaqueté en standard dans les distributions Linux usuelles. La famille de cartes RDNA4 venant tout juste d’être mise sur le marché, conjecturer sa prise en charge est un exercice périlleux. On sait que le pilote ROCm n’est pas encore prêt, par exemple. Il est évident que les prochaines versions de tous ces pilotes les prendront en charge dans un futur proche. Les derniers pilotes graphiques AMD propriétaires qui subsistaient encore étaient donc les pilotes _OGLP_, _AMDVLK-Pro_, et _AMF_. Maintenant que tout est libre, ce qu’on attend désormais d’AMD est de faire fonctionner leur pilote de calcul HIP et leur pilote de virtualisation graphique GIM sur plus de matériel… # RADV officiellement supporté La phrase est explicite, à partir de la sortie de la suite _Radeon Software for Linux_ en version 25.20, « _The Mesa Vulkan driver will be officially supported_ ». Autrement dit, le pilote Vulkan de Mesa sera officiellement supporté par AMD. Le pilote Mesa pour les cartes AMD est _RADV_, initié originellement par Valve alors qu’_AMDVLK_ était encore propriétaire. Cette formulation n’exclut pas le pilote Vulkan libre _AMDVLK_ d’AMD. AMDVLK sera donc très certainement encore supporté comme il l’est déjà. Ce qui va changer pour Vulkan concerne AMDVLK-Pro, c’est ce que signifie la phrase « _The AMD proprietary OpenGL and Vulkan drivers will no longer be included in the release_ », qui signifie aussi que le pilote OGLP pour OpenGL est également poussé vers la sortie. # Ce que _support_ veut dire Ce terme de _support_ couvre les paquets de pilotes qu’AMD propose eux-mêmes, par exemple pour _Ubuntu_, _Red Hat Linux Entreprise_ ou _SUSE Linux Enreprise_, ce sont les paquets dans le dépôt [`repo.radeon.com`](https://repo.radeon.com/). Mais AMD participe déjà activement au développement de pilotes Mesa comme le pilote OpenGL _RadeonSI_. Apprendre qu’AMD ne fera pas que redistribuer mais supportera officiellement le pilote Mesa RADV dans sa suite de pilotes permet d’espérer une contribution similaire à RADV. En d’autres termes, si un bug affecte RADV, ils pourront considérer qu’il est de leur responsabilité de le corriger dans RADV directement. De plus, cela encourage désormais AMD à implémenter la prise en charge des futures cartes directement dans RADV avant que les cartes elles-mêmes ne soient mises sur le marché, ce qui était le principal argument en faveur d’AMDVLK-Pro et AMDVLK comparé à RADV. Ainsi, si vous utilisez une carte AMD et quand bien même vous utiliseriez le pilote RADV fournit par votre distribution, vous profiterez des effets de ces travaux de maintenance d’AMD comme vous en profitez déjà pour RadeonSI. C’est une très bonne nouvelle pour tout le monde car RADV est le pilote Vulkan installé par défaut (car faisant partie de la suite Mesa) par toutes les distributions Linux… et ce pilote devrait désormais profiter directement des efforts d’AMD. # Le départ des derniers Il est important de noter que parce que ces pilotes en espace utilisateur sont écrits pour fonctionner par-dessus le pilote noyau _amdgpu_, il reste toujours possible d’utiliser ces pilotes désormais abandonnés, que ce soit OGLP, AMF et AMDVLK-Pro qui nous quittent désormais, ou les plus anciens PAL et ORCA, pour ceux qui recherchent un environnement spécifique tout en utilisant une distribution très récente. Et ce sera probablement encore vrai pendant des années, à condition de conserver votre ancien matériel compatible avec ces pilotes désormais obsolètes. En réalité ça fait longtemps qu’il n’est plus nécessaire d’employer un logiciel propriétaire pour utiliser ses cartes graphiques AMD sous Linux. Toutes les API supportées par AMD avaient déjà des implémentations libres depuis longtemps. Ce qu’AMD est en train de faire est de se débarrasser définitivement des rares alternatives propriétaires qui survivaient encore… # Adieu OGLP OGLP était jusqu’à maintenant le pilote OpenGL propriétaire d’AMD sous Linux. AMD recommande le pilote libre Mesa RadeonSI pour OpenGL sous Linux depuis très longtemps. Le pilote libre Mesa RadeonSI lui est très supérieur, que ce soit en termes de fonctionnalité, de performance, et de qualité, et AMD contribue directement à ce pilote RadeonSI. Il est très probable que la majorité d’entre vous n’ait même pas connaissance que le pilote OGLP existait, ni même connaissait son nom. OGLP proposait une implémentation OpenGL et OpenGL ES. Mon expérience dans [l’évaluation de pilotes graphiques](https://wiki.unvanquished.net/wiki/GPU_compatibility_matrix) pour le jeu [Unvanquished](https://unvanquished.net/) m’a fait constater que le pilote OGLP présentait les mêmes bugs que le pilote propriétaire AMD pour Windows, Adrenalin. Il est donc extrêmement probable que c’était une simple recompilation du même pilote, mais pour Linux, comme à l’époque de _Catalyst_ et _fglrx_. En effet déjà à l’époque de _fglrx_ pour ATI, et encore aujourd’hui pour Nvidia, les pilotes propriétaires graphiques de ces concepteurs de cartes graphiques sont généralement exactement le même pilote quel que soit le système, avec une couche de compatibilité pour le système, ce qui est logique dans une optique de réduction des coûts de développement. OGLP était donc très certainement le pilote OpenGL de la suite _fglrx_, le pendant Linux du pilote Windows _Adrenalin_, mais porté pour le pilote noyau libre _amdgpu_ au lieu du pilote _fglrx_ abandonné il y a déjà des années. On pourra s’étendre en conjectures sur _pourquoi_ AMD maintenait encore le pilote OGLP jusqu’en 2025, il est probable que celui-ci répondait à des exigences contractuelles professionnelles. Sur le plan technique pendant longtemps le pilote Mesa s’était limité à implémenter seulement le « _core profile_ » d’OpenGL et pas le « _compatibility profile_ » qui pouvait être requis par certaines applications industrielles, et cela justifiait alors l’existence d’un pilote propriétaire pour satisfaire la clientèle. Mais Mesa a depuis implémenté ce « _compatibility profile_ » et ce depuis longtemps désormais, il est donc possible que ne subsistait plus que des exigences contractuelles — peut-être même pas techniques — pour justifier la fourniture de ce pilote OGLP. # Adieu AMDVLK-Pro Le pilote AMDVLK-Pro était en fait le pilote libre AMDVLK amalgamé de composants propriétaires. Le pilote AMDVLK est un pilote libre qui implémente l’API graphique Vulkan. Contrairement au pilote OpenGL officiel RadeonSI qui est développé en collaboration avec Mesa, le pilote Vulkan AMDVLK est développé exclusivement par AMD, mais c’est tout de même un pilote libre. Au tout début AMDVLK était aussi un pilote propriétaire mais conçu dès le départ pour devenir un pilote libre plus tard, avec la promesse qu’il soit libéré un jour. Le pilote AMDVLK, alors qu’il était encore propriétaire, avait permis à beaucoup d’utilisateurs de Linux de profiter des fonctionnalités Vulkan de leurs cartes graphiques AMD sans avoir à attendre un pilote libre, que ce soit AMDVLK lui-même une fois libéré, ou le pilote RADV développé par Mesa. Le pilote AMDVLK-Pro était donc en quelque sorte la continuité de ce pilote qui distribuait au plus tôt les fonctionnalités aux utilisateurs, en remettant à plus tard la libération de ces fonctionnalités. Quand AMDVLK avait été libéré, AMDVLK-Pro en était donc devenu la variante propriétaire qui implémentait et distribuait les dernières nouveautés. Là encore, il est pertinent de supposer que le pilote AMDVLK est construit sur la même base de code que le pilote Windows. Quand bien même existe désormais le pilote Mesa RADV pour Linux, il est peu probable que le pilote libre AMDVLK disparaisse de l’écosystème Linux de si tôt. Peut-être un jour AMDVLK, bien que libre, suivra le sort d’OGLP si un jour AMDVLK n’apportera rien de plus que RADV et ce depuis un temps certain ? L’avenir nous le dira. # Adieu AMF AMF (Advanced Multimedia Framework) s’en ira également, c’est une bibliothèque d’accélération matérielle pour le décodage et l’encodage de formats vidéo. AMD recommande d’utiliser à la place l’implémentation VA-API de Mesa. # Souvenir des pilotes AMD abandonnés sur le bord du chemin Parmi les pilotes AMD propriétaires conçus pour tourner sur le pilote noyau _amdgpu_, AMD a déjà abandonné _ORCA_ et _PAL_. C’était des pilotes de calcul OpenCL (conçus pour les cartes GCN 2 à 4 pour ORCA, et GCN 5 pour PAL) qui ont été remplacés par ROCm. On peut aussi supposer que PAL et ORCA était des portages du pilote OpenCL de Windows mais conçus pour tourner sur le pilote noyau _amdgpu_ à la manière d’OGLP et d’AMDVLK. Pour les plus pointilleux, [PAL](https://github.com/GPUOpen-Drivers/pal) (_Platform Abstraction Library_) était en fait le nom de la bibliothèque d’abstraction entre le code propriétaire commun et le système Linux, et par [métonymie](https://fr.wikipedia.org/wiki/M%C3%A9tonymie) on appelait _PAL_ le pilote OpenCL _qui utilise PAL comme interface_. Dans la même veine, certains parlent parfois de _ROCr OpenCL_ pour l’implémentation actuelle de OpenCL de la suite ROCm, ROCr étant le _ROCm Runtime_. Le nom _ORCA_ n’échappe probablement pas à cette règle d’usage, mais je n’ai jamais trouvé d’explication de ce nom (je ne suis même pas sûr que ce soit un acronyme), la chaîne `orca` était simplement utilisée dans le nom du paquet (par exemple : `opencl-orca-amdgpu-pro-icd`). PAL et ORCA ont longtemps été regrettés, car ils prenaient en charge la totalité des cartes de leurs générations, contrairement à ROCm. On peut lire à ce sujet sur LinuxFr.org l’article de 2022 « [_OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx_](https://linuxfr.org/news/opencl-sous-linux-l-etat-des-pilotes-amd-est-desormais-pire-que-ce-qu-il-etait-a-l-epoque-de-fglrx) ». Heureusement, Mesa fournit désormais _RustiCL_ qui leur est désormais supérieur sur bien des points. _Cela pourrait faire l’objet d’une dépêche à venir…_ 😉 Et avant cela, il y a bien longtemps avant de s’embarquer dans son aventure _amdgpu_, AMD fournissait la suite _Catalyst_ entièrement propriétaire, qui exécutait au-dessus du pilote noyau propriétaire _fglrx_ des pilotes propriétaires OpenGL et OpenCL pour le graphisme et le calcul. # Mais… et les firmwares ? Les micrologiciels (_firmwares_) des cartes graphiques ne sont toujours pas libres, mais ceux-ci ne s’exécutent pas avec le système d’exploitation de votre ordinateur dans le processeur principal de votre machine, ils s’exécutent dans la carte graphique directement, c’est donc un tout autre sujet. Certains réclament aussi la libération de ces micrologiciels, mais d’ici à ce que ce rêve devienne un jour réalité, si ce jour vient un jour, vous savez déjà que votre _Linux_, lui, il peut déjà prendre en charge toutes les fonctionnalités de votre carte avec des logiciels libres sous Linux. # Préférer le DisplayPort à l’HDMI pour les très hautes résolutions… Un petit couac cependant… Les pilotes AMD sous Linux ne peuvent légalement pas implémenter la version 2.1 du protocole [HDMI](https://fr.wikipedia.org/wiki/High-Definition_Multimedia_Interface), donc si vous avez besoin d’utiliser des résolutions telles que le 4K à 120 Hz ou le 5K à 240 Hz, il faut privilégier le [DisplayPort](https://fr.wikipedia.org/wiki/DisplayPort). Ce n’est pas la faute d’AMD : AMD avait en fait implémenté cette prise en charge mais n’a légalement pas le droit de la publier dans un pilote libre. [Le _HDMI Forum_ a restreint l'accès public aux spécifications en 2021](https://www.comptoir-hardware.com/actus/software-pilotes/47411-le-hdmi-forum-rejette-le-pilote-open-source-hdmi-21-damd.html), et publier cette partie du code du pilote serait contraire à ces nouvelles conditions. Ce code de prise en charge HDMI 2.1 est censé être implémenté dans le pilote noyau _amdgpu_, et AMD n’a aucune intention d’abandonner son pilote libre, alors que sa stratégie est précisément de tout libérer ! # Prochain objectif : l’universalité du calcul et de la virtualisation ? Enfin, je dis que « _Linux peut déjà prendre en charge toutes les fonctionnalités de votre carte avec des logiciels libres_ » mais si vous souhaitez profiter de ROCm et GIM ce n’est vrai qu’à condition de bien choisir votre carte. 😬 AMD a la volonté d’améliorer la situation de ROCm, tel [qu’en témoigne un sondage](https://github.com/ROCm/ROCm/discussions/4276) il y a quelque mois invitant les utilisateurs à exprimer leurs souhaits dans le cadre de l’effort d’AMD d’étendre la prise en charge. Mais ça prend du temps ! Et si, _se faire attendre, c’est se faire désirer_, il ne faudrait pas trop attendre pour AMD au risque que le désir se détourne vers d’autres propositions. Et du côté de la virtualisation de carte graphique (GPU-IOV), le pilote [GIM](https://github.com/amd/MxGPU-Virtualization/) est libre aussi mais la situation est encore pire : il ne prend en charge que deux accélérateurs (ces produits n’ont pas de sortie vidéo)… Certains diront que c’est un progrès car [la version précédente](https://github.com/GPUOpen-LibrariesAndSDKs/MxGPU-Virtualization) ne prenait en charge qu’un seul accélérateur… Il [a été annoncé](https://www.phoronix.com/news/AMD-GIM-Open-Source) qu’une prise en charge matérielle plus large serait « _sur la feuille de route_ » mais si ça prend le même temps que ROCm ou plus, il faudra se montrer très patient. 😄 En attendant, on peut célébrer cette victoire : _La pile graphique d’AMD sous Linux est désormais complètement libre !_ 🥂🍾