Linux's AMD Vulkan Driver Is Being Ported To Windows
Cette vidéo analyse le projet de portage du driver Vulkan open-source RADV (Mesa) vers Windows, financé par Valve, et explique pourquoi cette initiative pourrait transformer l’écosystème graphique Linux et Windows.
SYNTHÈSE STRUCTURÉE
Contexte : RADV, le pilier graphique Linux
L’intervenant rappelle que RADV est devenu le driver Vulkan de facto pour les GPU AMD sous Linux, au point que même AMD collabore directement au projet Mesa. Il souligne : « No one even considers the fact that there actually was a separate proprietary version that did exist at one point ». Cette adoption massive contraste avec NVIDIA, où les drivers propriétaires restent majoritaires malgré les efforts open-source comme Nouveau.
Le paradoxe Windows : DXVK utilisé par des joueurs Windows
Un point surprenant est l’utilisation de DXVK (outil de traduction DirectX vers Vulkan) par certains joueurs Windows, alors même que DirectX est natif sur cette plateforme. L’intervenant explique que dans certains jeux, cette approche donne de meilleures performances : « in certain games, under certain conditions, doing this will actually get you more performance ». Il suppose que Vulkan offre un accès plus direct au matériel, avec moins de couches intermédiaires.
Pourquoi porter RADV sur Windows ?
L’intérêt principal est la mutualisation du code entre plateformes. Un bug de rendu Vulkan trouvé sur Windows (où il y a plus de joueurs) serait corrigé plus vite et profiterait aussi à Linux. L’intervenant insiste : « if you can get RADV into a situation where gamers on Windows are using it, suddenly, problems which traditionally would have only been found when a Linux user eventually found it, are now being seen by a much larger user base ». Cela facilite aussi le travail des développeurs de jeux qui passent par Proton.
Le problème de l’abandon matériel par les drivers propriétaires
Les drivers propriétaires (AMD et NVIDIA) abandonnent régulièrement le support des anciennes cartes. Mesa, lui, maintient un support sur des décennies : « There are cards from 20 years ago, which are still getting updates to this day ». C’est un argument fort pour l’open-source, même si les cartes très anciennes restent limitées par les standards qu’elles supportent.
Les fondations techniques : WDDM2 et le travail de Faith Ekstrind
Le projet s’appuie sur les travaux de Faith Ekstrind, présentés à XDC 2024. Elle a démontré que l’interface WDDM2 (introduite avec Windows 10) offre une base bien plus propre pour un driver tiers que les versions précédentes. Elle définit clairement la séparation entre le driver en mode utilisateur (UMD) et celui en mode noyau (KMD).
Le défi des données privées opaques
Le principal obstacle est que les appels D3D KMT transportent des « private driver data » : des blobs opaques, spécifiques au vendeur, dont le contenu est totalement non documenté publiquement. L’intervenant précise : « It is documented. It is totally documented. Not the documentation that you’re going to see, though ». Cela signifie que UMD et KMD sont étroitement couplés, et que ces structures peuvent changer entre versions de drivers sans préavis.
L’outil de reverse engineering : WDDM2 PDD RE
Pour contourner ce problème, Faith a créé un outil de logging des appels WDDM2, capable de capturer les données privées pour des applications D3D12. Cette approche a permis de reverse-engineer suffisamment d’interface pour faire fonctionner RADV avec le driver noyau propriétaire AMD, jusqu’à afficher un modèle 3D en rotation. L’intervenant note avec humour : « a 3D model that rotates, not exactly very useful. But, it’s a start ».
Premiers succès : Counter-Strike 2 jouable
Le projet a ensuite amélioré la stabilité et la flexibilité, réduisant les valeurs codées en dur et ajoutant le support de fonctionnalités comme les sparse bindings, la tessellation et les task shaders. Le résultat marquant est l’exécution de Counter-Strike 2 via RADV sur Windows, en lançant le jeu avec l’argument -vulkan. L’intervenant tempère : « It does say an average FPS of 162, but that is one picture. FPS doesn’t tell the entire story », évoquant les stutters et les 1% lows.
Les défis techniques rencontrés
- Sensibilité du matériel récent : les tests sur du matériel Gen 11 ont échoué là où la Gen 10 fonctionnait, à cause de changements d’architecture. Le driver propriétaire semble faire beaucoup de vérifications et « dies » si les appels ne correspondent pas exactement à ses attentes.
- Compilation avec MSVC : Mesa est développé principalement avec GCC et Clang. MSVC ne gère pas les enums de la même manière, ce qui peut causer des comportements inattendus (limitation à 32 bits).
- Les appels D3D KMT escape : ces hooks spécifiques au vendeur peuvent être ignorés pour l’instant, car ils concernent surtout des fonctionnalités avancées comme le multi-GPU.
Le futur : besoin d’un soutien d’AMD
La question centrale pour une version production est l’interface avec le driver noyau propriétaire. L’intervenant résume : « we need one of a stable documented interface to the proprietary kernel mode driver, or a shim library that mediates communication with the KMD through the private data channel ». Sans cela, le projet restera fragile. Il ajoute : « Basically, they kinda need AMD to at least sign off on it, if not get involved at least a little bit on the Windows side of things as well ».
La présentation : un chantier encore long
Le support de la présentation (WSI) est encore limité à un chemin CPU lent. L’utilisation de swap chains DXGI est nécessaire pour améliorer les performances, mais cela implique d’importer des images depuis D3D12, avec encore plus de métadonnées opaques. L’objectif ultime serait le zero copy swap, qui pourrait tripler les performances pour les applications non limitées par le GPU, mais nécessiterait l’implication d’AMD et probablement de Microsoft.
CONCEPTS CLÉS
- RADV : driver Vulkan open-source pour GPU AMD, développé dans le projet Mesa.
- WDDM2 : Windows Display Driver Model version 2, interface standardisée entre les drivers graphiques et Windows 10+.
- UMD/KMD : User-Mode Driver / Kernel-Mode Driver, les deux composants d’un driver graphique Windows.
- D3D KMT : interface de communication entre le mode utilisateur et le mode noyau pour DirectX.
- DXVK : couche de traduction DirectX vers Vulkan, utilisée sous Linux et parfois sous Windows.
- WSI : Window System Integration, la partie du driver qui gère la présentation des images à l’écran.
- Zero copy swap : technique permettant d’afficher une image sans copie mémoire intermédiaire, très performante.
CONCLUSION
Le portage de RADV sur Windows est un pari technique ambitieux, rendu possible par le reverse engineering et la persévérance. Son intérêt dépasse le simple fait de fournir un driver open-source sur Windows : il mutualise les corrections de bugs, accélère le développement et renforce l’écosystème Mesa dans son ensemble. L’intervenant conclut avec optimisme : « People said you would never get Linux running on the Apple Silicon. People said you’d never be able to make open NVIDIA drivers. People said a lot of different things that are just not possible to do, and people make it happen ». Le chemin est encore long, mais les fondations sont posées, et le financement de Valve donne au projet une crédibilité et une pérennité que peu d’initiatives open-source peuvent revendiquer.