Mesure de la latence d’entrée sous Linux : X11 contre Wayland, VRR, DXVK

 (marco-nett.de)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Sur un écran 500 Hz, les mesures du clic jusqu’au changement de luminosité à l’écran montrent que, même en appliquant X11, le VRR et dxvk-low-latency, la latence de bout en bout médiane ne baisse que de 0,72 ms par rapport à Wayland par défaut
  • Wayland natif est 0,14 à 0,22 ms plus lent que X11, tandis que XWayland ajoute jusqu’à 3,13 ms par rapport à Wayland natif, créant un écart bien plus important
  • Le taux de rafraîchissement variable (VRR) réduit la latence de 0,26 à 0,45 ms dans toutes les comparaisons, et resserre aussi l’écart de distribution p5–p95 de 2,6–3,0 ms à 2,1–2,2 ms
  • dxvk-low-latency réduit la latence de 0,10 à 0,29 ms avec une limite de framerate, et de 0,84 ms sans limite, mais dans ce dernier cas les FPS passent de 715 à 670 tout en maintenant l’utilisation GPU à 95–97 % au lieu de 100 %
  • Les résultats proviennent de conditions optimales — FPS stables et goulot d’étranglement CPU — ainsi que d’une combinaison matérielle et logicielle précise ; en jeu réel, la réduction du jitter par le VRR et la limitation de la file de rendu par le frame pacer peuvent produire des différences supérieures à la médiane

Pourquoi vérifier directement les conseils d’optimisation

  • Le gaming sous Linux regorge de conseils d’optimisation : utiliser X11 plutôt que Wayland, désactiver la composition, employer un fork de DXVK optimisé pour la latence, utiliser un ordonnanceur de noyau pour le jeu, appliquer gamescope, gamemode ou des variables d’environnement, etc.
  • Dans les FPS compétitifs, une faible latence, des temps de frame réguliers et des FPS élevés sont importants, mais il est difficile de savoir si un changement de configuration apporte une amélioration réelle ou relève d’un placebo voire d’un effet inverse
  • Le matériel de l’appareil de mesure, son boîtier, son firmware, le code d’analyse et les données brutes sont publiés dans le dépôt GitHub click2photon

Un appareil qui mesure du clic au changement à l’écran

  • L’appareil est fixé au moniteur et déclenche un clic souris via USB, puis mesure le temps jusqu’à ce que le capteur optique détecte un changement à l’écran, afin de mesurer la latence système de bout en bout
  • La conception initiale s’est appuyée sur les schémas de l’OSLTT disponibles à l’époque, et des idées de m2p-latency et Open-Source-LDAT ont aussi été intégrées pendant la réalisation
  • La fabrication a nécessité un microcontrôleur, de la soudure, un firmware Arduino, un temps d’intégration, un amplificateur transimpédance, KiCad et la conception d’un boîtier
  • Un Adafruit QT Py RP2040 agit comme une souris USB HID à polling 1 000 Hz et génère les clics
    • Juste après l’envoi du clic, il collecte des échantillons de photodiode environ toutes les 24 µs
    • Pour chaque clic, 12 000 échantillons sont envoyés à l’hôte par liaison série et enregistrés en CSV
    • L’outil hôte calcule une ligne de base pour chaque clic et cherche le premier échantillon s’en écartant au-delà d’un certain seuil
    • Comme la durée de collecte des 12 000 échantillons est fixe, il est possible de calculer le temps écoulé entre l’envoi du clic et le changement de luminosité à l’écran

Configurations d’affichage et de rendu comparées

  • X11 et Wayland natif ont été comparés afin de confronter aux mesures l’impression selon laquelle Wayland serait plus lent
  • L’activation ou non du taux de rafraîchissement variable (VRR), qui inclut G-Sync et FreeSync, a été comparée
  • L’écart entre dxvk-low-latency et le DXVK par défaut a été mesuré
    • Le frame pacer de ce fork a été intégré au paquet officiel proton-cachyos, et s’active avec PROTON_DXVK_LOWLATENCY=1
  • Deux cas avec limite de FPS désactivée ont été ajoutés pour vérifier si le frame pacer absorbe les variations de frame time et empêche l’accumulation de la file de rendu
    • Dans la scène de jeu statique, il n’y avait pas de variation de frame time, et le test était aussi en condition de goulot d’étranglement CPU ; il ne reflète donc pas entièrement une session de jeu réelle
    • Dans une session réelle, les temps de frame peuvent varier selon la situation en jeu ou l’utilisation des ressources par d’autres processus
  • Les tests Wayland ont été exécutés par défaut en Wayland natif avec PROTON_ENABLE_WAYLAND=1, et deux cas XWayland avec VRR désactivé ont aussi été mesurés pour comparaison

Matériel et logiciels de test

  • Pendant les tests, un seul écran était connecté, avec la configuration matérielle suivante
    • AMD Ryzen 7 5800X3D
    • NVIDIA GeForce RTX 4070 SUPER
    • 2 modules DDR4 3 200 MHz de 8 Go
    • MSI MAG 272QP QD-OLED X50, 2560×1440, 500 Hz
    • MSI B450 GAMING PRO CARBON AC
  • La pile logicielle comprenait CachyOS, Kernel 7.1.3-2-cachyos, NVIDIA driver 610.43.03-1, KDE Plasma 6.7.2-1.1 et xorg-server 21.1.24-1.1
    • proton-cachyos-native 1:11.0.20260602-3 et dxvk 3.0 ont été utilisés
    • L’ordonnanceur de noyau par défaut de CachyOS a été conservé

Paramètres d’affichage et de DXVK

  • Le taux de rafraîchissement système a été réglé sur 500 Hz
  • Sous X11, le mode flip et le VRR ont été activés avec nvidia-settings, et un redémarrage est nécessaire pour modifier le VRR
  • Sous Wayland, le VRR s’active dans les paramètres de KDE et ne nécessite pas de redémarrage
  • Sous Wayland, le mode flip ou le scanout direct n’est pas réglé manuellement par l’utilisateur : le compositeur décide à chaque frame
    • Dans l’onglet Effects de KWin Debug Console, showcompositing a été activé
    • Si seul le jeu est affiché en plein écran, totalement au focus, et qu’aucune bordure rouge n’apparaît sur les bords, le mode flip est considéré comme actif
  • Un dxvk.conf optimisé pour chaque condition de comparaison a été utilisé
    • Avec VRR désactivé : dxgi.maxFrameRate = 500
    • Avec VRR activé et dxvk-low-latency désactivé : dxgi.maxFrameRate = 497
    • Lorsque VRR et dxvk-low-latency sont activés ensemble, le frame pacing VRR basse latence pour 500 Hz est utilisé avec les réglages suivants
dxgi.maxFrameRate = 480
dxvk.lowLatencyOffset = 70
dxvk.framePace = "low-latency-vrr-500"
dxvk.lowLatencyAllowCpuFramesOverlap = False
  • d3d11.cachedDynamicResources = "c" a été appliqué à toutes les configurations

Environnement de jeu et procédure de mesures répétées

  • Le jeu de test est Diabotical, un jeu DirectX 11 lancé avec Heroic et Proton
  • La résolution native et une échelle de rendu de 100 % ont été utilisées, Vsync a été désactivé, et les autres paramètres graphiques ont été réglés aussi bas que possible
  • Une commande cachée masquant brièvement l’UI a été liée au clic gauche avec /bind mouse_left testlatency, et un HUD affichant un grand carré blanc a été configuré afin d’augmenter l’écart de luminosité lors du clic
  • Chaque test a été répété dans les mêmes conditions
    • Fermeture des logiciels inutiles et lancement d’un serveur local avec le même mode et la même carte
    • Placement de la souris sur un repère précis du décor depuis une position donnée
    • Environ 100 clics sur 2 minutes, répétés 3 fois au total
    • Scène statique sans bots, autres joueurs, déplacement ni redémarrage de manche
    • Aucun autre processus significatif en cours d’exécution, et position de l’appareil de mesure fixe pour tous les tests

Plage de latence de l’ensemble des configurations

  • Tous les cas avec limite de framerate ont maintenu de manière stable les FPS visés, et le jeu est resté en goulot d’étranglement CPU pendant tout le test
  • Tous les cas présentent une distribution en cloche sans gros outliers, avec un écart d’environ 2 à 3 ms entre p5 et p95
  • Les médianes des 8 configurations principales vont de 4,21 à 4,93 ms, soit un écart total de seulement 0,72 ms
  • XWayland affiche une médiane jusqu’à 3,13 ms plus élevée que la configuration Wayland native correspondante, avec respectivement 8,06 ms contre 4,93 ms
  • Dans les cas sans limite de FPS, dxvk-low-latency réduit la latence de 0,84 ms par rapport au DXVK par défaut

Le faible écart entre X11 et Wayland natif

  • X11 est plus rapide dans toutes les configurations, mais l’écart est faible, 0,14 à 0,22 ms, ce qui ne suffit pas à expliquer l’impression que Wayland serait beaucoup plus lent
    • low-latency et VRR activés : X11 4,21 ms, Wayland 4,38 ms, écart +0,17 ms
    • low-latency seul activé : X11 4,64 ms, Wayland 4,83 ms, écart +0,19 ms
    • VRR seul activé : X11 4,45 ms, Wayland 4,67 ms, écart +0,22 ms
    • Les deux désactivés : X11 4,79 ms, Wayland 4,93 ms, écart +0,14 ms
  • La forme de la distribution de latence des deux serveurs d’affichage était également très similaire

Effet du VRR sur la latence et la distribution

  • Le VRR a montré le plus grand impact parmi les éléments comparés, avec un gain de 0,26 à 0,45 ms dans toutes les combinaisons
    • X11 avec low-latency : baisse de 4,64 ms à 4,21 ms, soit 0,43 ms
    • DXVK par défaut sous X11 : baisse de 4,79 ms à 4,45 ms, soit 0,34 ms
    • Wayland avec low-latency : baisse de 4,83 ms à 4,38 ms, soit 0,45 ms
    • DXVK par défaut sous Wayland : baisse de 4,93 ms à 4,67 ms, soit 0,26 ms
  • L’écart entre p95 et p5 est de 2,1 à 2,2 ms avec VRR, contre 2,6 à 3,0 ms sans VRR, ce qui resserre aussi la distribution de latence
  • Avec le VRR, une frame est scannée dès qu’elle est prête au lieu d’attendre le prochain créneau de scanout, ce qui correspond aux résultats mesurés

Effets et coût de dxvk-low-latency

  • Dans les cas avec limite de FPS, dxvk-low-latency réduit la latence dans toutes les combinaisons, avec une amélioration moyenne de 0,20 ms, proche de l’écart moyen de 0,18 ms entre X11 et Wayland
    • X11 avec VRR : baisse de 4,45 ms à 4,21 ms, soit 0,24 ms
    • X11 avec VRR désactivé : baisse de 4,79 ms à 4,64 ms, soit 0,15 ms
    • Wayland avec VRR : baisse de 4,67 ms à 4,38 ms, soit 0,29 ms
    • Wayland avec VRR désactivé : baisse de 4,93 ms à 4,83 ms, soit 0,10 ms
  • Sans limite de FPS, l’effet du pacer pour empêcher l’accumulation de la file de rendu et lisser un frame pacing irrégulier est plus marqué
    • Le GPU n’est pas totalement saturé et reste proche d’une situation de goulot d’étranglement GPU
    • L’utilisation GPU est de 100 % avec DXVK par défaut, contre 95–97 % avec dxvk-low-latency
    • La latence baisse de 5,27 ms à 4,43 ms, soit 0,84 ms
    • Les FPS diminuent de 715 à 670, soit 45 FPS de moins

La forte latence ajoutée par XWayland

  • Lorsque l’option Enable Wine-Wayland (Experimental) de Heroic Launcher ou PROTON_ENABLE_WAYLAND=1 est désactivée, le jeu s’exécute via XWayland
  • XWayland ajoute une latence importante par rapport à Wayland natif
    • low-latency activé : hausse de 4,83 ms à 5,95 ms, soit 1,12 ms
    • DXVK par défaut : hausse de 4,93 ms à 8,06 ms, soit 3,13 ms
  • Les 3,13 ms ajoutées avec DXVK par défaut dépassent la somme de tous les autres effets mesurés, et ne proviennent pas de quelques mauvaises frames qui augmenteraient la moyenne : c’est toute la distribution qui se décale
  • Ajouter dxvk-low-latency sous XWayland réduit la latence de 2,11 ms, la plus forte amélioration de tous les cas

Portée des résultats et interprétation en conditions réelles

  • Les mesures sont limitées à des conditions optimales — FPS limités et stables, goulot d’étranglement CPU, scène statique — et à une pile matérielle et logicielle précise
  • Dans d’autres environnements, les valeurs absolues de latence peuvent varier, mais les hausses et baisses observées pour chaque configuration devraient globalement se transférer
  • Sur des écrans à taux de rafraîchissement plus faible, les gains du VRR et du pacer basse latence pourraient être plus importants
  • X11 est 0,14 à 0,22 ms plus rapide que Wayland, mais des travaux d’optimisation de KWin pourraient réduire cet écart, et d’autres compositeurs Wayland pourraient déjà faire mieux
  • Hors XWayland, appliquer à la fois X11, le VRR et dxvk-low-latency donne une médiane 0,72 ms plus basse que la configuration Wayland par défaut
  • L’écart de médiane est faible, mais le VRR réduit le jitter de latence, tandis que dxvk-low-latency atténue les dégradations de frame time et les situations de goulot d’étranglement GPU rencontrées en jeu réel

Projets similaires de mesure de latence d’entrée

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis de Hacker News

  • Ce qui est bien avec Linux, c’est que ce genre d’analyse est non seulement possible, mais qu’elle débouche réellement sur une amélioration de l’écosystème. Les résultats remontent aux développeurs de logiciels graphiques et aux mainteneurs de paquets des distributions, alors qu’il semble difficile d’attendre un tel chemin d’amélioration chez Microsoft.
    Après avoir longtemps utilisé Windows, je suis récemment passé à Linux, et j’ai apprécié que KDE Plasma soit plus réactif que Windows 11, et qu’en cas de problème je puisse mettre les mains dedans pour l’améliorer. Si vous n’avez pas essayé le bureau Linux depuis un moment, je recommande Bazzite, une Fedora réglée pour le jeu ; même sans jouer, elle permet de mettre rapidement en place un bureau très abouti.

    • J’espère que cela se traduira vraiment par des améliorations. J’utilise Linux comme système principal et je l’aime bien, mais l’environnement de bureau et tout ce qui l’entoure sont devenus beaucoup plus complexes, tout en étant moins bons qu’avant.
      Autrefois, on pouvait changer ce qu’on voulait avec un simple fichier de configuration intuitif ; aujourd’hui, malgré les innombrables couches d’abstraction autour des thèmes, icônes, modes clair et sombre, il est difficile de trouver une combinaison qui fonctionne correctement. En mode clair, on se retrouve avec du texte gris sur gris clair ; en mode sombre, avec du texte noir sur fond noir ; et selon des thèmes comme Adwaita, même les lecteurs PDF n’arrivent parfois pas à déterminer correctement les couleurs du texte et de l’arrière-plan.
      Aucun thème ne rend les barres de défilement suffisamment visibles, ni ne distingue clairement les fenêtres actives et inactives par des couleurs nettes. Même Windows 3.11 gérait mieux les barres de défilement, l’indication de la fenêtre active et la personnalisation des couleurs : c’était finalement mieux avant cette surconception.
    • Microsoft pourrait aussi, avec un simple réglage, collecter des données de télémétrie sur des millions d’appareils et les transmettre aux développeurs de logiciels graphiques.
      Intel(https://www.techpowerup.com/312122/psa-intel-graphics-driver...) et Nvidia(https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...) collectent aussi ce type de données auprès des utilisateurs qui y ont consenti. Cela dit, dans les deux cas, c’est sur opt-in, donc il se peut qu’ils aient peu de données de joueurs passionnés.
    • Certaines choses s’améliorent effectivement, mais il existe aussi des domaines qui nécessitent une collaboration à grande échelle hors de portée des passionnés ou des petites entreprises. Appliquer une correction des couleurs cohérente à toutes les applications, ou prendre correctement en charge les fonctions avancées des imprimantes, en sont de bons exemples.
      Il y a beaucoup de changements progressifs, mais on reste souvent coincé pendant des années dans des optimums locaux. Cela dit, le fait de pouvoir inspecter relativement facilement le fonctionnement interne est appréciable, et je ne vois pas vraiment pourquoi Windows et macOS devraient nécessairement rester fermés.
    • Sous Windows aussi, on peut patcher des appels à l’API du noyau, remplacer la création d’objets COM, installer des pilotes de filtre qui interceptent les requêtes aux périphériques, voire substituer des DLL en espace utilisateur. Les interventions possibles sont si puissantes et dangereuses qu’une recherche sur certaines API mène à des forums black hat ou à des guides d’écriture d’exploits ; je me suis parfois demandé pourquoi c’était autorisé.
    • Ce qui est encore mieux, c’est que la majeure partie de la pile technique est open source, ce qui permet aussi d’y contribuer directement.

  • Il y a quelques mois, je suis passé à Fedora comme système principal et environnement de jeu, et l’ensemble m’a paru plus réactif que Windows ; ces mesures ont en partie répondu à mes questions sur la latence d’entrée dans les jeux.
    Je suis récemment passé à Hyprland basé sur Wayland, et je suis curieux de voir comment les résultats changeraient ; vu sa popularité croissante, ce serait bien de le retester. J’ai aussi envisagé Gamescope, mais j’ai entendu dire qu’il ne fonctionnait pas très bien avec Nvidia, et je viens seulement de découvrir l’existence de noyaux optimisés pour le jeu. Dans les jeux de combat compétitifs, la latence d’entrée est cruciale, donc j’aimerais entendre des retours sur des optimisations similaires.

    • En dehors de XWayland, les différences de latence d’entrée dans tous les tests sont trop faibles pour être perceptibles humainement, et même les 3 ms d’écart de XWayland seraient surprenantes à remarquer. Sur un moniteur lent, l’écart peut être plus important, mais la différence entre les protocoles Wayland et X11 eux-mêmes est minime ; c’est plutôt l’implémentation de XWayland qui semble avoir des contraintes.
    • Le gain en images par seconde obtenu en changeant de noyau est généralement minime, donc à chacun de voir si l’effort en vaut la peine. La principale différence se situe dans le planificateur, qui privilégie les processus exécutés brièvement et intensivement, plutôt que de répartir uniformément le temps CPU.
      Pour le jeu, Hyprland m’a plu, et les réglages fins comme le taux de rafraîchissement variable et le tearing via Gamescope étaient plus faciles qu’avec AwesomeWM sous X11. La configuration en Lua m’a aussi semblé familière venant d’AwesomeWM.
    • Une configuration consistant à lancer Gamescope dans un TTY séparé, puis à démarrer directement Steam ou Heroic Launcher, fonctionne très bien. Comme je joue de toute façon en plein écran, je n’ai pas besoin de gestionnaire de fenêtres, et cela a aussi réglé les problèmes de HDR ; en revanche, les touches de volume et de luminosité ne fonctionnent plus.
    • C’était similaire sous OpenSUSE, mais le point faible de Wayland était le streaming de jeux. Sunshine/Moonlight fonctionne, mais la latence d’entrée et les artefacts visuels sont visibles, donc je repasse entre X11, meilleur pour le streaming, et Wayland. J’espère qu’avec le temps je finirai par n’utiliser que Wayland.

  • Comme les tests ont été réalisés avec un écran 500 Hz, beaucoup de problèmes qui apparaissent sur des écrans à faible taux de rafraîchissement ont pu être masqués. Le fait que XWayland ait été 3 ms plus lent peut vouloir dire qu’à cette fréquence il avait une image de retard.
    Des tests à 120 Hz ou 60 Hz permettraient de distinguer plus clairement les petites différences de timing d’exécution des effets plus importants où une image entière arrive en retard.

  • À la fin de l’article, l’auteur s’étonne que Wayland soit considéré comme lent, mais les résultats de XWayland pourraient justement en être la raison. Il est possible que des utilisateurs ayant lancé des jeux X11 sous Wayland aient ressenti une latence significative. Ce serait bien d’avoir davantage de mesures réelles de ce type dans différents domaines.

    • Seul XWayland a obtenu de mauvais résultats, et l’écart n’est que de quelques millisecondes, ce qui rend difficile de croire qu’un humain l’ait perçu. 10 à 20 ms, je comprendrais, mais quelques millisecondes me semblent douteuses.
      L’auteur a bien éliminé les autres variables parasites, mais les utilisateurs qui ont eu l’impression que Wayland était lent sont peut-être partis d’un environnement non optimisé puis, en passant à une configuration à faible latence, ont aussi corrigé au passage les paramètres concernés.
    • Je pensais que Wayland avait toujours une image de retard par rapport à Xorg pour éviter le tearing ; je me demande si ce n’est plus le cas aujourd’hui. Si c’est le cas, un taux de rafraîchissement très élevé en aurait fortement réduit l’effet.
    • J’utilise Linux depuis le milieu des années 1990, mais je suis totalement incapable de distinguer X11 de Wayland, et le débat ne m’intéresse pas. Cela ressemble à une répétition des débats Vim contre Emacs ou GNOME contre KDE ; désormais, quand je vois ce genre de plaintes, je ferme la page.
    • On ne peut pas tester un seul compositeur Wayland et en tirer des conclusions sur les performances de tous les compositeurs Wayland. En particulier, les extensions Wayland nécessaires au traitement des périphériques d’entrée (https://wayland.app/protocols/) varient beaucoup selon les implémentations.
      Contrairement à X11, où Xorg se comporte à peu près partout comme l’implémentation de référence de fait, les différences entre implémentations Wayland sont importantes. Il peut exister des compositeurs plus lents que KDE Plasma, utilisé pour le test, comme des compositeurs plus rapides.
    • Pour juger si Wayland est rapide ou lent, il faut disposer de toutes les informations sur l’environnement : version du jeu, serveur d’affichage et ses réglages, paramètres du jeu, capacités du moniteur et de la carte graphique, version du pilote, etc.

  • L’expression latence d’entrée Wayland mélange elle-même des couches différentes, un peu comme fluidité des animations HTTP. Ce que cet article a mesuré, ce sont Xorg, KWin et XWayland ; d’autres implémentations X11 et Wayland peuvent avoir des caractéristiques différentes.
    Cela dit, la latence supplémentaire de XWayland paraît étonnamment élevée pour être traitée comme un simple surcoût.

    • Un autre article soupçonne le pilote Nvidia d’en être la cause : https://davidjusto.com/articles/m2p-latency/#results
    • Il faudrait aussi refaire les tests avec GNOME. Je n’ai pas creusé en profondeur, mais le compositeur Wayland de GNOME semble plus rapide et conçu avec davantage de soin que KWin.
      En particulier, Emacs en mode pgtk fonctionne bien mieux sous GNOME, alors que sous KWin il consomme beaucoup de CPU lors du défilement et peut même présenter une légère latence en haute résolution.
    • Le raisonnement autour de Wayland peut parfois être agaçant. On commence par dire que X est obsolète depuis longtemps et qu’il faut passer à Wayland, qui représente l’avenir ; puis, quand les utilisateurs disent que quelque chose est cassé ou fonctionne moins bien, on leur répond que Wayland n’est qu’un protocole et que c’est la faute de l’implémentation. Mais pour l’utilisateur, tout fonctionnait déjà correctement avec X.

  • Il serait aussi très intéressant de voir ce que donnerait une comparaison avec Windows sur le même matériel.

  • Chez Breaka Club, nous abordons directement ce problème en apprenant le code aux enfants avec une version modifiée d’Overcooked 2!.
    Comme il est difficile d’installer des mods sur les appareils des écoles, nous diffusons en WebRTC une version d’OC2 incluant le mod, et les enfants jouent dans Mobile Safari sur iPad avec une manette affichée à l’écran. Les instances du jeu s’exécutent dans des conteneurs Docker sur Kubernetes/k3s, sur un ancien matériel Nvidia ; comme le flux passe par Internet et le réseau de l’école, nous réduisons la latence totale en utilisant notamment les transferts sans copie de NVEnc et DMABuf.
    Nous subissons actuellement le surcoût d’entrée de XWayland, mais comme l’entrée provient d’un périphérique virtuel, le comportement peut être différent. L’optimisation de bout en bout est difficile, et les performances actuelles sont acceptables. Vidéo de codage avec OC2 : https://www.youtube.com/watch?v=ITWSL5lTLig
    Les licences OC2 sont achetées en nombre limité ; lorsqu’un pod démarre, il s’en voit attribuer une, et si toutes sont utilisées, les enfants jouent à un autre jeu.

  • Sous X11, lorsqu’on utilise le rendu composite, si une fenêtre plein écran envoie au compositeur un indice de désactivation de la redirection, la composition peut être suspendue tant qu’aucun autre élément n’est dessiné à l’écran, et la swapchain de l’application peut être transmise directement à l’écran. C’est en pratique la méthode optimale, donc difficile à améliorer.
    Si une autre fenêtre apparaît par-dessus, ou si le compositeur estime qu’il ne peut pas transmettre directement l’image, une étape intermédiaire apparaît : la fenêtre de l’application et les autres éléments sont composés dans un tampon temporaire. Si la désactivation de la redirection est rompue, par exemple parce qu’une fenêtre est créée avec une hauteur inférieure d’un pixel à celle de l’écran, ou si XWayland est utilisé, la latence peut augmenter ; c’est une contrainte fondamentale, et des problèmes similaires peuvent se produire avec les compositeurs d’autres systèmes d’exploitation.
    Wayland a aussi exploré les plans d’affichage (display planes), où le matériel GPU compose directement plusieurs couches. Avec cela, le jeu peut rendre au nombre maximal d’images par seconde tandis que les fenêtres au-dessus sont dessinées sur un plan séparé, ce qui permet la composition sans effet secondaire, mais je ne sais pas si c’est utilisé dans des environnements de production réels.

  • Les consoles visent plutôt un nombre d’images par seconde fixe en sortie et une résolution dynamique, tandis que les PC ont tendance à fixer la résolution et à laisser dynamiques le nombre d’images par seconde et les intervalles de frame time. Je me demande quel rapport cela a avec la latence
    Dans les jeux compétitifs en particulier, on vise un nombre d’images par seconde largement supérieur au taux de rafraîchissement de l’écran, mais je ne suis pas sûr que ce soit un vrai avantage ou une illusion

    • Du point de vue de quelqu’un qui travaille dans le rendu, un nombre élevé d’images par seconde aide d’une manière particulière. La position de rendu des objets est principalement déterminée au début du rendu d’une frame ; donc plus on génère souvent des frames, plus les objets affichés à l’écran sont proches de leur position réelle actuelle
      L’essentiel n’est pas de voir plus de frames, mais de voir des informations plus récentes. On pourrait aussi retarder le début du rendu pour qu’il se termine juste avant le rafraîchissement de l’écran, mais rater le timing de peu provoque de fortes saccades, et le temps d’exécution GPU comme le temps de soumission du travail côté CPU ne sont pas déterministes
    • Un nombre d’images par seconde supérieur au taux de rafraîchissement n’est pas totalement dénué d’intérêt, même s’il y a du gaspillage de ressources. C’est parce que chaque frame affichée reflète un état du jeu plus récent
      Idéalement, il suffirait de ne pas produire de frames inutiles et de lancer le rendu juste avant le rafraîchissement de l’écran, mais si l’on manque la deadline, on obtient des saccades très gênantes
    • Les jeux PC prennent eux aussi souvent en charge la résolution dynamique. Si les consoles visent généralement 60 fps, c’est parce que c’est le taux de rafraîchissement de la majorité des téléviseurs et que tous les utilisateurs ont la même configuration matérielle, ou seulement quelques variantes
      Une nouvelle frame peut s’insérer au milieu du balayage de l’écran, ce qui crée du tearing, mais sous la ligne de rupture s’affichent des pixels plus récents. Ainsi, plusieurs frames rendues peuvent se mélanger dans une seule frame du moniteur et, même si ce n’est pas aussi bon qu’un écran à taux de rafraîchissement variable et élevé, cela réduit la latence. Dans les jeux où l’action est moins importante, il est courant d’utiliser VSync pour caler les frames sur le taux de rafraîchissement et éliminer le tearing
    • Si c’est une illusion, elle est assez puissante pour pousser des joueurs compétitifs à sacrifier énormément les détails et la résolution afin d’obtenir un nombre d’images par seconde énorme. Moi aussi je vois la différence, mais à cause des rendements décroissants, je choisis généralement une résolution plus élevée et de meilleurs graphismes
      Certains jeux ajustent la résolution en temps réel pour maintenir un nombre d’images par seconde constant. Sur PC, on pouvait historiquement lancer des jeux sur des machines bien en dessous de la cible prévue, les faibles nombres d’images par seconde étaient culturellement plus acceptés, et si cela ne plaisait pas, on pouvait toujours upgrader. Les consoles n’ont pas de voie d’upgrade et doivent être optimisées pour une configuration unique ; il était donc plus adapté de réduire la résolution avant que les performances ne deviennent trop mauvaises
    • Au cœur d’un jeu se trouve une grande boucle exécutée à chaque frame. Si l’on produit des frames plus vite que le taux de rafraîchissement de l’écran, le prochain rafraîchissement a plus de chances d’utiliser une frame plus récente, ce qui réduit la latence d’entrée
      Cela ne signifie pas que le jeu reçoit davantage d’événements d’entrée, mais qu’il peut les traiter et les refléter plus rapidement. Ce n’est pas une illusion, mais les rendements décroissants sont importants, et l’effet dépend de la file de frames, de VSync, du taux de rafraîchissement variable, des goulots d’étranglement CPU ou GPU, ainsi que de la structure des boucles d’entrée et de simulation

  • L’auteur semble vouloir écarter l’illusion dès le départ, mais au final, la latence ne s’évalue-t-elle pas par le ressenti et l’usage ? À titre personnel, la manière dont on le ressent est le test final, et même si les données sont utiles pour diagnostiquer et corriger la latence réelle, je pense que, pour la plupart des UI/UX, on peut très bien s’appuyer sur les préférences et le ressenti
    Associer une évaluation moins technique, comme une note par étoiles, peut aussi éviter que les tests et la collecte de données ne s’enferment trop dans la méthodologie. Dans un test conçu avec beaucoup de précision, il est possible de passer à côté des conditions de dégradation des performances qui apparaissent fréquemment lors de l’usage quotidien d’un environnement donné

    • En tant que joueur de jeux de rythme au niveau national, j’ai du mal à être d’accord. ITGmania mesure la précision au 0,1 ms près, et si la latence matérielle varie entre les sessions ou pendant une session, le score est ruiné ; un environnement incohérent est extrêmement pénible. Il ne faut pas traiter la latence comme une question de sensation ou d’ambiance
    • Mon premier téléviseur TFT avait une latence d’entrée de 2 secondes, ce qui rendait les jeux injouables, et cela n’a rien à voir avec le ressenti. Une latence de seulement 10 ms a déjà un impact mesurable : https://www.youtube.com/watch?v=5qjSGEOEaXo
    • Dans les situations les plus importantes, ce n’est pas une illusion. Si deux joueurs de FPS de même niveau s’affrontent et que la latence du système de l’un est de 4 ms tandis que celle de l’autre est de 5 ms, alors même si aucun des deux ne ressent la différence entre les deux environnements, celui à 4 ms est statistiquement avantagé