Un hadron est une particule composite, composée de particules subatomiques régies par l'interaction forte, nous dit Wikipédia. Si cela vous fait penser à Proton, ce n’est peut-être pas parce qu’un proton est un hadron, mais parce que Hadron, comme Proton, promet de faire tourner vos jeux (et plus) n’importe où, même sur des systèmes terreux.

Vous connaissez peut-être Proton, l’assemblage de Wine et d’autres composants libres que Valve emploie pour faire tourner des jeux Windows sous Linux pour sa plate-forme Steam. Hadron propose la même chose pour macOS.

Des jeux Windows ? Sous macOS ? Quel est le 🌀️💀️⚡️⁉️ de rapport avec LinuxFr.org et son objectif de promotion des logiciels libres ? C’est parce que Hadron est construit de briques libres du sol au plafond : Wine, FEX, Mesa, vkd3d…

Sommaire

• Pourquoi Hadron ?
• L’architecture de Hadron
  • FEX, le traducteur automatique d’instruction processeur
  • Wine, l’implémentation libre des API Windows
  • Mesa, Zink et KosmicKrisp
  • vkd3d-proton, DirectX 12 sur KosmicKrisp
  • mtld3d et DXMT, les plus anciens Direct3D sur Metal
• Win32 + Vulkan + AMD64, la plate-forme universelle ?

Le logiciel libre 7zFM pour Windows x86-64 s‘exécutant sur un Mac mini M1 sous macOS 27 sans utiliser Rosetta 2.

Le développement de Hadron est encore très jeune, confidentiel, mais très rapide et réactif. Votre serviteur a testé de faire tourner le jeu libre Unvanquished et a rencontré deux bugs (1, 2) qui ont tous deux été corrigés dans les deux jours (1, 2), et une nouvelle version incorporant les correctifs a été publiée sous cinq jours (1).

Les spéculations sur « qui est derrière Hadron » pourraient se tourner naturellement vers Valve, qui est le premier bénéficiaire économique d’un tel système, mais le README du projet Hadron est explicite : « It is unofficial. Hadron is not affiliated with or endorsed by Valve, Apple, CodeWeavers or any of the projects it builds on », « C’est un projet non officiel. Hadron n’est ni affilié à, ni approuvé par Valve, Apple, CodeWeavers ou l’un des projets sur lesquels il s’appuie ».

Il semble donc que Hadron soit simplement l’initiative de son auteur David Andrews (Broyojo), ni plus ni moins.

Au delà de la proximité de nom entre Hadron et Proton, Hadron reste délibérément focalisé sur Steam : la fenêtre qui s’affiche quand vous lancez Hadron ne sert qu’à intégrer Hadron à Steam, et les premières versions ne proposaient d’ailleurs pas d’option pour lancer un programme non-Steam (fonctionnalité ajoutée très rapidement en quelques jours aussi). Le but premier de Hadron est Steam, et quand vous rapportez un bug pour un jeu, il vous est demandé l’identifiant Steam de ce jeu (cet identifiant est heureusement optionnel).

Pourquoi Hadron ?

En 2027, Apple sortira macOS 28 et à cette occasion, a prévu de drastiquement réduire l’étendue de la compatibilité Rosetta 2. Rosetta 2 est le système de traduction automatique qui permet de faire tourner des binaires amd64 (x86-64) sur arm64 (Apple Silicon ici, dans les macs « M »). Rosetta 2 a un 2 parce que Rosetta premier du nom s’occupait de traduire les binaires PowerPC vers Intel il y a très longtemps. Par commodité nous dirons simplement Rosetta au lieu de Rosetta 2 dans la suite de l’article.

Apple a annoncé que Rosetta ne sera plus disponible pour les applications, mais qu’ils conserveront une petite sous-partie prévue uniquement pour faire tourner des vieux jeux non maintenus s'appuyant sur des bibliothèques pour Intel (« we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks » (source). C’est une affirmation super floue. Que restera-t-il de Rosetta ? Sur quoi pourra-t-on compter et ne pas compter ?

Pour Apple, décommissionner Rosetta a un intérêt : ne plus fournir toutes les bibliothèques systèmes en double, ne plus avoir à apporter de la maintenance et du code système pour l’architecture amd64, etc. Tout l’effort de migration vers arm64 est entièrement externalisé vers le développeur indépendant. Ça coûte très cher à l’échelle globale, mais rien du tout pour Apple, et leur clientèle est suffisamment captive pour que le développeur au milieu y soit contraint. Si un développeur échoue à porter son logiciel, le développeur perdra des ventes, mais pas nécessairement Apple. Ce n’est pas le problème d’Apple, surtout quand l’acquisition du logiciel a lieu probablement en dehors de leur marché. Ceci est d’autant plus vrai en dehors du jeu : un logiciel de production concurrent remplace facilement un autre s’il venait à disparaître.

Pour un consommateur de jeu, c’est insupportable : il ne veut pas perdre son jeu parce que le développeur ne le développe plus. Il y a un attachement affectif, le joueur y a investi une partie de sa vie, il peut être attaché à l’histoire, etc. Et si le jeu est encore développé, le joueur ne trouve pas d’intérêt à ce que le développeur se retrouve avec plus de travail qui ne lui apportera aucun changement en jeu. Rajouter gratuitement du travail au développeur de jeu n’apporte rien au joueur.

Et pour une plate-forme tierce de vente et de location de logiciels comme Steam et autre GOG GALAXY, c’est une catastrophe : si un développeur échoue à porter son logiciel, ou n’est plus disponible pour cette tâche, ce sont des ventes en moins pour le développeur et pour le vendeur. Un vendeur de jeux qui prend sa commission à chaque vente (et dont ce serait la première sinon la seule activité économique) a intérêt à ce que le moindre effort soit proposé aux développeurs de jeux.

L’architecture de Hadron

Ne pas confondre avec le Grand collisionneur de hadrons ! L’architecture de Hadron est très différente, mais fait aussi se rencontrer plein de particules élémentaires libres pour observer des effets très intéressants.

Diagramme de l’architecture de Hadron, telle que décrite dans la documentation du projet.

FEX, le traducteur automatique d’instruction processeur

Comme alternative à Rosetta pour traduire les instructions amd64 vers arm64 pour exécuter des logiciels, il existe au moins deux logiciels libres : FEX (dont le développement était initialement secrètement soutenu par Valve), et Box64 développé par notre ptitSeb national.

Ces deux logiciels libres ont été à la base développés pour s’exécuter sous Linux. Hadron a choisi FEX et le fait tourner sous macOS. Ainsi, plus besoin de compter sur Rosetta et d’être dépendant du bon-vouloir d’Apple !

Le choix de FEX correspond bien à l’écosystème de Valve : l’intégration de FEX peut prendre exemple sur celle déjà réalisée pour Steam sur le Steam Frame (un produit de réalité virtuelle tournant sous Linux et sur ARM), et permet d’hériter des tests déjà réalisés par Valve pour le Steam Frame.

En intégrant FEX, Hadron rend les jeux et autres logiciels indépendants de la volonté d’Apple d’abandonner la prise en charge de l’architecture x86.

Wine, l’implémentation libre des API Windows

On ne présente plus Wine, le logiciel libre qui permet de faire tourner depuis des décennies des programmes Windows sous Linux, BSD et macOS. En 2022 Arek Hiler avait prononcé la désormais célèbre phrase Win32 Is The Only Stable ABI on Linux, Win32 est la seule interface binaire de programmation qui soit stable sous Linux. Ce constat de l’ABI Win32 comme une interface très stable s’étend en fait bien au-delà des utilisateurs de Linux.

Wine est une brique fondamentale de Proton, la sous-couche de Valve pour faire tourner des jeux Windows sous Linux. Hadron fait de même pour macOS.

Hadron intègre donc FEX et Wine pour faire tourner des programmes Windows compilés pour x86 (32-bit et 64-bit) sur les macs exécutant macOS sur des processeurs ARM. L’héritage Wintel ne s’effacera donc jamais.

En intégrant Wine, Hadron rend les jeux et autres logiciels indépendants des interfaces de programmation de macOS.

Mesa, Zink et KosmicKrisp

Mesa est la collection de pilotes graphiques libres qui domine nos écosystèmes Linux et BSD. Mais Mesa propose aussi des pilotes pour d’autres plate-formes, comme Windows et macOS.

L’article Le pilote open-source Vulkan pour AMD “RADV” de chez Mesa bientôt disponible sous Windows ? posait ce constat en répondant à la question « Et pour Vulkan sur macOS ? » :

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 libre traduisant Vulkan pour l’API propriétaire 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.

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 vous le voyez venir en mille, Hadron intègre KosmicKrisp pour fournir la prise en charge de l’API graphique Vulkan. KosmicKrisp traduit les appels Vulkan vers l’Interface de programmation (API) propriétaire Metal.

En intégrant KosmicKrisp, Hadron rend les jeux et autres logiciels indépendants de la politique d’Apple refusant de prendre en charge le standard industriel Vulkan.

Mais, et pour OpenGL ? Zink est un pilote Mesa qui implémente OpenGL au dessus de Vulkan, quel que soit le système (Zink tourne déjà sous Linux et Windows, et donc aussi macOS comme on peut le voir). Voilà, problème résolu.

En fait macOS fournit déjà OpenGL, mais ils l’ont déclaré obsolète depuis longtemps et ne fournissent qu’une ancienne version 4.1 qui date de 2010 (16 ans déjà !) qui est 7 ans plus ancienne que la dernière version d’OpenGL (4.6).

Zink implémente donc OpenGL 4.6 et en intégrant Zink, Hadron rend les jeux et autres logiciels indépendant de la volonté d’Apple d’abandonner OpenGL.

Et au passage, Zink propose la dernière version d’OpenGL et est un pilote désormais bien connu des développeurs de jeu, c’est tout bénef !

Hadron a comme politique de favoriser Zink à la place de l’implémentation OpenGL maison d’Apple. Quand un des bugs donnés comme exemple et affectant Unvanquished a été rapporté, l’expérimentation avait été réalisée avant que Hadron ne propose un moyen simple de lancer un logiciel en dehors de Steam, et donc l’expérimentation avait été faite en appelant Wine directement sans passer par le lanceur de Hadron. Le développeur Broyojo a constaté en lisant le journal du moteur de jeu Dæmon que dans ces circonstances, le jeu utilisait l’implémentation OpenGL d’Apple, chose qu’il s’est empressé de corriger fissa. Et pour le coup, ce changement est ce qui a corrigé le bug, trop facile.

L’article sur RADV et Windows indiquait :

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.

Nous y sommes. À part que cette fois-ci, ce n’est pas Valve qui en aurait eu l’initiative.

vkd3d-proton, DirectX 12 sur KosmicKrisp

Là où Zink implémente OpenGL sur Vulkan, vkd3d-proton fait de même et implémente DirectX 12 sur Vulkan, lui-même implémenté par KosmicKrisp.

DirectX 12 est l’interface de programmation graphique propriétaire de Microsoft pour Windows, elle est similaire à Metal et Vulkan.

Un développeur de jeu libre n’en a pas besoin : il peut utiliser OpenGL ou Vulkan, mais de très nombreux jeux utilisent Direct X 12, et Hadron s’assure donc de fournir cette prise en charge.

Comme son nom l’indique, vkd3d-proton est une brique essentielle de Proton, et l’est aussi maintenant pour Hadron.

mtld3d et DXMT, les plus anciens Direct3D sur Metal

Vous connaissez peut-être le logiciel DXVK qui implémentent Direct3D 8, 9, 10 et 11 au dessus de Vulkan. Vous aviez peut-être entendu parlé de D9VK qui faisait de même pour D3D9 mais qui est désormais intégré à DXVK, ou WineD3D qui implémentait Direct3D 8, 9, 10 et 11 au dessus de OpenGL.

Proton utilise DXVK sous Linux, implémentant donc D3D sur Vulkan, et Hadron pourrait faire de même, à la façon dont c’est effectivement implémenté avec vkd3d-proton.

Mais il existe deux logiciels qui implémentent D3D sur l’API Metal directement, ce qui permet de supprimer une couche intermédiaire de traduction.

Ces deux logiciels libres sont mtld3d qui implémente D3D9 sur Metal, et dxmt qui implémente D3D10 et D3D11 sur Metal.

Pour D3D8, Hadron ne précise pas si quelque chose est prévu, mais il devrait être possible d’utiliser DXVK, ou encore d3d8to9 qui implémente D3D8 sur D3D9. Et on peut supposer que rien ne devrait techniquement empêcher d’utiliser dd7to9 et autres projets de ce type (voir dxwrapper pour plus de détails).

Win32 + Vulkan + AMD64, la plate-forme universelle ?

Pour un développeur de logiciel libre, ces APIs DirectX sont peu utiles, mais tout le reste de cet écosystème peut profiter aux développeurs de logiciels libres.

Les compilateurs libres du projet MinGW permettent de compiler pour Win32. Wine permet de faire tourner ces programmes Win32 ailleurs que sur Windows. Et en s’appuyant sur les API graphiques OpenGL ou Vulkan, et des bibliothèques comme OpenAL ou SDL pour le son, le fenêtrage et les entrées, un développeur de jeu libre peut donc produire un seul binaire entièrement libre de la tête aux pieds qui tourne partout, sous Linux, BSD, macOS ou Windows.

Alors bien évidemment, certains préféreront un programme natif à leur système, avec de bonnes raisons. Mais quand un lanceur comme Steam ou une alternative libre comme Lutris fait toute l’intégration pour vous, tout ce qui retient se réduit à un attachement affectif (et ça compte beaucoup). C’est un chagrin légitime mais il n’empêche pas de jouer.

Wine fait déjà tourner naturellement les programmes x86 sur Linux et autres BSD. FEX peut être associé à Wine pour faire tourner des programmes Windows x86 sous Linux et macOS sur les processeurs ARM. Et Box64 sait faire de même sous Linux, non-seulement sur ARM64, mais aussi sur PowerPC (en mode petit-boutiste), RISC-V et Loongson.

Certains ont pu déclarer que « AMD64 is the new Java », en réalité, c’est peut-être la triforce Win32 + Vulkan + AMD64 qui est ce nouveau Java. Vous ferez peut-être autant la grimace, mais ça ne marche pas moins.

Et avec Hadron, votre prochain environnement de développement pour macOS pourrait simplement être MinGW, trop bien !

Avec Hadron, le futur de macOS court-circuite tout macOS, et Apple ne peut rien y faire.

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 :

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à :

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 :

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) :

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 :

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 !