- Selon les tests d’Ars Technica, SteamOS offre une amélioration notable du framerate dans quatre des cinq jeux testés
- Returnal, Borderlands3, Cyberpunk 2077, Homeworld 3, Doom: The Dark Ages
- Seul Borderlands 3 affiche un niveau de performances similaire sur Windows et SteamOS
- Les pilotes par défaut de SteamOS donnent globalement de meilleurs résultats que les pilotes Windows par défaut
- SteamOS se distingue notamment par une réduction de la surcharge du système d’exploitation et par les optimisations de Proton
- Microsoft montre aussi des signes de réaction en annonçant des fonctions d’optimisation de Windows pour le jeu
Principales améliorations de performances
- SteamOS montre une hausse notable du framerate dans 4 jeux sur 5
- Returnal, Borderlands3, Cyberpunk 2077, Homeworld 3, Doom: The Dark Ages
- Seul Borderlands 3 présente des résultats de performances presque identiques sur les deux systèmes d’exploitation, avec une légère tendance en faveur de Windows sur ce jeu
- Dans certains jeux, le simple changement de système d’exploitation entraîne une perte de framerate de 8 % à 36 %
- Dans le cas de Homeworld 3, Windows atteint un niveau de performances proche de SteamOS avec des réglages graphiques plus faibles lorsqu’on installe le pilote graphique fourni par Asus
- Sur les quatre autres jeux, les pilotes Windows par défaut de Lenovo se sont révélés nettement moins performants que ceux de SteamOS
Mises à jour des pilotes et évolution des performances
- L’installation manuelle du pilote Asus sur Windows améliore globalement les performances
- Avec le réglage graphique « Low » dans Homeworld 3, les performances des deux systèmes deviennent pratiquement équivalentes
- Dans les autres résultats de test, même un Windows mis à jour avec les derniers pilotes subit encore une perte de framerate de 8 % à 36 % par rapport à SteamOS
Optimisations de SteamOS et Proton
- Bien que SteamOS exécute les jeux Windows via la couche de compatibilité Proton, il affiche en pratique des performances supérieures à Windows
- Cela s’explique par l’optimisation continue menée par Valve sur Proton et sur les pilotes graphiques Mesa
Surcharge du système d’exploitation et réponse de Windows
- L’exécution sur SteamOS réduit les tâches inutiles en arrière-plan, ce qui favorise les performances
- Microsoft reconnaît également le problème et a récemment présenté, via "Xbox Experience for Handheld", une stratégie d’optimisation des performances en jeu comprenant la réduction des tâches en arrière-plan et le report des tâches non essentielles
- Cela laisse espérer, à l’avenir, des framerates plus élevés aussi sur les consoles portables de jeu basées sur Windows
1 commentaires
Commentaires Hacker News
Selon une expérience personnelle accumulée ces dernières années, le classement des performances en jeu serait le suivant : 1) Steam sur Linux avec Proton et Wayland (Niri), 2) Proton avec X11 (Xfce), 3) Steam sur Windows, 4) les jeux lancés sur Linux par d’autres moyens. Le changement le plus marquant en passant à Linux a été une meilleure constance des images par seconde, avec bien moins de micro-coupures, donnant une sensation de jeu beaucoup plus stable et prévisible. Après être passé de X11/Xfce à Wayland/Niri, le gain global en framerate s’est aussi fait sentir. Il note également qu’après plusieurs tentatives, c’est au début de 2023 qu’il a finalement réussi à s’y installer durablement. En revanche, comme les jeux passent par Proton ou Wine, les temps de lancement sont généralement plus longs, ce qui semble difficile à éviter
Fait intéressant, il est arrivé que même des jeux disposant d’un portage natif Linux offrent de meilleures performances en lançant la version Windows via Proton. Exemples donnés : Civ5, Civ6 et Cities Skylines (1). Comme il utilise du matériel non destiné au gaming — un portable avec GPU Nvidia 3050 Laptop — il ressent encore davantage cet écart. Dans le cas de Cities Skylines, Linux plafonne autour de 20 fps, tandis que Windows reste de manière stable entre 45 et 60 fps. Diablo 4 est également trop peu réactif sous Linux pour être réellement jouable. Selon lui, Linux convient très bien aux utilisateurs équipés de matériel gaming haut de gamme, mais Windows garde encore l’avantage sur les configurations modestes
Niri est vraiment un gestionnaire de fenêtres (WM) remarquable. Après avoir vu sur HN, via un article de Phoronix, qu’un mode overview avait été ajouté, il a finalement quitté Sway pour Niri. D’après son expérience, pour les jeux en plein écran ou les fenêtres flottantes, Niri présente bien moins de lag et de saccades qu’un environnement X11 (peut-être grâce à
xwayland-satellite). Petit conseil au passage : il a eu du mal à trouver une barre compatible aveci3status-rs, et a fini par adopteri3bar-riverIl joue sur Linux depuis des années et partage globalement les avis exprimés sur le framerate. Avec ZFS (sur un seul NVMe), il est possible d’obtenir des temps de chargement bien plus rapides que sous Windows. Il cite un cas concret où, à matériel identique, ses jeux se chargeaient souvent environ 10 secondes plus vite que sur le PC Windows de son mari
Question posée : existe-t-il une manière de rendre Wayland réellement utilisable avec un GPU Nvidia ? À chaque tentative, cela lui a toujours semblé lent, avec un système globalement plus lourd que sous X11
En plus du fait que les temps de lancement des jeux Steam sont en moyenne plus longs sur Linux à cause de Proton/Wine, il pense aussi, d’après son ressenti, que sous Linux les jeux Steam compilent les shaders sur le CPU et semblent moins optimisés. À l’inverse, Windows fournirait des shaders précompilés ou utiliserait davantage le GPU. Malgré cela, l’expérience Wayland + Linux reste bien plus stable et souffre de beaucoup moins de stutter que Windows. Il n’est toutefois pas certain que cette différence vienne vraiment de l’OS lui-même, ou simplement du fait qu’un système Windows a plus facilement tendance à s’alourdir à force d’installer diverses choses. D’autant plus que ses usages diffèrent aussi selon l’OS
Pour que le jeu sur Linux soit vraiment complet, la dernière pièce du puzzle serait l’anti-cheat. Les principaux acteurs hésitent à le prendre en charge à cause de limites de sécurité au niveau du noyau, et même lorsqu’un anti-cheat existe, les développeurs de jeux choisissent souvent de ne pas l’activer (comme pour Destiny). Si les jeux AAA fonctionnaient tous correctement, il abandonnerait complètement Windows. SteamOS est qualifié de meilleure innovation de l’histoire du jeu vidéo
Les anti-cheats modernes ne seraient en réalité qu’un palliatif temporaire. Avec l’amélioration de la sécurité des OS, l’impossibilité à long terme de maintenir des anti-cheats au niveau noyau dans des environnements de faible confiance, et la nature perpétuelle de course-poursuite entre tricheurs et défenseurs, les approches actuelles basées sur des hooks noyau montrent clairement leurs limites. Il propose comme alternative plus efficace un modèle où toutes les vérifications seraient faites côté serveur, et où le client ne recevrait que les informations nécessaires. Si un jeu de référence comme UT adoptait une telle architecture, les méthodes archaïques finiraient naturellement par disparaître
Avis selon lequel les jeux multijoueurs sans serveurs dédiés ont de toute façon des limites. Il ne veut pas d’un démon anti-cheat qui s’infiltre dans le noyau pour surveiller les fichiers ou la mémoire. D’après son expérience, les communautés basées sur des serveurs dédiés gèrent bien plus efficacement les joueurs qu’un matchmaking centralisé
Epic, en particulier, attribuerait son refus de prendre Linux en charge à la complexité, mais il y aurait aussi derrière cela une volonté d’exclure Steam, devenu de facto la boutique standard
Rappel que Easy Anti Cheat et Battle Eye prennent nativement en charge Linux depuis déjà plusieurs années, mais que leur activation réelle dépend des développeurs des jeux. Environ 40 % des jeux avec anti-cheat fonctionneraient sur Linux, et il est possible de le vérifier sur areweanticheatyet.com
Souvenir un peu mélancolique de technologies comme Valve Anti-Cheat (VAC), présentes à l’époque où des jeux comme Counter-Strike ont porté la popularité de Steam. Pourquoi VAC n’a-t-il pas su évoluer avec son temps ? Il aimerait que Valve réinvestisse dans VAC à l’ère de Linux et en fasse un véritable concurrent d’Easy Anti Cheat
Si des jeux Windows tournent plus vite sur SteamOS via Proton, alors les développeurs devraient prioriser l’API de SteamOS plutôt que Windows. Selon cette idée, cela permettrait à la fois d’assurer la compatibilité avec Windows et de maximiser les performances. Les principaux moteurs comme Unity ou Unreal devraient renforcer leur CI et leurs tests avec SteamOS comme cible principale. Il se demande si Valve exploite une ferme CI/CD pour SteamOS, et estime qu’avec des templates et bibliothèques Rust, il devrait être possible de faire aussi du build/test multiplateforme
Réponse opposée : l’API Windows reste la référence de fonctionnement du jeu (la « True Source »). Si un jeu fonctionne sous Windows mais pas sous Proton, Valve peut corriger Proton ; en revanche, si un jeu fonctionne uniquement sous Proton mais pas sous Windows, il risque au final d’être cassé. Il faut donc éviter, sous Proton, d’utiliser des fonctionnalités peu compatibles avec Windows, et tenir compte d’environnements comme le Steam Deck lors des tests, mais il reste préférable de conserver une stratégie de développement prioritairement orientée Windows
Il est souligné que, dans l’environnement SteamOS, le seul ABI réellement stable est Win32 ; développer uniquement pour SteamOS pourrait donc créer à long terme des problèmes de compatibilité
Comme Epic possède le moteur Unreal, certains doutent qu’il soit enthousiaste à l’idée d’optimiser pour SteamOS et ses API, dans un contexte de concurrence entre Epic Store et Steam
Rappel réaliste : l’écrasante majorité du marché (99 %) fonctionne encore selon les standards de Windows. Proton n’est au fond qu’une implémentation de Win32 ; cibler Proton revient donc essentiellement à cibler Windows
Souvenir étonnant de l’époque de Windows XP : faire tourner Windows au-dessus de Linux dans une VM VMWare donnait de meilleures performances que d’utiliser Windows seul sur le même matériel
Quelqu’un est récemment passé à Arch (sans base SteamOS) et décrit une expérience assez solide. Il précise honnêtement que cela ne fonctionne pas entièrement out-of-the-box et que chaque jeu nécessite un peu de configuration. Rien de très difficile toutefois, souvent juste quelques paramètres ajoutés à la commande de lancement, et Proton DB ainsi que les commentaires de la communauté fournissent presque toujours les conseils nécessaires. Il exprime une réelle satisfaction et voit mal une raison de revenir à Windows
Il y a environ 10 à 15 ans, quelqu’un utilisait alternativement Windows et Linux (Wine) avec le même jeu, en enregistrant entre 100 et 200 fichiers de sauvegarde. Fait surprenant, le chargement de la liste des sauvegardes était deux fois plus rapide sous Linux (Wine) que sous Windows. Il s’interroge sur l’origine d’un tel écart, alors même que NTFS n’est pas le système de fichiers natif de Linux
Si SteamOS et Ganoo/L00nockz (une manière humoristique d’écrire GNU/Linux, vraisemblablement) s’imposent pleinement comme plateformes de jeu, il envisage de monter un PC gaming pour la première fois depuis 2012. En tant qu’utilisateur Mac, il apprécie la base Unix pour le développement, mais regrette que l’expérience de jeu reste encore en retrait, même par rapport à Linux. Il s’attend à de grands changements d’ici cinq ans, une fois les sorties AAA et la stabilité des pilotes GPU encore améliorées
Les jeux AAA fonctionneraient en réalité déjà bien depuis plusieurs années, et avec le client Steam et un GPU AMD, Linux serait déjà une excellente plateforme de jeu
Depuis la sortie du Steam Deck, pratiquement tous les jeux tourneraient bien sous Linux, à l’exception de quelques titres volontairement rendus incompatibles (notamment à cause de l’anti-cheat). La compatibilité peut être vérifiée sur protondb.com ; parmi les 300 jeux Steam les plus populaires, seuls 17 ne fonctionneraient pas réellement, dont 5 ne seraient que des utilitaires
Il dit avoir toujours espéré que Windows devienne basé sur Unix, afin de réunir le meilleur du développement et du jeu sur une même plateforme. À ses yeux, la réalité actuelle s’en rapproche déjà beaucoup
Partage ironique de quelques liens expliquant que le noyau Windows serait aussi plus lent que d’autres OS, avec un billet de blog et une discussion HN associée
Certains estiment qu’il est inexact de qualifier Proton de « translation layer ». L’API Win32 n’est pas un ensemble d’appels système, mais un ensemble de fonctions exposées dans des DLL ; sous Linux, Proton fournit des DLL qui implémentent cette API Win32 au-dessus des appels système Linux, tandis que Windows utilise simplement ses propres DLL reposant sur ses propres appels système
Contre-argument : sur le site officiel de Wine, il est aussi présenté comme une « couche de compatibilité » qui traduit les appels à l’exécution ; parler de translation layer n’est donc pas vraiment faux
Hommage à l’histoire de développement acharnée de Wine, Proton inclus. Autrefois moqué comme une pseudo-solution créant de nouveaux problèmes, il est désormais vu comme une arme puissante pour remplacer Windows
Question posée sur un ton amusé : des fonctions comme
sscanf()ont-elles elles aussi été implémentées de manière inutilement complexe pour assurer la compatibilité ?Il est noté que Proton/Wine implémente aussi directement plusieurs appels système NT, et qu’en pratique de nombreux programmes Windows utilisent effectivement ces appels
Rappel de base : la nature profonde de Wine est de traduire l’ABI Windows en OS Linux et en userland Linux. Autrement dit, l’acte même de traduction est au cœur de la portabilité
Quelqu’un s’attendait à une différence de performances de 20 à 30 %, mais a été choqué de constater quelque chose de l’ordre de 200 à 300 %. Il aimerait que Microsoft lance un « Windows pour le gaming » débarrassé des fonctions inutiles, et précise qu’aujourd’hui il utilise Windows presque uniquement pour lancer Steam