Collabora fait fonctionner sur Windows le pilote RADV de Mesa, l'implémentation Vulkan open source pour GPU AMD dont dépendent les joueurs Linux et le Steam Deck, jusqu'à y lancer Counter-Strike 2. Valve finance ces travaux, décrits comme exploratoires et non comme un produit. La difficulté ne vient pas du pilote mais de tout ce qui se trouve dessous : sur Windows, RADV doit dialoguer avec le pilote noyau propriétaire d'AMD à travers WDDM2, et l'équipe y parvient aujourd'hui en rétro concevant des structures de données privées qui peuvent changer à chaque nouvelle version. C'est toute la différence entre une démonstration et quelque chose de livrable.
The short answer
Collabora a publié le 28 juillet 2026 l'avancement de son portage du pilote Vulkan RADV de Mesa vers Win32, dans des travaux financés par Valve. Le pilote est passé du rendu de modèles 3D en rotation à l'exécution de Counter-Strike 2 avec son moteur Vulkan, en gagnant les liaisons éparses, la tessellation, les task shaders et l'interrogation dynamique des propriétés du GPU. Il atteint le GPU via des structures WDDM2 rétro conçues, la présentation passe uniquement par le CPU, et Collabora indique qu'un usage en production exige une interface noyau AMD documentée ou une bibliothèque intermédiaire stable.
Les pilotes graphiques voyagent d'habitude dans l'autre sens. Quelqu'un prend une pile Windows et la persuade de fonctionner sous Linux, généralement à travers une couche de traduction et beaucoup de patience. Collabora fait l'inverse, et ce qui mérite lecture n'est pas la nouveauté du geste. C'est ce sur quoi le portage est tombé.
Ce qui a été construit
RADV est le pilote Vulkan open source du projet Mesa pour le matériel AMD. Sous Linux, il se trouve sous la majorité du jeu en Vulkan, y compris tout ce que Proton traduit depuis Direct3D, et il explique en bonne partie les performances du Steam Deck. Sous Windows, ce rôle revient au pilote Vulkan propriétaire d'AMD.
Le billet de Louis-Francis Ratte-Boulianne retrace la progression. D'abord le rendu de base, le traditionnel modèle 3D en rotation. Puis les fonctionnalités qu'attend une vraie application : liaisons éparses, tessellation, task shaders, interrogation dynamique des propriétés du GPU, avec une gestion plus complète du flux de commandes et de la synchronisation. Puis Counter-Strike 2, lancé avec son moteur de rendu Vulkan, a tourné dessus.
Cette dernière étape est celle qui compte. Un jeu commercial sollicite bien plus d'API qu'une démonstration de conformité, et il le fait dans l'ordre désordonné qu'emploient les vrais moteurs.
Le blocage se situe sous le pilote
Un pilote Vulkan est un composant en espace utilisateur. Il lui faut malgré tout transmettre les commandes au matériel, et sous Windows ce chemin passe par WDDM2, le modèle de pilote d'affichage de Windows, puis par le pilote noyau propriétaire d'AMD.
Rien de cette interface n'est documenté pour les tiers. L'équipe rétro conçoit donc les structures de données privées attendues par le pilote noyau, ce qui fonctionne jusqu'au jour où AMD publie une mise à jour qui les modifie. Un pilote utilisateur bâti sur des structures non documentées n'est pas un pilote que quiconque peut supporter, aussi bien tourne t il aujourd'hui.
Collabora nomme les deux issues. Soit AMD fournit une interface stable et documentée vers son pilote graphique noyau sous Windows, soit quelqu'un construit une bibliothèque intermédiaire entre RADV et ce pilote noyau, qui absorbe la manipulation des structures privées. Les deux demandent la participation d'AMD.
La présentation, l'autre manque
La seconde limite est plus étroite mais a un coût direct en performances. Seule la présentation par le CPU est implémentée à ce jour. Les swapchains DXGI accélérées par le GPU et les échanges sans copie ne le sont pas.
La présentation est l'ultime étape de chaque image, le passage de l'image rendue à ce que le contrôleur d'affichage envoie à l'écran. La faire sur le CPU revient à copier des données qui n'auraient jamais dû bouger. Tout chiffre mesuré aujourd'hui mesure cette copie autant que le pilote, ce qu'il vaut mieux garder en tête avant toute comparaison.
Sous ces deux points se trouvent les agacements habituels du portage d'une base de code jamais compilée ailleurs que par GCC et Clang. MSVC traite les énumérations différemment, et il a fallu contourner cette différence.
Pourquoi Valve paie pour cela
L'intérêt de Valve n'a rien de mystérieux. L'entreprise vend du matériel Linux avec le Steam Deck et la Steam Machine, ses clients utilisent massivement aussi des PC Windows, et sa pile Proton canalise déjà Direct3D vers Vulkan des deux côtés. Aujourd'hui l'implémentation Vulkan sous jacente diffère selon la plateforme, ce qui signifie qu'un bug peut exister sur l'une et pas sur l'autre, et que le correctif de l'une appartient à un fournisseur plutôt qu'à Valve.
Un seul pilote sur les deux plateformes fait disparaître cet écart. Cela signifie aussi que le travail déjà financé par Valve sur RADV, considérable, profite aux utilisateurs Windows de ses logiciels au lieu de s'arrêter à la frontière de la plateforme. Nous avions relevé un schéma comparable de travail amont financé par un industriel dans les correctifs AMD P-State qui gagnent 31,8 % sur les 1 % low, où le gain mesurable arrive par le noyau plutôt que par un produit.
Comment le lire
Ce sont des travaux exploratoires, financés, publiés ouvertement, et honnêtes sur leurs limites. Faire tourner Counter-Strike 2 est une vraie étape, pas une date de sortie. La question qui décidera de la suite ne dépend pas de Collabora : elle dépend de la documentation par AMD de son interface noyau Windows, ou de son aide pour bâtir la bibliothèque intermédiaire. D'ici là, le produit intéressant est le compte rendu d'ingénierie, pas un pilote installable.
Sources et pour aller plus loin
- Collabora : Cracking Windows open, porting RADV to WIN32
- Phoronix : Valve finance le portage du pilote open source RADV vers Windows
- Documentation Mesa : le pilote RADV
- Discussion Hacker News de l'annonce
Questions fréquentes
Qu'est ce que RADV, et pourquoi le porter vers Windows ?
RADV est le pilote Vulkan open source du projet Mesa pour les cartes graphiques AMD. C'est lui qui fait tourner les titres Vulkan sur la plupart des configurations de jeu sous Linux, et une bonne part de la réussite du Steam Deck et de la Steam Machine tient à lui, puisque Proton traduit les appels Direct3D en Vulkan et que RADV les exécute. Sur Windows, AMD fournit à la place son propre pilote Vulkan propriétaire. Amener RADV sur Windows, c'est le même code de pilote, les mêmes correctifs et le même comportement sur les deux plateformes, ce qui élimine toute une catégorie de problèmes du type fonctionne sous Linux mais pas sous Windows et donne à Valve une pile qu'elle peut corriger elle même.
Où en est le portage ?
Plus loin qu'une preuve de concept, bien en deçà d'un produit. Collabora rapporte être passé du premier rendu de modèles 3D en rotation à l'exécution de Counter-Strike 2 avec son moteur de rendu Vulkan, en implémentant au passage les liaisons éparses, la tessellation, les task shaders et l'interrogation dynamique des propriétés du GPU, ainsi qu'un travail sur la gestion du flux de commandes et la synchronisation. Phoronix décrit l'effort comme exploratoire et en phase initiale, et le billet de Collabora est franc sur ce qui manque. Faire tourner un jeu commercial est une vraie étape pour un pilote graphique, parce qu'un jeu sollicite bien plus de surface d'API qu'une démonstration de conformité, mais ce n'est pas la même chose qu'être utilisable.
Qu'est ce qui bloque réellement ?
Trois choses, par ordre de gravité décroissante. D'abord l'interface noyau : sur Windows, le pilote doit atteindre le GPU via WDDM2 et le pilote noyau propriétaire d'AMD, et les structures de données privées en jeu ne sont pas documentées, donc l'équipe les rétro conçoit sans garantie qu'elles restent stables d'une mise à jour à l'autre. Ensuite la présentation : seule la présentation par le CPU fonctionne aujourd'hui, les swapchains DXGI accélérées par le GPU et les échanges sans copie n'étant pas implémentés, ce qui pèse lourd sur les performances puisque la présentation est la dernière étape de chaque image. Enfin les frictions ordinaires de portage, dont la gestion des énumérations par MSVC, différente de celle de GCC et de Clang.
Que faudrait il pour un usage en production ?
Collabora l'énonce clairement : soit une interface stable et documentée vers le pilote graphique noyau d'AMD sous Windows, soit une bibliothèque intermédiaire placée entre RADV et ce pilote noyau pour prendre en charge les structures privées. Les deux voies exigent la coopération d'AMD, car aucune ne peut tenir sur la seule rétro conception. Un pilote qui dépend de structures non documentées est un pilote qui casse à la prochaine mise à jour du fabricant, et aucun distributeur ne veut assumer cela. Tant que l'une des deux options n'existe pas, ces travaux restent exploratoires, quel que soit le nombre de jeux qui tournent.
Dois je m'attendre à l'utiliser sur ma machine Windows ?
Pas de sitôt, et peut être jamais directement. Ce sont des travaux exploratoires financés par une entreprise qui a un intérêt précis à disposer d'une pile de pilotes unifiée entre son matériel Linux et les PC Windows que ses clients utilisent toujours. Même dans le meilleur des cas, le chemin entre faire tourner Counter-Strike 2 en laboratoire et un pilote que n'importe quel utilisateur Windows installe passe par la présentation accélérée, une interface noyau supportée, et une longue traîne de jeux et d'applications. La lecture réaliste à court terme est que cela facilite le développement de RADV et donne un levier à Valve, un éventuel résultat grand public venant plus tard, si tant est qu'il vienne.