Linux affiche de meilleurs FPS que Windows sur certains jeux Windows. Pas sur des titres Linux natifs, pas sur des indés pixelisés — sur des AAA récents, tournant via Proton, sur le même matériel. L’ironie est si dense qu’on pourrait en faire un mème. Pourtant, c’est exactement ce que mesurent les benchmarks depuis le début de l’année 2025, et l’explication est moins surprenante qu’il n’y paraît une fois qu’on gratte un peu.
La raison ? Linux a intégré des primitives du noyau Windows NT directement dans son propre noyau. Pas un hack, pas un workaround de plus dans la longue liste des bidouilles Wine — une implémentation conforme, propre, fusionnée dans le noyau Linux 6.14 en mars 2025 sous le nom de ntsync. C’est le genre de nouvelle qui passe sous les radars grand public mais qui fait vibrer les forums de bas niveau depuis des mois.
Pour comprendre pourquoi c’est significatif, il faut comprendre où était le vrai goulot d’étranglement dans Proton — et il n’était pas là où la plupart des gens le cherchaient.
TL;DR — Le module ntsync, fusionné dans Linux 6.14, implémente les objets de synchronisation Windows NT (mutex, sémaphores, events) directement dans le noyau Linux. Proton peut désormais les utiliser nativement au lieu de passer par le Wineserver, un processus Unix mono-threadé qui était un goulot massif. Sur les jeux CPU-bound, les gains atteignent 10 à 40% selon les titres.
Wine et Proton : une couche de compatibilité, pas un émulateur
Le malentendu le plus répandu sur Wine, c’est de le qualifier d’émulateur. Wine n’émule rien. Le binaire .exe s’exécute directement sur le CPU x86, sans traduction d’instructions. Ce que Wine fait, c’est implémenter les APIs Windows — Win32, NTDLL, DirectX — en les redirigeant vers leurs équivalents Linux ou Vulkan. C’est de la compatibilité binaire, pas de l’émulation.
Proton, la solution de Valve intégrée à Steam, est essentiellement Wine augmenté : DXVK traduit DirectX 11 vers Vulkan, VKD3D-Proton s’occupe de DirectX 12, et une ribambelle de patchs maison viennent compléter le tableau. Pour les appels graphiques, ça fonctionne remarquablement bien depuis des années. Le problème vient d’une autre catégorie d’appels systèmes, nettement moins glamour : la synchronisation entre threads.
Un jeu moderne n’est pas une application mono-thread. Les moteurs physiques, les systèmes d’IA, le streaming d’assets, le rendu — tout ça tourne en parallèle. Ces threads doivent se coordonner en permanence, et Windows fournit pour ça un ensemble d’objets noyau : mutexes, sémaphores, événements (event objects), timers. Des milliers d’appels par seconde dans un AAA typique.
Le Wineserver : le goulot que personne ne voyait venir
Sur Windows, un appel de synchronisation NT est trivial : un syscall direct, quelques microsecondes, c’est plié. Sur Linux via Wine, c’était un chemin bien plus tortueux. Ces appels transitaient par le Wineserver — un processus Unix unique, mono-threadé, qui gère l’état global d’une session Wine. Chaque opération de synchronisation devenait un aller-retour IPC vers ce processus. En termes de latence et de contention, sur un jeu qui en déclenche des milliers par seconde, c’est dévastateur.
Des palliatifs existaient. esync puis fsync mappaient les objets NT vers des file descriptors Unix (via eventfd notamment), permettant de court-circuiter le Wineserver pour les cas les plus courants. Ces hacks amélioraient nettement la situation — Proton les activait par défaut depuis longtemps — mais ils restaient des approximations avec leurs propres limites sémantiques. Certains comportements des event objects NT, notamment, ne se mappaient pas proprement sur les primitives Unix disponibles.
Le problème de fond : il n’existait pas dans Linux de primitives qui correspondent exactement à la sémantique NT. Jusqu’à ntsync.
DÉCOUVREZ NOS RÉALISATIONS
FinDaWine
Application web PWA de recherche de vins avec scan de code-barres et gestion du catalogue en back-office.
Voir le projet →ntsync : Linux 6.14 absorbe les entrailles de Windows NT
Le module ntsync implémente les objets de synchronisation NT directement dans le noyau Linux, exposés via le device /dev/ntsync. Mutex NT, sémaphores NT, événements NT — avec la sémantique exacte définie par la spec Windows NT, pas une approximation Unix. Wine et Proton peuvent désormais créer et manipuler ces objets nativement via des ioctls, sans aucun transit par le Wineserver pour les opérations critiques.
// Avant ntsync : NtWaitForSingleObject → IPC vers Wineserver → latence
// Avec ntsync : appel noyau direct via /dev/ntsync
ioctl(ntsync_fd, NTSYNC_IOC_WAIT_FOR_SINGLE, &args);Le travail a été porté principalement par Elizabeth Figura de CodeWeavers (l’entreprise derrière Wine commercial). La discussion autour de son inclusion dans le kernel a duré des années — les mainteneurs rechignaient à intégrer du code lié à Windows. L’argument qui a finalement convaincu : l’implémentation est propre, les primitives sont utiles indépendamment de Wine, et les objets exposés ont une cohérence interne qui dépasse le simple cas d’usage Gaming.
Linux n’a pas convaincu les développeurs de porter leurs jeux. Il est devenu suffisamment bon pour les faire tourner sans eux — et parfois mieux.
Les gains en pratique — des chiffres concrets
Les benchmarks publiés depuis l’activation de ntsync dans Wine et Proton sont éloquents sur les jeux CPU-bound. Elden Ring, Hogwarts Legacy, Cyberpunk 2077 affichent des gains de 10 à 25% selon les configurations matérielles. Sur certains titres qui saturaient littéralement le Wineserver de requêtes de synchronisation, les améliorations dépassent 40% en frametime moyen.
Sur les jeux très multi-threadés (moteur physique actif, IA intensive, streaming d’assets), ntsync peut améliorer le frametime de 15 à 40%. Sur les jeux GPU-bound où le CPU n’est pas le facteur limitant, l’impact est en revanche négligeable.
Ce n’est pas universel, et c’est important de le nuancer. Un jeu GPU-bound — où le CPU attend simplement que le GPU finisse — ne verra aucune différence mesurable. Mais pour tout ce qui sollicite intensément la synchronisation inter-threads, le gain est réel et reproductible. C’est de l’ingénierie de bas niveau qui paie là où elle devait payer.
Ce gain s’additionne à tout ce qui a été fait côté Vulkan. DXVK et VKD3D-Proton ont atteint une maturité remarquable, les drivers AMD et NVIDIA Linux ont comblé une bonne partie de leur retard historique, et le Steam Deck a forcé Valve à rendre Proton solide comme un roc. ntsync n’est pas un miracle isolé — c’est la dernière pièce d’un puzzle assemblé patiemment depuis 2018.
Linux devient-il un peu Windows ?
La question fait tiquer les puristes, et elle mérite d’être posée franchement. Intégrer des primitives de synchronisation NT dans le noyau Linux, c’est faire entrer la logique Windows dans un OS qui s’est construit en opposition à Microsoft. Pourtant, ce n’est pas sans précédent : futex existe depuis Linux 2.6 et fut en partie motivé par des besoins de portabilité ; le support Android a introduit binder et ashmem dans le kernel. Linux absorbe ce dont l’écosystème a besoin. C’est probablement sa vraie force.
Il y a un effet de bord intéressant pour quiconque développe une application sur mesure ciblant plusieurs OS. Si les primitives NT ont une correspondance directe dans Linux, le portage de code Windows vers Linux se simplifie en théorie. Pas l’objectif affiché de ntsync, mais un bénéfice collatéral appréciable pour les équipes qui maintiennent du code multi-plateforme.
Microsoft a longtemps utilisé ses APIs propriétaires comme fossé économique. Ce fossé se comble — non par Microsoft — mais par des contributeurs open source qui implémentent la spec NT dans Linux avec une rigueur exemplaire. La spec a toujours été publique. Il suffisait de quelqu’un pour faire le travail.
Côté infrastructure, les gains de synchronisation inter-threads dans le noyau ont aussi des répercussions indirectes sur les workloads serveur. Si tu t’interroges sur les performances de ton hébergement Linux, un noyau qui gère mieux la contention entre threads, c’est potentiellement une meilleure efficacité sur des services hautement parallèles — bases de données, workers asynchrones, proxies.
WESTCODE BY LEB
Studio web en Mayenne — On crée des outils numériques qui transforment
Ce que ça dit sur le futur du gaming Linux
En 2018, quand Valve annonçait Proton, l’objectif semblait ambitieux à l’extrême : rendre jouable le catalogue Steam entier sous Linux. Aujourd’hui, ProtonDB recense plus de 80% des 100 jeux les plus joués sur Steam comme fonctionnels ou mieux sur Linux. La progression est constante, méthodique, invisible pour la plupart des utilisateurs — et c’est exactement ce qu’il fallait.
ntsync est emblématique d’une méthode : identifier le vrai bottleneck (pas le visible, le vrai), le corriger à la bonne couche d’abstraction, itérer. Pas de communication tapageuse, pas de version 2.0 avec keynote — juste du code bas niveau qui règle le problème à la source et se retrouve dans un git log que 99% des gamers ne liront jamais.
Mon pari sur la suite
La trajectoire est claire, et elle ne ralentit pas. Chaque trimestre, la liste des raisons de rester sur Windows pour jouer raccourcit. Les anti-cheat EAC et BattlEye supportent Linux depuis un moment, le parc Steam Deck installe Linux dans les mains de millions de joueurs sans qu’ils s’en rendent compte, et maintenant ntsync ferme le dernier grand écart de performance côté synchronisation.
Ça ne sera pas une bascule brutale. Le gaming Windows a une inertie considérable — habitudes, exclusivités, ecosystème Xbox. Mais la direction est actée. Dans deux ou trois ans, « je reste sur Windows pour les jeux » sera une raison aussi solide que « je reste sur Windows pour les drivers Wi-Fi » l’était en 2010. Ce n’est plus une question de si, c’est une question de quand.
Et quelque part, c’est une belle victoire pour l’open source : avoir retourné les armes propriétaires de Microsoft contre ses propres produits, non par hostilité idéologique, mais par pragmatisme d’ingénieur. C’est la meilleure sorte de victoire.
