ACTU
NTSYNC : bye bye bye Windows
par CBL,
email @CBL_Factor
Une application (ou un jeu) Windows est composée d'un ou plusieurs processus qui font tourner un ou plusieurs threads. Au coeur du noyau de l'OS se trouvent ce que Microsoft appelle les primitives de synchronisation (ou objets de synchronisation), une série de classes, méthodes et variables qui permettent aux programmes d'utiliser plusieurs threads et de les manipuler afin de faire tourner plusieurs routines de code en parallèle. On parle de synchronisation car les threads en question communiquent entre eux et doivent souvent s'attendre.
Typiquement dans un jeu, les threads qui s'occupent de la logique (gameplay, AI...) doivent attendre que ceux en charge du rendu aient fini leur boulot et vice versa sous peine d'avoir une désynchronisation entre ce qui se passe et ce qui est affiché. Les threads en question sont assignés aux différents coeurs d'un processeur par le scheduler. Comme tous les OS, Linux dispose aussi d'un scheduler mais ne possède pas des mêmes primitives de synchronisation, ce qui est problématique pour exécuter les jeux Windows sous Linux via Wine.
Il y a eu plusieurs tentatives pour régler le problème. La première était d'avoir un processus appelé wineserver qui jouait le rôle d'orchestrateur mais nécessitait que les jeux communiquent avec des milliers de fois par seconde, ce qui engendrait un goulot d'étranglement. Puis Elizabeth Figura, codeuse chez CodeWeavers (qui co-développe Proton avec Valve), a inventé ESync qui utilisait eventfd, l'équivalent des primitives de synchronisation de Windows dans Linux. Ça fonctionnait mais c'était loin d'être parfait. FSync a ensuite été développé et fonctionnait encore mieux mais nécessitait de patcher le noyau Linux et donc d'être constamment sur une branche du code.
Depuis quelques années, Elizabeth Figura a bossé sur une vraie solution appelée NTSYNC. Il s'agit d'un pilote Linux au niveau du kernel qui réimplémente les primitives de synchronisation de Windows. Le driver en question a été ajouté au noyau Linux à partir de la 6.14 et est supporté par Wine depuis la version 11. SteamOS prend en charge NTSYNC depuis la 3.7.20 bêta et une fois que Proton passera à la version 11 de Wine, ça devrait donner un sacré coup de boost aux performances dans les jeux. Mais vous pouvez déjà tester sur d'autres distributions et/ou en utilisant Proton GE, la branche non-officielle de Proton qui est nettement plus à jour. Et les gains de performance sont limite débiles. Ça dépend beaucoup des jeux mais ça peut aller de 20 % à 200 %.
Ce n'est pas tout. Wine 11 améliore aussi le support des applis 32 bits. Sur Windows, celles-ci sont supportés via la couche WoW64. Jusqu'à présent sous Wine, les applications 32 bits nécessitaient des bibliothèques 32 bits. Wine 11 fait disparaître cette contrainte en implémentant WoW64. Non seulement cela simplifie les choses mais ça augmente la compatibilité avec les annciennes applis y compris celles codées en 16 bits ! Du reste, Wine 11 améliore le support de Wayland, le protocole d'affichage qui tente lentement mais sûrement de remplacer le vénérable X11. Wayland est utilisé par défaut dans la dernière version de KDE Plasma, l'environnement de bureau utilisé par pas mal de distribs dont SteamOS. Enfin, Wine 11.5 ajoute le support des Syscall User Dispatch, ce qui devrait améliorer la compatiblité avec les applications Windows qui parlent au noyau à très bas niveau comme les DRM et les protections anti-triche.
TROP LONG J'AI RIEN LU : les développeurs de Wine tentent de répliquer à la perfection le fonctionnement de Windows afin de maximiser la compatibilité et les performances des jeux sur Linux via Proton et sur macOS via CrossOver. On est passé en quelques années de la surprise de voir des jeux Windows tourner sur Linux à celle de constater qu'ils ne s'exécutent pas dessus. Pour Valve, l'intérêt est évidemment de booster l'attrait de ses bécanes mais encore une fois, vous n'avez pas besoin d'acheter leur matos pour en profiter. À titre personnel, ma petite expérience avec GLF OS se porte bien. Le PC boote automatiquement sur Steam Big Picture et je peux tout contrôler au pad y compris pour éteindre la bécane. Les rares fois où je dois utiliser un clavier, c'est quand il faut que je me connecte à un compte type Ubisoft Connect.
Typiquement dans un jeu, les threads qui s'occupent de la logique (gameplay, AI...) doivent attendre que ceux en charge du rendu aient fini leur boulot et vice versa sous peine d'avoir une désynchronisation entre ce qui se passe et ce qui est affiché. Les threads en question sont assignés aux différents coeurs d'un processeur par le scheduler. Comme tous les OS, Linux dispose aussi d'un scheduler mais ne possède pas des mêmes primitives de synchronisation, ce qui est problématique pour exécuter les jeux Windows sous Linux via Wine.
Il y a eu plusieurs tentatives pour régler le problème. La première était d'avoir un processus appelé wineserver qui jouait le rôle d'orchestrateur mais nécessitait que les jeux communiquent avec des milliers de fois par seconde, ce qui engendrait un goulot d'étranglement. Puis Elizabeth Figura, codeuse chez CodeWeavers (qui co-développe Proton avec Valve), a inventé ESync qui utilisait eventfd, l'équivalent des primitives de synchronisation de Windows dans Linux. Ça fonctionnait mais c'était loin d'être parfait. FSync a ensuite été développé et fonctionnait encore mieux mais nécessitait de patcher le noyau Linux et donc d'être constamment sur une branche du code.
Depuis quelques années, Elizabeth Figura a bossé sur une vraie solution appelée NTSYNC. Il s'agit d'un pilote Linux au niveau du kernel qui réimplémente les primitives de synchronisation de Windows. Le driver en question a été ajouté au noyau Linux à partir de la 6.14 et est supporté par Wine depuis la version 11. SteamOS prend en charge NTSYNC depuis la 3.7.20 bêta et une fois que Proton passera à la version 11 de Wine, ça devrait donner un sacré coup de boost aux performances dans les jeux. Mais vous pouvez déjà tester sur d'autres distributions et/ou en utilisant Proton GE, la branche non-officielle de Proton qui est nettement plus à jour. Et les gains de performance sont limite débiles. Ça dépend beaucoup des jeux mais ça peut aller de 20 % à 200 %.
Ce n'est pas tout. Wine 11 améliore aussi le support des applis 32 bits. Sur Windows, celles-ci sont supportés via la couche WoW64. Jusqu'à présent sous Wine, les applications 32 bits nécessitaient des bibliothèques 32 bits. Wine 11 fait disparaître cette contrainte en implémentant WoW64. Non seulement cela simplifie les choses mais ça augmente la compatibilité avec les annciennes applis y compris celles codées en 16 bits ! Du reste, Wine 11 améliore le support de Wayland, le protocole d'affichage qui tente lentement mais sûrement de remplacer le vénérable X11. Wayland est utilisé par défaut dans la dernière version de KDE Plasma, l'environnement de bureau utilisé par pas mal de distribs dont SteamOS. Enfin, Wine 11.5 ajoute le support des Syscall User Dispatch, ce qui devrait améliorer la compatiblité avec les applications Windows qui parlent au noyau à très bas niveau comme les DRM et les protections anti-triche.
TROP LONG J'AI RIEN LU : les développeurs de Wine tentent de répliquer à la perfection le fonctionnement de Windows afin de maximiser la compatibilité et les performances des jeux sur Linux via Proton et sur macOS via CrossOver. On est passé en quelques années de la surprise de voir des jeux Windows tourner sur Linux à celle de constater qu'ils ne s'exécutent pas dessus. Pour Valve, l'intérêt est évidemment de booster l'attrait de ses bécanes mais encore une fois, vous n'avez pas besoin d'acheter leur matos pour en profiter. À titre personnel, ma petite expérience avec GLF OS se porte bien. Le PC boote automatiquement sur Steam Big Picture et je peux tout contrôler au pad y compris pour éteindre la bécane. Les rares fois où je dois utiliser un clavier, c'est quand il faut que je me connecte à un compte type Ubisoft Connect.