Linux Gaming On XWayland Was A Mistake
La vidéo démontre, via des mesures précises, que le gaming sur Wayland n’est pas intrinsèquement plus lent que sur X11, mais que le véritable problème de latence provient de l’utilisation de XWayland, et que les optimisations comme VRR et DXVK low-latency réduisent encore l’éc...
SYNTHÈSE STRUCTURÉE
Méthodologie de test rigoureuse
L’intervenant a utilisé un setup contrôlé : un système KDE (choisi car supporté par Valve et le Steam Deck), un CPU 5800X3D, une GPU 4070 Super, et un écran 500 Hz pour maximiser la visibilité des variations. Le jeu Diabotical a été exécuté en local, sans bots, avec des paramètres fixes (minimum settings, résolution native, pas de FSR). Un capteur lumineux a mesuré la latence d’entrée sur des sessions de deux minutes par configuration. « On a le jeu, le bureau, le launcher, et on ferme tout le reste » – une approche minimaliste pour isoler les variables.
Résultats : X11 domine, mais l’écart est infime
Le graphique montre que X11 avec VRR et DXVK low-latency est le plus rapide, suivi de près par Wayland avec les mêmes optimisations. La différence entre le meilleur cas (X11 optimisé) et le pire (Wayland sans optimisation) est de seulement 0,72 milliseconde. Pour contextualiser : « Si on a un écran à 60 Hz, une frame dure 16,67 ms. On parle de 0,72 ms. » Même à 240 Hz (4,17 ms par frame), cet écart reste imperceptible pour la majorité des joueurs.
XWayland : le vrai coupable
Le constat le plus frappant est que XWayland (l’émulation X11 sur Wayland) ajoute une latence bien plus élevée : 3 ms de plus que Wayland natif, et jusqu’à 4 ms par rapport à X11 optimisé. L’intervenant explique : « Le problème n’a jamais été Wayland. XWayland était la cause depuis le début. » Jusqu’à récemment, tous les jeux Windows sous Proton tournaient en XWayland, ce qui a créé la perception erronée que Wayland était mauvais pour le gaming.
VRR : l’optimisation la plus impactante
L’activation du VRR (G-Sync/FreeSync) réduit la latence de 0,26 à 0,45 ms et, surtout, lisse la distribution : l’écart entre le 5e et le 95e percentile passe de 2,6-3,0 ms (sans VRR) à 2,1-2,2 ms (avec VRR). Cela signifie moins de pics de latence, ce qui améliore la régularité perçue.
DXVK low-latency : un gain modeste mais constant
Le fork DXVK low-latency (intégré dans ProtonCachyOS) apporte un gain moyen de 0,2 ms en mode capé (FPS limité). Son vrai bénéfice apparaît en mode non capé : il lisse le frame pacing en maintenant la GPU à 95-97 % d’utilisation, évitant l’accumulation dans la file de rendu. Le coût est une perte de FPS (715 → 670 FPS dans le test), mais « si vous êtes au-dessus du taux de rafraîchissement, ça n’a pas d’importance ».
Wayland natif vs X11 : un match quasi nul
En comparant directement Wayland natif et X11 (tous deux avec VRR et DXVK low-latency), la différence n’est que de 0,14 à 0,22 ms en faveur de X11. L’intervenant conclut : « Wayland est légèrement moins bon, mais la différence est essentiellement imperceptible, surtout si vous utilisez VRR et DXVK low-latency. »
Configuration pratique pour le gaming sur Wayland
Pour activer le driver Wayland dans Proton, ajoutez PROTON_ENABLE_WAYLAND=1 %command% dans les options de lancement du jeu. Pour le DXVK low-latency, installez ProtonCachyOS via ProtonUp-Qt, puis ajoutez PROTON_DXVK_LOW_LATENCY=1 %command%. Attention : certains jeux peuvent ne pas fonctionner correctement avec ces options.
Limites et généralisation
Les résultats sont valables pour KDE et le matériel testé. L’intervenant précise : « Sur un écran à plus faible taux de rafraîchissement, les gains du VRR et du low-latency pacer seraient probablement encore plus grands. » Il recommande de tester sur d’autres environnements (GNOME, Hyprland) et avec des GPU AMD, où Wayland pourrait être encore meilleur.
CONCEPTS CLÉS
- XWayland : Couche de compatibilité permettant d’exécuter des applications X11 sur un serveur d’affichage Wayland. Elle introduit une latence supplémentaire significative (3-4 ms) par rapport au Wayland natif.
- VRR (Variable Refresh Rate) : Technologie (G-Sync, FreeSync) qui synchronise le taux de rafraîchissement de l’écran avec le FPS de la carte graphique, réduisant le tearing et la latence.
- DXVK low-latency : Fork de DXVK avec des patches pour améliorer le frame pacing et réduire la latence, notamment en limitant l’utilisation GPU à ~95 % pour éviter les files d’attente.
- Frame pacing : Régularité avec laquelle les images sont envoyées à l’écran. Un mauvais frame pacing (pics de latence) est plus perceptible qu’une latence moyenne légèrement plus élevée.
CONCLUSION
Le message principal est que Wayland n’est pas un problème pour le gaming, contrairement à une idée reçue tenace. La latence supplémentaire par rapport à X11 est inférieure à la milliseconde dans les pires cas, et les optimisations modernes (VRR, DXVK low-latency) la réduisent encore. Le véritable ennemi est XWayland, qui ajoute une latence notable et doit être abandonné au profit du Wayland natif. Pour l’administrateur système, cela signifie qu’il est temps de migrer ses configurations de jeu vers Wayland, en activant le driver Wayland dans Proton et en utilisant des forks optimisés comme ProtonCachyOS. Comme le résume l’intervenant : « Vous pouvez absolument jouer sur Wayland, mais il est peut-être temps d’arrêter d’utiliser XWayland pour tout. »