Le problème de saccades dans les jeux sous Linux n'est pas dû à Proton, et un nouveau correctif du noyau pourrait révéler quelle en est la véritable cause

Résumé : Les problèmes de saccades et d'irrégularité du temps d'affichage (frame timing) observés lors des sessions de jeu sous Linux ne proviennent pas nécessairement de la couche de compatibilité Proton, mais parfois de la gestion énergétique des processeurs. Un correctif proposé pour le noyau Linux, nommé epp_boost, met en lumière un dysfonctionnement sur les puces AMD où la fréquence du processeur chute lors de brèves pauses de calcul pour ensuite tarder à remonter, provoquant ainsi des chutes de performances (1% lows). En ciblant spécifiquement les cœurs sollicités afin de leur réattribuer temporairement une puissance maximale sans surconsommer d'énergie globale, ce correctif a permis d'améliorer la fluidité jusqu'à près de 32 % sur le Steam Deck, démontrant que l'origine de certaines instabilités réside directement dans les pilotes et la gestion du matériel.

Linux a fait des progrès fulgurants tant dans le domaine du jeu vidéo que dans celui de la productivité en général. La maturité grandissante du noyau et la multitude de distributions offrent aux anciens utilisateurs de Windows et de Mac une alternative viable aux écosystèmes fermés des grandes entreprises. L'essor du jeu sous Linux s'explique en grande partie par l'arrivée massive des consoles de jeu portables et par le développement de Proton par Valve, qui permet aux jeux Windows de fonctionner aussi bien, voire mieux, qu'en mode natif sous Windows, selon les titres. Le système n'est toutefois pas encore parfait, mais un nouveau correctif du noyau suggère que certains problèmes pourraient être causés par d'autres éléments, notamment les pilotes.

Comment la fréquence d'images influe sur le gameplay

Le « frame time » correspond à la durée exacte nécessaire à un système pour afficher une image unique, mesurée en millisecondes (ms). Alors que la fréquence d’images (FPS) permet d’évaluer les performances globales moyennes du jeu, le « frame time » mesure l’intervalle de temps entre chaque image affichée. Tout cela est étroitement lié, car pour calculer le frame time, il faut diviser 1 000 millisecondes par le nombre d'images par seconde. Par exemple, 60 images par seconde correspondent à un frame time d'environ 16,7 ms. Un frame time régulier est généralement synonymes d'une expérience de jeu plus fluide.

Imaginons que vous ayez un FPS moyen de 60. C’est plutôt bon pour un jeu exigeant et cela devrait se traduire par un gameplay fluide, mais si le temps entre les images n’est pas constant, vous pourriez observer des durées allant de 16 ms à 50 ms, voire plus, pour chaque image, ce qui peut provoquer des micro-saccades. C’est pourquoi nous ne fournissons généralement pas uniquement le FPS moyen, car cela ne donne pas une vision globale de la situation. Une moyenne de 60 FPS pourrait masquer un creux de 1 % qui réduit considérablement les performances. 

Le « 1 % le plus bas » dans un jeu correspond à la fréquence d’images moyenne du 1 % le plus lent de toutes les images. Imaginons qu’une moyenne de 60 FPS oscille pendant un certain temps autour de la fin des 50. Ce n’est pas catastrophique en soi, mais si un pic de performance fait chuter la fréquence d’images à 15 FPS, cela sera perceptible sans pour autant se refléter clairement dans la fréquence d’images moyenne. C’est là que le « 1 % le plus bas » entre en jeu : il vous permet de voir s’il y a des baisses fréquentes de performances. En général, plus le « 1 % le plus bas » est proche de la moyenne, plus l’expérience devrait être fluide.

Le timing des images peut également aider à mettre les choses en perspective. Si un PC affiche une succession d’images presque instantanément, avec un intervalle d’environ 5 ms entre chacune d’elles, mais qu’il marque ensuite une pause avant d’afficher les images suivantes, le compteur peut tout de même indiquer une moyenne de 60 FPS, même si l’expérience visuelle ne reflète pas cette valeur. Les technologies modernes telles que le taux de rafraîchissement variable (VRR), Nvidia G-Sync et AMD FreeSync peuvent contribuer à réduire l’impact visuel de l’instabilité du système pendant le jeu, en lissant l’affichage afin que ces irrégularités soient moins perceptibles. 

Linux présente un problème de compatibilité

La plupart des jeux ne sont pas conçus pour Linux. C'est là le nœud du problème. Ils sont conçus pour Windows et parfois pour macOS. Certes, les développeurs peuvent proposer une prise en charge de cette plateforme ouverte, et ils le font souvent, mais cela n'est jamais garanti. Valve souhaitait lancer la Steam Deck, une console de jeu portable fonctionnant sous Linux et destinée à concurrencer le marché des consoles de salon. L’expérience de jeu sous Linux n’était pas parfaite ; cette console portable n’aurait donc pas été aussi performante sans les ressources investies par Valve dans Proton, une couche de compatibilité qui utilise d’autres outils tels que Wine, dont le nom signifie « Wine Is Not an Emulator » (Wine n’est pas un émulateur).

Plusieurs éléments du système pourraient être tenus pour responsables des problèmes liés au jeu, qu’il s’agisse de Proton, de DXVK ou d’une autre pièce du puzzle, mais il y a souvent un autre aspect qui est complètement négligé dans les discussions sur les performances des jeux : le noyau, les pilotes du processeur et le micrologiciel du système. C’est précisément à cela que pourraient remédier les nouveaux correctifs de noyau proposés par David Vernet, développeur du noyau Meta, pour les systèmes AMD. Bien que les tests se soient jusqu’à présent concentrés sur la Steam Deck et son APU AMD, le correctif epp_boost pourrait également profiter à d’autres systèmes AMD pris en charge.

Vernet a découvert une défaillance dans le système de contrôle actif « Energy Performance Preference » (EPP) d’AMD. Bien qu’il n’ait pas été développé par AMD, ce correctif est actuellement examiné par les ingénieurs de la société spécialisés dans la gestion de l’énergie sous Linux. Le problème que ce correctif vise à résoudre concerne ce qui se passe lorsqu’un thread de jeu sensible à la latence s’arrête brièvement pour attendre une autre tâche, une barrière GPU ou un événement de synchronisation. Au cours de ces brèves pauses, le signal de demande de performance du processeur peut s’affaiblir, ce qui entraîne la reprise du thread à une fréquence d’horloge inférieure et peut potentiellement lui faire manquer son délai d’affichage d’image, réduisant ainsi les minima de 1 %.

C’est là qu’intervient le correctif epp_boost. Le P-State d’AMD délègue une grande partie de la prise de décision à la plateforme, en utilisant des limites de performance minimales et maximales parallèlement à l’EPP afin d’assurer un équilibre souhaité entre vitesse et efficacité. C’est particulièrement important pour les appareils portables dotés de batteries internes et d’une autonomie limitée. Vernet a découvert que le cœur le plus sollicité d’une Steam Deck passait de 3,5 GHz à environ 2,4 GHz après une brève mise en veille du thread de jeu. Cette fréquence de fonctionnement réduite pouvait persister pendant environ 8 ms et, dans certains cas, jusqu’à quelques secondes après le réveil du thread.

Les tests ont suggéré que le problème était lié au firmware ou à l’estimation de la demande par l’unité de gestion du système, plutôt qu’à Proton ou à la couche de compatibilité elle-même. Ce comportement était particulièrement visible dans un jeu très gourmand en ressources CPU tel que Civilization VI.  

Le rôle d'epp_boost

La réponse la plus simple serait : « Eh bien, il suffit de tout régler à 100 % de performances ou de puissance », mais cela serait préjudiciable aux appareils portables tels que la Steam Deck et d’autres consoles de jeu portables. C’est là qu’epp_boost peut s’avérer utile en échantillonnant la « résidence C0 » de chaque cœur, qui mesure le temps que le cœur a passé à exécuter activement des tâches plutôt qu’à rester inactif. Lorsqu’un échantillon montre que le cœur a été utilisé à au moins 50 %, le correctif du pilote écrit temporairement la valeur de performance maximale (zéro) dans son champ EPP. La requête EPP précédente est rétablie lorsque 300 ms se sont écoulées sans qu’un autre échantillon éligible ne soit détecté.

Il s’agit d’une approche bien plus judicieuse que de faire tourner tous les cœurs à plein régime pour compenser. Elle évite d’appliquer un biais de performance maximale à l’ensemble du processeur, ce qui contribue à préserver le budget énergétique limité partagé entre le processeur et la carte graphique intégrée. Plutôt que d’augmenter la fréquence minimale du cœur sollicité ou de forcer tous les cœurs à passer en mode axé sur les performances, epp_boost fournit essentiellement un biais temporaire aux cœurs qu’il détecte en charge de travail soutenue. Le périphérique peut par ailleurs contrôler les cœurs comme d’habitude, mais il dispose d’une meilleure visibilité sur les moments où un cœur particulier nécessite une réponse rapide en termes de performances.

Alors, quel gain de performances peut-on espérer ? Vernet a réalisé des tests et des comparaisons en alternance en exécutant six itérations de Civilization VI sur la Steam Deck LCD. Avec les paramètres par défaut, le cœur du thread principal affichait une fréquence médiane de 2,43 GHz, bien qu’il ait été utilisé à 98 % tout au long du benchmark. L’activation de l’option epp_boost a fait passer cette médiane à 3,5 GHz et a amélioré les valeurs minimales de 1 % de 31,8 %.

Le réglage global de l’EPP sur « performance » a également fait passer la fréquence médiane à 3,5 GHz et amélioré les valeurs minimales à 1 % d’environ 16 %, mais cela a appliqué la préférence de performance à tous les cœurs et à toutes les charges de travail. Une expérience distincte visant à augmenter la performance minimale du cœur le plus sollicité a détérioré les temps d’affichage p999 les plus extrêmes de 13 % à 21 %.

Ce n'est pas toujours la faute de Proton

Cette solution proposée montre que lorsque vous rencontrez des problèmes de performances, ceux-ci ne sont pas forcément liés à Proton. Bien que ce soit généralement l'une des premières cibles pointées du doigt par les joueurs, la situation peut s'avérer plus complexe qu'il n'y paraît à première vue. Il est important d'envisager d'autres solutions et d'effectuer des tests rigoureux afin de déterminer avec précision ce qui pourrait être à l'origine des baisses de performances.

Le patch epp_boost est encore au stade de RFC (appel à commentaires) et n'est pas encore une fonctionnalité acceptée dans la branche principale de Linux ; sa mise en œuvre est susceptible d'évoluer au cours du processus de révision. Pour les appareils portables équipés de processeurs AMD, ce patch potentiel du noyau pourrait toutefois s'avérer très intéressant. 

traduction de : https://www.xda-developers.com/linux-gamings-frame-timing-problem-was-always-the-driver-not-proton-and-amd-just-proved-it/