La pile graphique dâAMD sous Linux est dĂ©sormais complĂštement libre
Ă 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.
Nos logiciels libres sont plus sereins lorsquâils reposent sur des pilotes libresâŠ
Sommaire
- Lâoffre complĂštement libre de pilotes graphiques AMD sous Linux
- RADV officiellement supporté
- Ce que support veut dire
- Le départ des derniers
- Adieu OGLP
- Adieu AMDVLK-Pro
- Adieu AMF
- Souvenir des pilotes AMD abandonnés sur le bord du chemin
- Mais⊠et les firmwares�
- PrĂ©fĂ©rer le DisplayPort Ă lâHDMI pour les trĂšs hautes rĂ©solutionsâŠ
- Prochain objectifâŻ: lâuniversalitĂ© du calcul et de la virtualisationâŻ?
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.
- AMD ROCm pour une sélection de cartes RDNA2 et suivantes (pilote officiel),
-
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 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
.
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 pour le jeu Unvanquished 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 (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 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âŻÂ». 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, 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. 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, 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 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 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 ne prenait en charge quâun seul accĂ©lĂ©rateur⊠Il a Ă©tĂ© annoncĂ© 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âŻ!
đ„đŸ
Commentaires : voir le flux Atom ouvrir dans le navigateur