Triton est un nouveau pilote DirectX 11 pour les invités Windows sous QEMU, écrit par osy, l'auteur d'UTM, et repris par Phoronix le 8 août. L'intérêt n'est pas que Direct3D 11 fonctionne dans une machine virtuelle, c'est possible depuis un moment. C'est l'endroit où la traduction se produit. Triton implémente la Device Driver Interface de Windows, la couche à laquelle la pile graphique de Microsoft s'adresse, au lieu de remplacer les DLL Direct3D à côté de chaque application. Cette seule décision change ce qui s'installe proprement et ce que l'invité voit comme carte graphique. Nous avons lu l'architecture et les notes de l'auteur.
The short answer
Triton est un pilote DirectX 11 pour les invités Windows sous QEMU, écrit par osy, le développeur derrière UTM. Au lieu de substituer les DLL Direct3D dans chaque application, il implémente la Device Driver Interface de Windows : l'invité conserve les exécutifs Direct3D et DXGI de Microsoft et gagne simplement une carte graphique qui leur répond. Les commandes transitent par VirtIO via le protocole Neptune jusqu'à virglrenderer, qui aboutit sur DXVK et Vulkan sous Linux ou sur DXMT et Metal sous macOS. Claude Opus 5 et Claude Fable 5 ont aidé au développement. C'est expérimental et cela demande de compiler soi-même.
Qui a déjà essayé de donner une vraie accélération graphique à une machine virtuelle Windows connaît le marché habituel. Vous déposez une couche de traduction dans l'invité, vous la pointez vers le GPU de l'hôte, et vous acceptez qu'une partie de vos logiciels refuse de démarrer parce que la DLL posée à côté n'est pas celle que Microsoft a livrée. Cela marche assez souvent pour valoir le coup et échoue assez souvent pour agacer. Triton attaque le même problème par une autre entrée.
La couture est descendue d'un étage
La pile Direct3D de Windows offre plusieurs points d'interception. Le plus évident est l'API : les applications appellent d3d11.dll et dxgi.dll, vous écrivez donc vos propres versions de ces bibliothèques et vous traduisez les appels vers quelque chose que l'hôte comprend, en général Vulkan. L'approche a fait ses preuves et c'est ainsi que fonctionne l'essentiel de la traduction graphique sous Linux aujourd'hui.
Triton intercepte en dessous, au niveau de la Device Driver Interface. La DDI est le contrat que Windows lui-même emploie pour parler à un pilote d'affichage, et l'implémenter signifie que l'invité garde les vrais exécutifs Direct3D et DXGI de Microsoft. Les applications continuent d'appeler les mêmes composants du système que sur du matériel physique, et la seule chose qui a changé est que la carte en dessous est virtuelle. Structurellement, Triton a la forme de ce que livre un constructeur : un pilote d'affichage en mode utilisateur associé à un pilote en mode noyau pour la carte virtuelle.
Cela a une conséquence pratique qui mérite d'être posée à part. Rien n'atterrit dans le dossier de l'application. Les systèmes de protection et d'intégrité des jeux surveillent de près les modules chargés par un processus, et une d3d11.dll substituée est précisément le motif qu'ils existent pour signaler, d'où des refus qui n'ont aucun rapport avec la justesse du rendu. Un pilote installé au niveau système ne déclenche pas ce signal, puisque vue du processus la liste des modules est parfaitement ordinaire.
Ce qui arrive après la sortie de Windows
Le transport s'appelle Neptune, le protocole qui fait sortir le travail Direct3D de l'invité par VirtIO. QEMU le reçoit et le confie à virglrenderer, la bibliothèque côté hôte qui rend ce service aux invités Linux depuis des années, et virglrenderer s'adresse au moteur graphique dont l'hôte dispose réellement.
C'est en bout de chaîne que se logent les différences d'hôte. Sous Linux, cela passe par DXVK et Vulkan. Sous macOS, par DXMT, qui projette Direct3D 11 sur Apple Metal, et le D3DMetal d'Apple est disponible comme chemin plus direct, à titre expérimental. Le côté invité s'en moque. C'est la propriété de conception qui rend le projet digne d'attention : le pilote Windows est écrit une fois et l'hôte substitue la traduction qu'il sait faire, au lieu que chaque invité doive savoir sur quoi il tourne.
Deux décisions plus petites suivent le même instinct. Triton conserve plus longtemps le code de nuanceur DirectX d'origine dans le pipeline au lieu de le convertir tôt, ce qui laisse davantage d'information à la compilation finale. Et sur Apple Silicon, il s'appuie sur la mémoire unifiée pour éviter de recopier des textures que les deux côtés peuvent déjà atteindre.
Où se place l'aide de l'IA
La ligne de crédit est assez inhabituelle pour être relevée : l'auteur indique que Claude Opus 5 et Claude Fable 5 ont aidé à construire le pilote. Un pilote d'affichage Windows est une cible réellement ingrate pour un développeur seul. La DDI est peu documentée, les implémentations de référence qui fonctionnent sont propriétaires, et le coût d'une hypothèse fausse est un écran d'arrêt sur une machine qu'il faut ensuite redémarrer, pas une exception que l'on peut lire.
Ce n'est pas une raison de traiter le résultat autrement, et le projet ne le demande pas. Le code est public sur github.com/osy/kvm-guest-drivers-windows, un pilote satisfait l'exécutif graphique ou plante d'une manière que personne ne peut manquer, et l'évaluation honnête de la maturité vient de l'auteur plutôt que d'un relecteur : plantages, défauts visuels et problèmes de compatibilité font encore partie de l'expérience, et ce n'est pas prêt pour l'ordinateur de travail dont vous dépendez tous les jours.
Ce que cela change pour qui exploite des VM Windows
Pas grand-chose cette semaine, et beaucoup sur l'année qui vient si l'ensemble tient. Aujourd'hui, cela veut dire compiler les composants soi-même, des deux côtés, sans chemin d'installation prêt à l'emploi. Ce qui fonctionne couvre le bureau Windows, les effets de composition, la sortie vidéo et les applications bâties sur Direct3D 11, les premières démonstrations montrant Windows 11 pour ARM exécutant des jeux et des tests DirectX 11 sous QEMU. Aucun chiffre de performance n'a été publié, personne ne devrait donc annoncer de gains.
La raison de suivre le projet est architecturale plutôt qu'immédiate. Un pilote côté invité qui implémente la vraie interface, avec un hôte libre de traduire comme il peut, c'est la forme qui finit par devenir quelque chose qu'une distribution peut livrer. Les couches de traduction par application n'y arrivent jamais tout à fait, parce que la surface de maintenance est l'ensemble des applications au lieu d'un pilote unique. Si Triton se stabilise, la question intéressante cesse d'être si Direct3D fonctionne dans une machine virtuelle pour devenir à quel point il s'approche du matériel installé dans le même boîtier.
Sources et pour aller plus loin
- AI Helped Create A DirectX 11 Driver For QEMU VMs, Phoronix, 8 août 2026
- Introducing Triton: DirectX 11 driver for QEMU, blog UTM
- osy/kvm-guest-drivers-windows sur GitHub
- Introducing Neptune: Direct3D virtualization for QEMU, blog UTM
- UTM Triton brings DirectX 11 graphics to QEMU on Apple, GenerationAmiga
- Triton: DirectX 11 driver for QEMU, discussion Hacker News
Questions fréquentes
Qu'apporte réellement le fait d'implémenter la DDI plutôt que l'API DirectX ?
Cela déplace la couture d'un étage vers le bas, et presque tout le reste en découle. Quand vous traduisez au niveau de l'API, vous fournissez vos propres d3d11.dll et dxgi.dll, et l'application se lie à votre code au lieu de celui de Microsoft. C'est l'approche courante, elle fonctionne bien, mais elle impose de livrer des binaires posés à côté de l'exécutable et exige que votre implémentation remplace fidèlement chaque recoin d'une surface d'API que Microsoft étend depuis 2009. La Device Driver Interface est le contrat du dessous : Windows conserve ses propres exécutifs Direct3D et DXGI, et le pilote n'a plus qu'à répondre aux appels que ces exécutifs émettent. Les applications n'y voient rien, puisque de leur point de vue elles parlent à Windows, exactement comme sur du matériel réel. Triton se présente comme un pilote d'affichage en mode utilisateur accompagné d'un pilote en mode noyau pour la carte virtuelle, soit la forme exacte d'un pilote de constructeur.
Comment les commandes sortent-elles de l'invité pour atteindre le GPU de l'hôte ?
Par le protocole Neptune au-dessus de VirtIO. Le pilote en mode utilisateur, dans Windows, empaquette le travail Direct3D et le remet au composant noyau, qui le pousse à travers le transport VirtIO jusqu'à QEMU. QEMU passe le flux à virglrenderer, la bibliothèque côté hôte qui rend ce service aux invités Linux depuis des années, et virglrenderer pilote le moteur graphique de l'hôte, quel qu'il soit. Sur un hôte Linux, la fin de la chaîne passe par DXVK et Vulkan. Sur macOS, elle passe par DXMT, qui projette Direct3D 11 sur Apple Metal, avec le D3DMetal d'Apple disponible comme raccourci expérimental. La propriété intéressante, c'est que le côté invité ignore tout de l'hôte : le même pilote Windows fonctionne quelle que soit la couche de traduction disponible, parce que la traduction a quitté la machine virtuelle.
Pourquoi est-ce si important de ne rien poser dans le dossier de l'application ?
Parce que beaucoup de logiciels se méfient des binaires inattendus apparaissant à côté de leur exécutable. Les systèmes de protection et d'intégrité des jeux inspectent les modules chargés par un processus, et une d3d11.dll de remplacement correspond très exactement au motif qu'ils sont conçus à repérer, si bien que l'approche par l'API se heurte à des refus qui n'ont rien à voir avec la justesse du rendu. Triton contourne toute la catégorie en n'étant pas présent de cette manière dans l'espace d'adressage de l'application. Il s'installe comme un pilote système, le processus charge l'exécutif de Microsoft, et la liste des modules ressemble à ce que Windows attend. Il y a un second bénéfice, plus discret, pour qui administre des machines virtuelles : vous installez une fois, au niveau système, au lieu d'entretenir des copies par application qui vieillissent chacune de leur côté.
Quel rôle ont joué les modèles d'IA, et cela change-t-il la lecture du code ?
L'auteur crédite Claude Opus 5 et Claude Fable 5 d'une aide au développement du pilote, ce qui mérite d'être noté parce qu'un pilote d'affichage Windows est un domaine où la documentation est maigre, où les implémentations de référence sont propriétaires, et où la boucle de retour après une erreur est un écran d'arrêt plutôt qu'une pile d'appels lisible. C'est un endroit réellement difficile pour avancer seul. Cela ne change pas la façon d'évaluer le résultat. Le code est public dans le dépôt kvm-guest-drivers-windows, il satisfait ou non les attentes de l'exécutif graphique, et un pilote graphique signale ses propres défauts assez bruyamment. Lisez-le comme n'importe quel pilote de jeunesse écrit par un auteur unique : prometteur, à tester, pas encore à mettre sous une charge à laquelle vous tenez.
Est-ce utilisable aujourd'hui, et que faut-il pour l'essayer ?
C'est expérimental et l'auteur le dit sans détour, en décrivant les plantages, les défauts visuels et les problèmes de compatibilité comme faisant encore partie de l'expérience, et en avertissant que ce n'est pas prêt pour l'ordinateur de travail dont vous dépendez tous les jours. L'essayer signifie compiler soi-même plutôt qu'installer un paquet : les pilotes invités se trouvent sur github.com/osy/kvm-guest-drivers-windows, et il vous faut côté hôte une pile QEMU et virglrenderer assez récente pour parler le protocole, ce qui revient aujourd'hui à construire les composants à la main. Ce qui fonctionne, quand cela fonctionne, couvre le bureau Windows, les effets de composition, la sortie vidéo et les applications qui reposent sur Direct3D 11, les premières démonstrations montrant Windows 11 pour ARM exécutant des jeux et des tests DirectX 11 sous QEMU. Aucun chiffre de débit n'a été publié, la performance reste donc une question ouverte.