Linux Gaming Didn't Happen By Accident

La Steam Machine de Valve n'est pas un cadeau fait au gaming Linux, mais le pari que la pile logicielle open source, construite par une constellation de développeurs souvent méconnus, est enfin assez mature pour justifier un hardware non subventionné.

Voir la source

Voici l’analyse détaillée de la transcription que tu m’as fournie.

SYNTHÈSE STRUCTURÉE

Valve n’a pas construit le gaming Linux seul

L’intervenant insiste sur le fait que le récit habituel, qui attribue tout le mérite à Valve, est trop simpliste. “The story flattens the picture and erases the people who made this possible.” Valve a certes financé et orienté une grande partie du travail, mais les développeurs qui ont écrit le code sont les véritables artisans. Leur travail préexistait souvent à l’implication de Valve.

La Steam Machine comme “forcing function”

Le lancement d’un hardware contraint Valve à corriger tous les bugs qu’il expose. Ces correctifs ne sont pas propriétaires : “They follow upstream. They land in Debian Trixie… They land in Arch the next day.” La Steam Machine est donc un accélérateur : elle force Valve à financer massivement le travail upstream, car le succès de son matériel en dépend désormais.

La proposition de valeur repose sur le logiciel

Valve ne subventionne pas le hardware. “They are promising that the Steam machine is going to be priced as a piece of PC hardware and not as a console.” Pour être compétitive face à une machine Windows au même prix, la Steam Machine doit donc s’appuyer sur une pile logicielle Linux suffisamment performante. C’est ce qui rend le travail des développeurs cités si crucial.

Alexandre Julliard et Wine : 30 ans de rétro-ingénierie

Alexandre Julliard maintient Wine depuis 1994, soit plus de 30 ans. Il est CTO de CodeWeavers depuis 2003, et CodeWeavers est responsable d’environ deux tiers de tous les commits de Wine. “30 years of patient reverse engineering decades before Proton even existed.” C’est la fondation sur laquelle tout le reste est bâti.

Philip Rebohle et DXVK : la traduction Direct3D 9/10/11

Philip Rebohle a créé DXVK fin 2017, initialement pour faire fonctionner NieR:Automata sur Linux. Ce projet traduit les appels Direct3D 9, 10 et 11 en Vulkan. Sans DXVK, Proton ne serait qu’une curiosité. Avec, c’est une plateforme. Rebohle est aujourd’hui un contractant de Valve.

Hans-Kristian Arntzen et VKD3D-Proton : la traduction Direct3D 12

Hans-Kristian Arntzen (et non Anderson) dirige le projet VKD3D-Proton, qui fait la même chose que DXVK mais pour Direct3D 12. C’est la raison pour laquelle certains jeux Windows tournent parfois plus vite sur Linux que sur Windows. Lui aussi est un contractant de Valve.

Mike Blumenkrantz et Mesa : le moteur graphique open source

Mike Blumenkrantz est le développeur de Zink, une couche de traduction OpenGL vers Vulkan. Il est le contributeur le plus prolifique de Mesa depuis deux ans, avec près de 7% du projet total en 2025. Il travaille pour Valve. Mais le pilote RADV (le pilote Vulkan open source pour AMD) a été lancé en 2016 par David Airlie (Red Hat) et Bas Nieuwenhuizen (indépendant), parce qu’AMD traînait des pieds. “This is not a Valve story. This is a Red Hat story and one guy in his spare time story.”

Joshua Ashton et Gamescope : le compositeur HDR

Joshua Ashton, chez Valve, est le moteur principal de Gamescope, en particulier pour le support HDR. Gamescope est dérivé d’un ancien compositeur SteamOS, mais Ashton l’a transformé en ce qu’il est aujourd’hui.

Les projets indépendants : Lutris et Heroic Games Launcher

Matthew Commandon a créé Lutris en 2009, sans aucun financement de Valve. Flavio Fares a créé Heroic Games Launcher pendant une semaine de vacances enneigée en Suède, “because he was bored”. Là encore, aucun argent de Valve. Ces projets montrent que la communauté a construit des outils essentiels de son propre chef.

Bazzite : le projet communautaire qui comble l’attente

Kyle Gospodetic a fondé Bazzite fin 2022, un projet communautaire (pas Valve) qui est aujourd’hui “the closest thing for SteamOS-like hardware that Valve doesn’t make”. Il répond au besoin immédiat des utilisateurs qui ne veulent pas attendre la sortie officielle de SteamOS.

Valve a payé, mais en open source

L’intervenant est honnête : “a lot of people I just named are funded by Valve in one way or another.” Il cite Philip Rebohle, Hans-Kristian Arntzen, Mike Blumenkrantz, Samuel Pitoiset, Joshua Ashton, Pierre-Loup Griffais (le pont entre Valve et l’upstream), et même l’équipe de FEX (l’émulateur Windows on ARM). Mais le point crucial est que Valve aurait pu tout rendre propriétaire. Au lieu de cela, “every line of code stays upstream where Debian and Arch and Bazzite can simply use it.”

CONCEPTS CLÉS

  • Upstream : Le flux de développement principal d’un projet open source. Les correctifs sont “poussés en amont” pour être intégrés dans la version officielle, bénéficiant ainsi à toutes les distributions.
  • DXVK : Une couche de traduction qui convertit les appels graphiques Direct3D 9, 10 et 11 en appels Vulkan, permettant aux jeux Windows de fonctionner nativement sur Linux.
  • VKD3D-Proton : L’équivalent de DXVK pour Direct3D 12.
  • Mesa : L’implémentation open source des API graphiques (OpenGL, Vulkan) pour les pilotes GPU.
  • RADV : Le pilote Vulkan open source pour les cartes graphiques AMD, faisant partie de Mesa.
  • Gamescope : Un compositeur Wayland minimaliste utilisé par SteamOS pour gérer l’affichage des jeux, notamment le HDR et le VRR.
  • FEX : Un émulateur permettant d’exécuter des applications x86 et x86-64 sur des processeurs ARM, utilisé par Valve pour le Steam Deck et potentiellement la Steam Machine.

CONCLUSION

Le message principal est que le gaming Linux n’est pas l’œuvre d’une seule entreprise, mais le résultat de décennies de travail acharné par des développeurs individuels et des petites équipes. Valve a eu le mérite de reconnaître ce travail, de le financer et de le laisser ouvert, plutôt que de le verrouiller. La Steam Machine est le point d’orgue de cette synergie : le moment où le grand public réalise que la fondation est solide. Pour l’administrateur système, cela signifie que la pérennité du gaming sur Linux ne dépend pas d’une seule entité, mais d’un écosystème résilient et upstream, où chaque correctif profite à tous.

Du même canal

Tout voir