Résumé : Wine 11 marque un tournant historique pour le jeu vidéo sur Linux grâce à l'intégration de NTSYNC dans le noyau mainline (6.14+), une solution native qui élimine les goulots d'étranglement des anciennes méthodes de synchronisation pour offrir une fluidité inédite aux titres multi-threadés. Cette version finalise également l'architecture WoW64, permettant de faire tourner des applications 32 bits (et même 16 bits) sans dépendances système complexes, tout en stabilisant considérablement le pilote Wayland et en modernisant le support de Vulkan 1.4. En unifiant ces avancées techniques majeures, Wine 11 ne se contente pas de corriger des bugs, il redéfinit la structure même de la compatibilité Windows sous Linux, apportant des gains de performance quasi immédiats à l'ensemble de l'écosystème, de SteamOS à Proton.
Le jeu sur Linux a beaucoup évolué. Lorsque Valve a lancé Proton en 2018, ce fut un tournant décisif : jouer sous Linux est passé de « techniquement possible si l'on accepte beaucoup de difficultés » à une situation plus ou moins fonctionnelle. Par la suite, plusieurs versions de Wine se sont succédé, chacune résolvant progressivement les problèmes de compatibilité et améliorant petit à petit les performances. Wine 10, Wine 9, et ainsi de suite ; chaque version apportait une série de corrections de bogues et de petites améliorations qui ont permis à l'écosystème de continuer à progresser.
Wine 11 est différent. Ce n'est pas simplement une nouvelle version annuelle avec quelques centaines de corrections de bogues et quelques ajustements de compatibilité. Ce sont des changements et des corrections de bogues en nombre considérable. Elle inclut également la prise en charge de NTSYNC, une fonctionnalité en développement depuis des années qui redéfinit la manière dont Wine gère l’une des opérations ayant le plus d’impact sur les performances dans les jeux modernes. En plus de cela, la refonte de l’architecture WoW64 est enfin terminée, le pilote Wayland a beaucoup évolué, et il y a une longue liste de petites améliorations qui, ensemble, font ressembler ce projet à un tout nouveau projet.
Je tiens à être clair : tous les jeux bénéficieront pas d'une différence radicale. Certains titres fonctionneront exactement comme avant. Mais pour les jeux qui bénéficieront de ces changements, les améliorations iront de notables à spectaculaires. Et comme Proton, SteamOS et tous les projets dérivés s'appuient sur Wine, ces gains profiteront à tout le monde.
Jusqu'à présent, tout n'était qu'une solution de fortune
Pour ceux qui ont déjà passé du temps à régler les paramètres de Wine ou de Proton, les termes « esync » et « fsync » ne vous sont sans doute pas inconnus. Peut-être les avez-vous activés dans Lutris, ou les avez-vous remarqués dans les options de lancement de Proton, sans pour autant comprendre pleinement leur fonction. Pour comprendre l'importance de NTSYNC, il faut d'abord appréhender le problème que ces solutions cherchaient toutes à résoudre.
Les jeux Windows, en particulier les plus récents, sont fortement multithreadés. Votre processeur n'exécute pas une seule tâche à la fois ; il jongle plutôt entre le rendu, les calculs physiques, le streaming des ressources, le traitement audio, les routines d'IA et bien plus encore, le tout en parallèle sur plusieurs threads. Ces threads doivent se coordonner entre eux en permanence. Un thread peut devoir attendre qu'un autre ait fini de charger une texture avant de pouvoir rendre une image. Un autre peut avoir besoin d'un accès exclusif à une ressource partagée pour éviter que deux threads n'essaient de la modifier simultanément.
Windows gère cette coordination via ce qu'on appelle des primitives de synchronisation NT... mutex, sémaphores, événements, etc. Elles sont profondément intégrées au noyau Windows, et les jeux en dépendent fortement. Le problème est que Linux ne dispose pas d'équivalents natifs qui se comportent exactement de la même manière. Wine a toujours dû émuler ces mécanismes de synchronisation, et la manière dont il le faisait n'était, pour faire simple, pas idéale.
L'approche initiale consistait à effectuer un appel RPC aller-retour vers un processus « noyau » dédié, appelé wineserver, à chaque fois qu'un jeu devait se synchroniser entre les threads. Pour un jeu effectuant des milliers de ces appels par seconde, cela représentait une surcharge qui s'accumulait rapidement et finissait par constituer un goulot d'étranglement. Ce goulot d'étranglement se traduisait par de légers saccades d'images, un rythme d'affichage irrégulier et des jeux qui semblaient ne pas fonctionner correctement, même lorsque les chiffres bruts de FPS semblaient corrects.
Esync a été la première tentative de solution. Développé par Elizabeth Figura chez CodeWeavers, ce système utilisait l'appel système eventfd de Linux pour gérer la synchronisation sans passer par wineserver. Cela fonctionnait et aidait, mais présentait des particularités. Certaines distributions rencontraient des problèmes liés aux limites des descripteurs de fichiers, car chaque objet de synchronisation nécessitait son propre descripteur, et les jeux qui en ouvraient beaucoup pouvaient atteindre très rapidement le plafond du système.
Fsync a suivi, utilisant les futexes de Linux à des fins de performances accrues. Fsync était plus rapide qu’esync dans la plupart des cas, mais il nécessitait des correctifs du noyau hors arborescence qui n’ont jamais été intégrés au noyau Linux principal. Cela signifiait qu’il fallait un noyau personnalisé ou corrigé pour l’utiliser, ce qui convient aux utilisateurs passionnés exécutant CachyOS ou Proton-GE, mais pas vraiment accessible aux utilisateurs lambda sur Ubuntu ou Fedora.
Le problème avec esync et fsync, c'est qu'il s'agissait de solutions de remplacement. Des solutions astucieuses, certes, mais des solutions de remplacement quand même. Elles reproduisaient approximativement le comportement de synchronisation NT à l'aide de primitives Linux qui n'étaient pas conçues pour cela, et certaines situations particulières ne pouvaient tout simplement pas être gérées correctement. Des opérations telles que NtPulseEvent() et le mode « wait-for-all » dans NtWaitForMultipleObjects() exigeaient un contrôle direct sur les files d'attente sous-jacentes d'une manière que les implémentations en espace utilisateur ne peuvent tout simplement pas fournir de manière fiable.
NTSYNC remanie tout
NTSYNC adopte une approche totalement différente. Au lieu d'essayer d'intégrer le comportement de synchronisation de Windows dans les primitives Linux existantes, celui-ci ajoute un nouveau pilote de noyau qui reproduit directement l'API des objets de synchronisation de Windows NT. Il met à disposition un périphérique /dev/ntsync avec lequel Wine peut communiquer, et c'est le noyau lui-même qui gère la coordination. Fini les allers-retours vers wineserver, fini les approximations, et la synchronisation se fait dans le noyau, là où il faut. Et il dispose d'une gestion de file d'attente, d'une sémantique d'événements et d'opérations atomiques correctes.
Pour couronner le tout, NTSYNC a été développé par la même personne qui a créé esync et fsync à l’origine. Elizabeth Figura travaille sur ce problème depuis des années, effectuant de multiples itérations de correctifs du noyau, présentant ses travaux à la Linux Plumbers Conference en 2023, et faisant passer plusieurs versions de l’ensemble de correctifs avant qu’il ne soit finalement intégré au noyau Linux principal avec la version 6.14.
Les chiffres sont époustouflants. Dans les tests de performance des développeurs, Dirt 3 est passé de 110,6 images par seconde (ips) à 860,7 ips, soit une amélioration impressionnante de 678 %. Resident Evil 2 a bondi de 26 ips à 77 ips. Call of Juarez est passé de 99,8 ips à 224,1 ips. Tiny Tina's Wonderlands a vu ses performances passer de 130 FPS à 360 FPS. De plus, Call of Duty: Black Ops I est désormais jouable sous Linux. Ces tests comparent Wine NTSYNC à la version standard de Wine, ce qui signifie qu'il n'y a ni fsync ni esync. Les joueurs qui utilisent fsync ne constateront pas une telle amélioration des performances dans la plupart des jeux.
Les jeux qui tirent le plus profit de NTSYNC sont ceux qui rencontraient auparavant des difficultés, notamment les titres impliquant des charges de travail multithread importantes où la surcharge liée à la synchronisation constituait un véritable goulot d'étranglement. Pour ces jeux, la différence est flagrante. Et contrairement à fsync, NTSYNC est intégré au noyau principal, ce qui signifie qu'aucun correctif personnalisé ni module hors arborescence n'est nécessaire pour qu'il fonctionne. Toute distribution équipée du noyau 6.14 ou d'une version ultérieure, ce qui inclut à l'heure actuelle Fedora 42, Ubuntu 25.04 et les versions plus récentes, le prendra en charge. Valve a déjà ajouté le pilote NTSYNC au noyau de SteamOS 3.7.20 beta, le module étant chargé par défaut, et un fork non officiel de Proton, Proton GE, l'a déjà activé. Lorsque la version officielle de Proton de Valve sera basée sur Wine 11, tous les propriétaires de Steam Deck en bénéficieront gratuitement.
Tout cela fait de NTSYNC une avancée majeure, car il ne s'agit pas simplement d'un correctif de performances ordinaire. Il s'agit en réalité de quelque chose de bien plus important : c'est la première fois que la synchronisation de Wine est correcte au niveau du noyau, implémentée dans le noyau Linux principal et accessible à tous sans avoir à faire des manipulations complexes.
WoW64 est enfin terminé
Si NTSYNC fait l'actualité, c'est l'achèvement de l'architecture WoW64 de Wine qui constituera le changement susceptible d'améliorer discrètement notre quotidien. Sous Windows, WoW64 (Windows 32 bits sur Windows 64 bits) est le sous-système qui permet aux applications 32 bits de fonctionner sur des systèmes 64 bits. Wine travaille depuis des années sur sa propre implémentation de cette fonctionnalité, et Wine 11 marque officiellement son achèvement.
Concrètement, cela signifie que vous n'avez plus besoin d'installer des bibliothèques système 32 bits sur votre système Linux 64 bits pour exécuter des applications Windows 32 bits. Wine gère la conversion en interne, à l'aide d'un binaire unique et unifié qui détecte automatiquement s'il s'agit d'un exécutable 32 bits ou 64 bits. L'époque où il fallait installer des paquets multilib, configurer ia32-libs ou se battre avec les dépendances 32 bits sur votre distribution 64 bits est heureusement révolue.
Cela peut sembler être une amélioration mineure de l'expérience utilisateur, mais il s'agit en réalité d'un travail de développement considérable. Le mode WoW64 gère désormais les mappages mémoire OpenGL, le pass-through SCSI et même la prise en charge des applications 16 bits. Oui, 16 bits ! Si vous possédez d'anciens logiciels Windows datant des années 90 que vous devez exécuter pour une raison quelconque, Wine 11 est là pour vous.
Pour les jeux en particulier, cela a son importance car un nombre surprenant de jeux, surtout les plus anciens, sont des exécutables 32 bits. Auparavant, pour les faire fonctionner, il fallait souvent se battre avec la configuration multilib de sa distribution, dont la qualité et la facilité d'utilisation variaient selon qu'on utilisait Ubuntu, Arch, Fedora ou tout autre système. Désormais, Wine s'en charge pour vous.
Le reste de Wine 11 n'est pas qu'un simple complément
On pourrait facilement laisser NTSYNC et WoW64 monopoliser l'attention, mais Wine 11 regorge d'autres nouveautés qui méritent d'être mentionnées.
Le pilote Wayland a fait d'énormes progrès. La prise en charge du presse-papiers fonctionne désormais dans les deux sens entre Wine et les applications Wayland natives, ce qui fait partie de ces choses auxquelles on ne pense pas tant qu'elles ne fonctionnent pas et qu'elles ne nous rendent pas fous. Le glisser-déposer depuis les applications Wayland vers les fenêtres Wine est pris en charge. Les changements de mode d'affichage sont désormais émulés via la mise à l'échelle du compositeur, ce qui signifie que les anciens jeux qui tentent de passer à des résolutions inférieures, comme 640x480, se comportent correctement au lieu de vous laisser avec un bureau déformé. Si vous avez hésité à passer de X11 à Wayland en raison de problèmes de compatibilité avec Wine, Wine 11 élimine bon nombre de ces obstacles.
Côté graphisme, EGL est désormais le backend par défaut pour le rendu OpenGL sur X11, remplaçant l'ancien chemin GLX. La prise en charge de Vulkan a été mise à niveau vers la version 1.4 de l'API, et il existe désormais une prise en charge initiale du décodage H.264 accéléré par le matériel via les API vidéo Direct3D 11 utilisant Vulkan Video. Ce dernier point est particulièrement intéressant pour les jeux et les applications qui utilisent la lecture vidéo pour des éléments tels que les cinématiques ou le streaming en cours de jeu.
La prise en charge du retour de force a été améliorée pour les volants de course et les manettes de vol, ce qui est une excellente nouvelle si vous utilisez un simulateur sous Linux. De plus, le Bluetooth a reçu un nouveau pilote avec des services BLE et une prise en charge correcte de l'appairage, la gestion des soundfonts MIDI a été améliorée pour la musique des jeux anciens, et il y a quelques ajouts mineurs comme la prise en charge de la compression Zip64, la prise en charge d'Unicode 17.0.0, la numérisation TWAIN 2.0 pour les applications 64 bits et la fonctionnalité de ping IPv6.
La gestion des priorités des threads a été améliorée sous Linux et macOS, ce qui contribue aux performances des applications multithread au-delà des seuls gains apportés par NTSYNC. Les appareils ARM64 peuvent désormais simuler des tailles de page 4K sur des systèmes dotés de pages natives plus grandes, ce qui ouvre la voie à Wine sur le matériel Arm. Et avec l'apparition chaque année de nouveaux appareils Linux basés sur Arm, cela revêt plus d'importance qu'auparavant.
De plus, de nombreuses corrections de bogues ont été apportées. Des jeux tels que Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI et Battle.net ont tous bénéficié de corrections de compatibilité spécifiques, qui s’ajoutent aux améliorations générales apportées à l’ensemble du système et qui amélioreront les performances et la compatibilité d’un nombre nettement plus important de titres.
Wine 11 est une version majeure, et ce n'est pas seulement grâce à NTSYNC. Certes, NTSYNC aurait suffi à lui seul à justifier qu'on s'y intéresse, mais combiné à l'achèvement de WoW64, aux améliorations de Wayland et à la multitude de correctifs, c'est la version la plus importante de Wine depuis que Proton a rendu le jeu sur Linux viable. Tout ce qui repose sur Wine, de Proton à Lutris en passant par Bottles, s'en trouve amélioré. Si vous jouez ne serait-ce qu'un peu à des jeux sur Linux, Wine 11 vaut vraiment la peine d'être essayé.
traduction de : https://www.xda-developers.com/wine-11-rewrites-linux-runs-windows-games-speed-gains/
Enregistrer un commentaire
Les commentaires sont validés manuellement avant publication. Il est normal que ceux-ci n'apparaissent pas immédiatement.