Nous en avions parlé en mars dans l’article « AMD mise tout sur RADV » : Maintenant qu’AMD a remplacé son pilote graphique AMDVLK sous Linux par le pilote RADV de chez Mesa, il est techniquement possible de faire de même sous Windows, unifiant les solutions graphiques sur un pilote libre quel que soit le système…

RADV est le pilote graphique libre fournissant la prise en charge de l’accélération 3D via Vulkan sous Linux. Il est développé communautairement chez Mesa.

Et cette fois-ci, c’est Valve qui mise tout sur RADV : l’éditeur de la plate-forme de jeu vidéo Steam finance des travaux explorant la faisabilité de RADV sous Windows !

L’automne arrive, mettons nos cartes graphiques AMD bien au chaud auprès de nos pilotes libres…

Cette dépêche est aussi l’occasion de détailler l’implication de Valve dans Mesa ainsi que la présence grandissante de Mesa dans le marché des pilotes graphiques, qui s’étend désormais bien au-delà de Linux !

Sommaire

• Vulkan, la solution graphique multiplateforme
• RADV, le pilote Vulkan libre pour carte AMD de chez Mesa
  • RADV, le pilote qui s’impatientait d’AMD
  • RADV, le pilote qui a déjà remplacé AMDVLK sous Linux
• RADV à l’attaque de Windows
  • L’expérimentation de Faith Ekstrand
  • La confirmation de Louis-Francis Ratté-Boulianne
  • Une alternative à Dozen
• L’implication de Valve dans RADV et Mesa
• Mesa part conquérir le monde
  • Et pour OpenGL sous Windows ?
  • Et DirectX 12 dans tout ça ?
  • Tout ce qui tourne sur RADV
  • Et pour Vulkan sur macOS ?
  • Et pour Intel et Nvidia sous Linux et Windows ?
  • Mesa prend le contrôle des pilotes Vulkan

Pour simplifier la rédaction et la lecture, cette dépêche fait le choix éditorial d’appeler « pilote graphique » un pilote qui implémente des interfaces de programmation graphique (Vulkan, DirectX, OpenGL, etc.), et pas seulement un pilote impliqué dans le pilotage d’une carte graphique. Ainsi l’expression « pilote graphique » est utilisée pour être distinguée du « pilote noyau » (ou KMD, Kernel Mode Driver) qui s’interface directement avec le matériel mais ne fournit pas d’interface de programmation graphique comme Vulkan et les autres.

Vulkan, la solution graphique multiplateforme

Vulkan est une API graphique multiplateforme utilisée pour accélérer des applications graphiques comme des jeux vidéo, les effets de composition de votre bureau, des applications de rendu 3D comme Blender, ou encore pour accélérer le calcul (Vulkan compute peut faire tourner des moteurs de LLM sur votre machine, par exemple).

RADV, le pilote Vulkan libre pour carte AMD de chez Mesa

À l’origine, le pilote Vulkan maison de chez AMD était AMDVLK, il était utilisé sous Linux et sous Windows. Initialement propriétaire, la version Linux avait été ensuite libérée.

Mais si vous utilisez Vulkan sous Linux, vous utilisez RADV, pas AMDVLK. Que s’est-il donc passé ?

RADV, le pilote qui s’impatientait d’AMD

En 2016, s’impatientant de cette libération promise qui ne venait pas encore, David Airlie — contributeur à Mesa — avait initié avec Bas Nieuwenhuizen le projet RADV, un compétiteur pour AMDVLK. Phoronix décrivait la situation ainsi en 2016 :

Plusieurs mois avant même la publication officielle de la spécification Vulkan, AMD avait annoncé qu’ils lanceraient dans un premier temps un pilote Linux Vulkan à code source fermé, qui serait ensuite ouvert. Plus de six mois se sont écoulés depuis la sortie de Vulkan 1.0, mais ce pilote Linux Vulkan n'a toujours pas été libéré, et AMD n'a pas non plus indiqué quand cette mise à disposition du code pourrait effectivement avoir lieu.

En l'absence de pilote Radeon Vulkan open source, David Airlie et Bas Nieuwenhuizen ont entrepris de développer leur propre pilote Radeon Vulkan « communautaire », au moins à titre de solution provisoire et éventuellement pour faire pression sur AMD afin qu’ils publient leur pilote Vulkan officiel. Bas Nieuwenhuizen est un contributeur indépendant, tandis que David Airlie est le responsable du sous-système DRM et un développeur chez Red Hat qui participe depuis longtemps aux efforts de développement de pilotes Linux AMD/ATI open source.
-- https://www.phoronix.com/review/radeon-vulkan-radv (30/08/2016)

David avait écrit à l’époque sur son blog :

J'attendais qu'un pilote open source fasse son apparition quand je me suis rendu compte que je ferais mieux de le développer moi-même. Après en avoir discuté avec Bas, nous avons décidé de voir jusqu'où nous pouvions aller.
-- https://airlied.livejournal.com/81460.html (20/07/2016)

RADV vient de souffler sa 10^ème bougie, et RADV a remplacé AMDVLK sous Linux et s’attaque désormais à Windows…

RADV, le pilote qui a déjà remplacé AMDVLK sous Linux

Comme rapporté dans la précédente dépêche « La pile graphique d’AMD sous Linux est désormais complètement libre », AMD avait annoncé le 21 mai 2025 que la version 25.10.1 de la suite Radeon Software for Linux serait la dernière à livrer des composants logiciels propriétaires. À l’époque AMD avait dit que « le pilote Vulkan de Mesa », (et donc, RADV) « sera officiellement pris en charge », et qu’ils abandonnaient les « pilotes OpenGL et Vulkan propriétaires ». On pouvait alors se demander ce qui adviendrait d’AMDVLK, si « le pilote propriétaire » devait s’entendre au sens de « le pilote à code fermé », ou dans le sens de « le pilote de chez AMD ».

L’histoire a montré que RADV a totalement remplacé AMDVLK sous Linux.

RADV à l’attaque de Windows

Grâce au travail préliminaire de Collabora et aux investissements de Valve pour poursuivre ces efforts, RADV pourrait bientôt être disponible sous Windows…

L’expérimentation de Faith Ekstrand

En juillet 2024 Faith Ekstrand avait proposé une requête de fusion à Mesa pour porter le pilote RADV sous Windows. Faith est un développeur de chez Collabora.

Quelques mois plus tard en octobre 2024 Faith Ekstrand avait présenté l’avancement de son travail lors de sa conférence « A little Windows with your Mesa » [pdf] lors de l’XDC (X.Org Developer's Conference). Une démonstration technique montrant une démo Vulkan tourner sous Windows 11 avec RADV avait été présentée.

Il s’agissait donc de faire fonctionner RADV sur WDDM (Windows Driver Display Model) au lieu du DRM (Direct Rendering Manager) de Linux.

Ce n’était qu’une démonstration, le code n’a jamais été fusionné dans Mesa, et la discussion n’avait pas bougé depuis. Cela prouvait pourtant que oui, cela était tout à fait faisable, et que si AMD le souhaitait, il leur suffisait de contracter avec Collabora.

La confirmation de Louis-Francis Ratté-Boulianne

C’est ce que vient de faire… non pas AMD, mais Valve, l’éditeur de la plate-forme de jeu vidéo Steam.

Comme le rapporte Phoronix :

Valve finance des ingénieurs de Collabora pour mener des travaux exploratoires préliminaires visant à porter le pilote open source Radeon Vulkan « RADV » sous Microsoft Windows.
-- https://www.phoronix.com/news/Valve-Sponsors-RADV-Windows (29/07/2026)

Le développeur Louis-Francis Ratté-Boulianne a rendu public ces travaux préliminaires dans un article sur le blog de Collabora intitulé « Cracking Windows Open: Porting RADV to WIN32 », Ouvrir une brèche vers Windows : porter RADV sur WIN32.

Louis-Francis précise que cette nouvelle expérimentation est fondée sur le travail déjà réalisé par Faith en 2024. Le projet est désormais à un niveau d’avancement élevé : le jeu Counter-Strike 2 (distribué, édité et développé par Valve) tourne déjà !

Une alternative à Dozen

Dozen (aussi connu comme VulkanOn12 chez Microsoft) est un pilote Mesa implémentant Vulkan sur DX12 (DirectX 12). Il est donc déjà possible d’utiliser un pilote libre Vulkan sous Windows, mais il est moins avancé que RADV, et il requiert le pilote propriétaire DX12 de la carte graphique, donc ici le pilote d’AMD. RADV s’interface directement avec le pilote noyau AMD sans intermédiaire graphique, permettant de bénéficier de tous les avantages de RADV déjà disponible sous Linux, dès lors que ce pilote Windows implémente des interfaces compatibles, sans dépendre des interfaces DX12 (contrôlées par Microsoft) ou du niveau d’implémentation du pilote DX12 d’AMD.

Le niveau de libération de la pile Vulkan sur AMD sous Windows peut donc être comparé ainsi :

Implémentation	RADV	Dozen	AMDVLK
Vulkan	libre	libre	propriétaire
Intermédiaire (DX12)		propriétaire
Pilote noyau (KMD)	propriétaire	propriétaire	propriétaire

L’implication de Valve dans RADV et Mesa

David Airlie et Bas Nieuwenhuizen ne sont pas les seules personnes ayant travaillé ou travaillant sur RADV, Samuel Pitoiset en est aussi un développeur incontournable. Samuel Pitoiset a été embauché par Valve en 2015 et est membre de la « Valve Linux driver team ». Samuel était en 2024 et en 2025 le plus gros contributeur Mesa (7.87% des commits de l’année en 2024, 6.78% en 2025).

Samuel participe aussi au développement d’ACO (Amd COmpiler), le compilateur de shader (code qui s’exécute sur la carte graphique. Principalement développé par Daniel Schürmann, le compilateur ACO a remplacé LLVM dans RADV (pilote Vulkan), et petit-à-petit, a aussi remplacé LLVM dans RadeonSI (pilote OpenGL) et dans RustiCL (pilote OpenCL). Daniel a été recruté par Valve en 2019.

Valve est un contributeur majeur de Mesa, finançant le travail de très nombreux développeurs. Il est difficile de suivre la carrière de chacun mais voici rassemblées quelques informations glanées ici ou là :

Contributeur Mesa	Relation avec Valve	Période documentée	Spécialité	Références
Samuel Pitoiset	Emploi	2016 → aujourd’hui	RADV, ACO, NIR	1 2 3
Andres Rodriguez	Emploi	au moins 2016	RADV, RadeonSI, AMDGPU, DRM	1 2 3
Keith Packard	Contrat (Indépendant)	au moins 2017 → 2018	RADV, ANV, DRM, affichage	1 2
Pierre-Loup Griffais	Emploi	au moins 2017 → aujourd’hui	RADV, Vulkan, Proton, Steam	1 2 3
Timothy Arceri	Emploi	2017 → période ultérieure	RadeonSI, GLSL, OpenGL	1 2
Connor Abbott	Emploi	2017 → période ultérieure	NIR, compilation, RADV, Turnip	1 2 3
Daniel Schürmann	Contrat (Indépendant)	2018 → au moins 2025	ACO, RADV, NIR	1 2 3
Tony Wasserka	Emploi	2020 → au moins 2024	RADV, Vulkan	1 2
Martin Roukala	Contrat (Indépendant)	2020 → aujourd’hui	Mesa CI, tests, infrastructure	1 2 3
Hans-Kristian Arntzen	Contrat (Indépendant)	au moins 2020 → aujourd’hui	RADV, Vulkan, VKD3D-Proton	1 2 3
Andrés Gómez	Sous-traitance (Igalia)	au moins 2020 → au moins 2021	Mesa CI, RADV, ANV, DXVK	1 2
Timur Kristóf	Contrat (Indépendant)	au moins 2021 → aujourd’hui	RADV, ACO, NIR	1 2
Natalie Vock	Contrat (Indépendant)	2022 → aujourd’hui	RADV, ACO, NIR, ray tracing	1 2 3 4
Charlie Turner	Sous-traitance (Igalia)	au moins 2022	Mesa CI, tests, RADV, ANV	1 2
Dhruv Mark Collins	Sous-traitance (Igalia)	2022 → aujourd’hui	Turnip, Adreno, Vulkan	1 2
Robin Kertels	Contrat (Indépendant)	au moins 2022 → aujourd’hui	KosmicKrisp, Vulkan, DXVK	1 2 3
Alyssa Rosenzweig	Contrat (Indépendant)	2023 → 2024	Panfrost, PanVK, AGX, NIR, compilation	1 2 3 4
Rhys Perry	Contrat (Indépendant)	au moins 2024 → 2026	RADV, ACO, NIR, ray tracing	1 2 3
Mike Blumenkrantz	Contrat (Indépendant)	au moins 2024 → aujourd’hui	Zink, RADV, Vulkan, infrastructure	1 2 3
Anna Maniscalco	Emploi	au moins 2024 → aujourd’hui	Turnip, Vulkan, Adreno	1 2 3
Mary Guillemard	Contrat (Indépendant)	2025 → aujourd’hui	NVK, Vulkan, pilotes NVIDIA	1
Thomas Andersen	Contrat (Indépendant)	au moins 2025 → aujourd’hui	NVK, Vulkan, NVIDIA	1 2
Danylo Piliaiev	Sous-traitance (Igalia)	au moins 2025 → aujourd’hui	Turnip, Adreno, Vulkan	1
Job Noorman	Sous-traitance (Igalia)	au moins 2025 → aujourd’hui	Turnip, NIR, compilateur	1
Autumn Ashton	Emploi	au moins 2025 → aujourd’hui	NVK, RADV, Vulkan, DXVK, VKD3D-Proton	1 2 3
Marek Olšák	Emploi	2026 → aujourd’hui	RadeonSI, Gallium3D, RADV	1 2
Louis-Francis Ratté-Boulianne	Sous-traitance (Collabora)	au moins 2026 → aujourd’hui	RADV, Vulkan, WDDM	1 2

La liste est très certainement incomplète, car d’autres personnes comme Louis-Francis Ratté-Boulianne peuvent travailler sur des missions de Valve sans travailler directement pour Valve. Ces personnes travaillent pour d’autres entités intermédiaires comme Collabora ou Igalia et les relations et le détail des missions ne sont pas forcément publiques ou faciles à trouver.

Dans cette table, la période documentée tente de retranscrire les périodes de contrat. Par exemple il est connu que Charlie Turner a travaillé pour Valve sur la CI (Intégration Continue) de Mesa en 2022 et nous savons aussi qu’il travaillait déjà sur ce même projet en 2021 sans qu’il soit évident si c’était déjà à la demande de Valve ou non.

Igalia et Collabora sont des sous-traitants et intégrateurs spécialisés dans le développement de solutions libres (pas seulement graphiques).

Mesa part conquérir le monde

Si un même pilote Vulkan peut fonctionner à la fois sur Linux et Windows, d’autres pilotes pour d’autres API ou d’autres matériels peuvent-ils suivre le même chemin ?

Et pour OpenGL sous Windows ?

Il est déjà possible d’utiliser une solution Mesa pour OpenGL sous Windows, grâce au pilote GLON12 développé par Microsoft chez Mesa. GLON12 convertit à la volée les appels OpenGL vers la solution propriétaire DirectX 12, et l’on peut déjà tester cette solution grâce à pal100 qui empaquette ces pilotes pour Windows. Cela dit, c’est fragile. La rédaction a testé, et les versions actuelles ont des bugs d’affichage assez sérieux (au moins avec le pilote propriétaire AMD sous-jacent), il faut remonter à 2024 pour avoir un rendu correct.

Il existe aussi chez Mesa le pilote Zink traduisant les appels OpenGL vers Vulkan, et donc jusqu’à maintenant, vers AMDVLK sous Windows. Mais si RADV devenait une solution sérieuse sous Windows, alors Mesa pourrait fournir OpenGL sous Windows en prenant en charge toute la pile d’exécution depuis OpenGL, s’arrêtant seulement à la limite du pilote noyau Windows, sans aucun logiciel intermédiaire tiers.

Et DirectX 12 dans tout ça ?

Là encore, RADV sous Windows permettrait aussi d’utiliser une solution libre pour DirectX ! Il existe plusieurs pilotes DirectX écrits pour convertir les appels Direct3D vers Vulkan initialement développés pour être exécutés dans Wine ou Proton sous Linux. Ces pilotes DirectX sont donc déjà écrits pour tourner dans un environnement Windows. Bien qu’ils soient moins testés sur un véritable Windows que dans un environnement Wine, ils existent. RADV serait la dernière brique pour court-circuiter entièrement les pilotes propriétaires graphiques sous Windows.

La couche la plus basse, le pilote noyau AMD, resterait propriétaire.

Tout ce qui tourne sur RADV

Voici ce qui est déjà faisable sous Linux, et ce qui serait bientôt réalisable sous Windows :

API	Solution possible Windows (aussi possible sous Linux)
Vulkan	RADV
OpenGL	Zink sur RADV
Direct3D 12	vkd3d sur RADV
Direct3D 9 à 11	DXVK sur RADV
Direct3D 8	D3D8-to-D3D9 sur DXVK sur RADV
OpenCL	RustiCL Zink sur RADV

Pour OpenGL et OpenCL utiliser Zink sur RADV n’est pas la solution recommandée sous Linux (mieux vaut utiliser RadeonSI et RustiCL), mais techniquement ça marche, c’est pourquoi on sait que ça pourrait aussi marcher sous Windows.

Donc grâce à Zink, Mesa pourrait fournir OpenGL sur les systèmes qui auraient RADV mais pas RadeonSI. De même pour OpenCL.

Voici un tableau plus général des opportunités que propose ou pourrait proposer l’écosystème libre (si RADV sur Windows devient viable) :

API	Solution recommandée Linux	Solution possible Windows et Linux	Autre solution possible Windows
Vulkan	Mesa RADV	Mesa RADV	Mesa Dozen (VulkanOn12)
OpenGL	Mesa Gallium3D avec Mesa RadeonSI	Mesa Zink sur Mesa RADV	Mesa GLON12 (OpenGLOn12)
Direct3D 12	vkd3d sur Mesa RADV	vkd3d sur Mesa RADV	vkd3d sur Mesa Dozen
Direct3D 9 à 11	DXVK sur Mesa RADV	DXVK sur Mesa RADV	DXVK sur Mesa Dozen
Direct3D 8	D3D8-to-D3D9 sur DXVK sur Mesa RADV	D3D8-to-D3D9 sur DXVK sur Mesa RADV	D3D8-to-D3D9 sur DXVK sur Mesa Dozen
OpenCL	Mesa RustiCL avec Mesa RadeonSI	Mesa RustiCL avec Mesa Zink sur Mesa RADV	Microsoft OpenCLOn12 avec Mesa CLOn12Compiler

Et pour Vulkan sur macOS ?

Valve est d’abord une plate-forme de vente de jeux vidéo. Ce qui leur importe le plus, c’est que vous puissiez leur acheter des jeux (développés par eux ou par n’importe qui). À ce titre, il importe à Valve que le maximum de jeux fonctionne sur votre machine, quelle que soit votre machine. Valve peut donc, si nécessaire, décider de fournir à ses utilisateurs ses propres pilotes, distribués avec Steam.

En participant au développement de RADV sous Linux et Windows, Valve se donne le pouvoir de contrôler la qualité de la pile logicielle d’exécution des jeux qu’ils vendent, jusqu’au pilote graphique inclus.

Pour macOS, la solution n’est pas à voir du côté de RADV (les derniers macs n’ont plus de cartes graphiques AMD de toute façon), mais du côté de MolktenVK et KosmicKrisp, des pilotes libres convertissant les appels Vulkan vers l’API Metal de macOS.

Sur macOS Vulkan est déjà disponible grâce à MoltenVK, une implémentation propriétaire traduisant Vulkan pour l’API Metal de macOS. Valve a investi dans MoltenVK. Cela permet par exemple à Valve de faire tourner leur jeu Dota2 sur macOS et pouvoir continuer à le vendre aux utilisateurs de macOS sans se soucier de l’obsolétisation d’OpenGL sur macOS par Apple. Valve avait poussé à ce que MoltenVK soit libéré, ce qui fut fait en 2018 grâce à un travail conjoint de Valve, de The Brenwill Workshop (la société à l’origine de MoltenVK), LunarG et Khronos. LunarG est un autre sous-traitant spécialisé dans les solutions graphiques et Vulkan libres. Khronos est le consortium à but non lucratif définissant le standard Vulkan. Le code source de MoltenVK est hébergé par Khronos directement.

KosmicKrisp est lui un pilote Mesa qui fait de même (convertir Vulkan vers Metal) mais de façon intimement spécialisée pour les puces AGX que l’on trouve dans les ordinateurs Apple M1, M2, etc. (aussi appelé « Apple Silicon »).

Et pour Intel et Nvidia sous Linux et Windows ?

Pour les utilisateurs Linux utilisant une carte Intel ou Nvidia, il y a déjà chez Mesa le pilote Vulkan officiel ANV développé par Intel, et le pilote expérimental NVK pour Nvidia. Il y a des connexions : Faith Ekstrand avait initié NVK chez Collabora et Collabora est connu pour travailler avec Valve… RADV pour AMD avait été initié en réutilisant du code d’ANV d’Intel… Tout cet écosystème est tissé de liens profonds que ce soit en termes de relations personnelles ou de mutualisation de code.

Pour les utilisateurs Windows utilisant une carte Intel ou Nvidia, rien n’est à l’horizon du côté de chez Mesa, excepté Dozen. Il faut donc utiliser les pilotes graphiques propriétaires de chez Intel et Nvidia (que ce soit le pilote Vulkan propriétaire directement, ou le pilote DX12 propriétaire comme sous-couche à Dozen). La situation est donc pour le moment la même qu’avec AMD sous Windows jusqu’à ce que RADV devienne utilisable pour le grand public.

Mesa prend le contrôle des pilotes Vulkan

Si on se concentre uniquement sur l’API Vulkan, voici ce que pourrait proposer l’écosystème libre dans un futur proche :

Système	Matériel AMD	Matériel Intel	Matériel Nvidia	Matériel Apple
Linux	Mesa RADV	Mesa ANV	Mesa NVK	Mesa Asahi
Windows	Mesa RADV	Mesa Dozen	Mesa Dozen
macOS	Khronos MoltenVK	Khronos MoltenVK	Khronos MoltenVK	Mesa KosmicKrisp

C’est une très bonne nouvelle. Vulkan avait été conçue pour devenir « l’API graphique universelle », sauf qu’au final le marché était resté très divisé : DX12 sur Windows, Metal sur macOS, Vulkan ailleurs (et ne parlons même pas des consoles…). La présence de Vulkan sous Windows dépendant entièrement du bon-vouloir des fabricants de carte graphiques, et ni Apple ni les fabricants de carte graphiques n’ont jamais développé un pilote Vulkan pour macOS…

Pour un distributeur de jeu vidéo comme Valve c’est excellent : ça signifie que si nécessaire, le jeu peut être distribué avec RADV sur Windows et Linux pour les utilisateurs de cartes graphiques AMD, et MoltenVK ou KosmicKrisp sur macOS afin de fournir une expérience Vulkan finement contrôlée, et autres combinaisons sus-mentionnées. Cela permet de contrôler et donc d’assurer au maximum la compatibilité d’un jeu.

Pour les développeurs et éditeurs de jeu, le bénéfice est le même. Si nécessaire, il devient possible d’indiquer au distributeur un pilote libre à intégrer avec le jeu.

Pour le joueur, il peut utiliser lui-même une autre option s’il la préfère ou en a besoin.

Ainsi, que ce soit avec des solutions propriétaires ou libre, Vulkan est déjà disponible quasiment partout, et le devient désormais encore plus souvent sous forme de pilote libre, grâce à Khronos et Mesa.

• Dis Mesa, tu veux faire quoi cette nuit ?
• La même chose que chaque nuit, Vulkan, tenter de conquérir le MONDE !

À 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 définitions…
• 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.
• 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 fourni 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 étaient 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 définitions…

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 définitions 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 !

🥂🍾