Philosophie d'ingénierie : John Carmack, la performance comme artisanat moral

Points clés

• Carmack envisage la performance comme une question morale, et non comme une passe d’optimisation. L’écart entre votre code et la limite physique du matériel, c’est du gaspillage — et le gaspillage est un choix.
• Sa méthode est soustractive : comprendre le problème jusqu’à ses fondations, le réduire à son cœur rapide et simple, et refuser toute fonctionnalité qui ralentirait ce cœur.
• Lorsque le problème sous-jacent change, il réécrit à partir de zéro. Quake a jeté le moteur qui avait fait la renommée d’id, parce que la vraie 3D était un problème différent de celui qui consistait à la simuler.
• Il travaillait à découvert — d’abord les journaux quotidiens .plan, puis des moteurs publiés en open source — animé par une seule conviction : un code que vous publierez est un code que vous écrivez plus honnêtement.

Le principe

« The speed of light sucks. » (« La vitesse de la lumière, c’est nul. ») — John Carmack¹

C’est une blague, et c’est toute la philosophie. Carmack l’a dit à propos de la latence réseau — le plancher physique infranchissable qui limite la vitesse à laquelle un paquet peut traverser un continent — mais ce sentiment traverse chaque ligne qu’il a écrite. La machine est régie par la physique, et le travail de l’ingénieur consiste à s’approcher de la limite physique autant que le problème le permet. Pas assez près. Aussi près que la physique l’autorise. Tout ce qui sépare l’utilisateur de la vitesse de la lumière est du gaspillage, et le gaspillage est un choix que vous avez fait.

Carmack envisage la performance comme une question morale plutôt que comme une passe d’optimisation. La plupart des logiciels accumulent de la lenteur comme une maison accumule le fouillis — une décision raisonnable à la fois, chacune défendable, leur somme indéfendable. La discipline de Carmack consiste à refuser cette accumulation : comprendre le problème jusqu’à ses fondations, le réduire à son cœur rapide et simple, et livrer cela. La même conviction sous-tend l’argument selon lequel la performance n’est pas une fonctionnalité que l’on ajoute, mais une propriété que l’on échoue à préserver — on n’optimise pas un système lent pour le rendre rapide ; on construit un système rapide et on le défend.

Et il montrait son travail. Pendant plus d’une décennie, Carmack a publié son journal d’ingénierie quotidien — son fichier .plan — sur l’internet ouvert, lisible par quiconque disposait d’un client finger.² Les problèmes de rendu 3D les plus ardus des années 1990 ont été résolus en public, quasiment en temps réel. Travailler à découvert n’était pas du marketing. C’était le même instinct que celui du code lui-même : aucun état caché, rien qu’on ne puisse inspecter.

Le contexte

John D. Carmack est né le 21 août 1970 à Shawnee Mission, dans le Kansas.³ Il a fréquenté l’université du Missouri à Kansas City pendant deux semestres, puis l’a quittée pour écrire des logiciels et en vivre. Pas d’apprentissage formel, pas de diplôme. Il a appris la programmation graphique comme l’a fait la demoscene — en lisant les manuels du matériel, en mesurant ce que la puce faisait réellement, et en écrivant de l’assembleur jusqu’à ce que les chiffres tombent juste.

Il a atterri chez Softdisk, une entreprise de logiciels et de magazines sur disquette à Shreveport, en Louisiane, où il travaillait sur un abonnement de jeux baptisé Gamer’s Edge. C’est là qu’il a rencontré John Romero, Tom Hall et Adrian Carmack (sans lien de parenté). En septembre 1990, Carmack a construit une démonstration qui aurait dû être impossible sur un PC : un défilement latéral fluide, de qualité console, sur du matériel EGA. Le PC IBM de 1990 redessinait tout l’écran à chaque image — trop lent pour un jeu à défilement. La technique de Carmack, le adaptive tile refresh, exploitait des fonctionnalités obscures du matériel EGA pour faire glisser l’écran déjà dessiné et ne repeindre que les bords nouvellement exposés.⁴ L’équipe a reconstruit le premier niveau de Super Mario Bros. 3 de Nintendo sous forme de démo PC pour en faire la preuve. Nintendo a décliné. L’équipe a gardé le moteur.

En février 1991, ils ont quitté Softdisk pour fonder id Software. Le schéma était déjà fixé : trouver le problème que personne n’avait résolu, le résoudre au niveau du matériel, construire le produit par-dessus la solution. Carmack allait recommencer avec la 3D à plaquage de textures, puis avec la vraie 3D polygonale, puis avec la réalité virtuelle. Le milieu qui l’entourait — le Graphics Programming Black Book de Michael Abrash, la culture du comptage de cycles propre à la demoscene — traitait le processeur comme quelque chose à comprendre exactement, et non à approximer. Carmack a rendu cette culture célèbre.

L’œuvre

Commander Keen et Doom : le cœur rapide (1990-1993)

Commander Keen in Invasion of the Vorticons (décembre 1990) fut le premier jeu commercial bâti sur l’adaptive tile refresh. Il comptait moins comme jeu que comme preuve : qu’une lecture attentive du matériel pouvait combler l’écart entre un PC généraliste et une console dédiée. Le défilement fluide n’était pas une astuce graphique posée par-dessus. C’était le moteur.

Doom (1993) est l’exemple canonique de la méthode de Carmack. Pour rendre ses environnements assez vite sur un PC de 1993, il a adopté le binary space partitioning — les arbres BSP, formalisés dans un article académique de 1980 que Carmack a retrouvé et adapté — afin de précalculer l’ordre dans lequel les murs devaient être dessinés, pour que le moteur ne redessine jamais un pixel qu’il recouvrirait ensuite.⁵ Doom n’est pas de la vraie 3D ; c’est une carte 2D rendue avec assez d’ingéniosité pour donner une impression de volume. Cette distinction est tout l’enjeu. Carmack n’a pas construit le système le plus général. Il a construit le système qui tournait vite sur le matériel qui existait, et a refusé toute fonctionnalité qui aurait ralenti la boucle centrale. Le cœur rapide et simple, livré.

Quake : la vraie 3D logicielle (1996)

Quake (1996) fut la reconstruction à partir de zéro. Là où Doom feignait la profondeur, Quake rendait de véritables mondes polygonaux en trois dimensions — surfaces inclinées, regard vers le haut et vers le bas, géométrie réelle — de façon logicielle, avant que les accélérateurs 3D grand public ne soient répandus.⁶ Le moteur combinait une visibilité BSP précalculée avec des lightmaps générées hors ligne et de l’assembleur affiné à la main pour accomplir ce que la sagesse établie jugeait impossible pour un processeur de cette époque. id a plus tard publié GLQuake, un moteur de rendu OpenGL, qui a contribué à légitimer la carte graphique 3D grand public.

Quake est l’œuvre où toute la posture de Carmack est visible d’un seul coup : il a jeté le moteur qui avait rendu l’entreprise célèbre, a compris le nouveau problème (la vraie 3D) jusqu’à ses fondations, et a reconstruit. Aucune réutilisation pour elle-même. La solution précédente n’était pas sacrée ; le problème l’était.

Les moteurs id ouverts et les fichiers .plan (1997-2011)

Carmack a fait deux choses inhabituelles avec le code qui l’a rendu riche. Il a publié son journal de travail quotidien — les fichiers .plan — pour que l’ingénierie soit lisible au fil de sa réalisation.² Puis il a donné les moteurs. id a publié en open source le moteur de Doom en 1997, celui de Quake en 1999, et a continué à diffuser le code source de chaque génération d’id Tech au fur et à mesure que la suivante sortait, jusqu’à Doom 3 et au-delà.⁷ Son argument était simple : publier l’ancien code permet aux développeurs plus jeunes d’apprendre comment la chose a réellement été construite, et « le logiciel libre auquel les gens accordent de la valeur ajoute de la richesse au monde ».⁸

Cette disposition est la part que la plupart des ingénieurs obsédés par la performance n’atteignent jamais. L’artisanat de Carmack, c’était une discipline privée rendue publique. La volonté d’être lu — de laisser quiconque inspecter le journal quotidien et, à terme, le code source — est en soi un pacte de qualité. Un code que vous publierez est un code que vous écrivez plus honnêtement.

Oculus VR : le plancher de latence (2013-2019)

Chez Oculus, l’ennemi de toute une vie de Carmack — la latence — est devenu le problème tout entier. Il a écrit que « la latence entre le mouvement physique de la tête d’un utilisateur et l’arrivée à ses yeux des photons actualisés d’un casque monté sur la tête est l’un des facteurs les plus critiques pour offrir une expérience de haute qualité », et qu’une latence perceptible du suivi de tête « est aussi l’une des principales causes du mal du simulateur ».⁹ Il a fixé un budget — l’objectif était de l’ordre de 20 millisecondes du mouvement au photon — et a traité chaque étape du pipeline comme un endroit où récupérer des microsecondes. Sa technique de timewarp reprojette une image déjà rendue à l’ultime instant avant l’affichage, afin d’absorber le mouvement de tête survenu pendant le rendu.⁹ C’est de nouveau l’adaptive tile refresh, vingt-trois ans plus tard : ne pas redessiner ce que l’on peut réutiliser, et mesurer le résultat à l’aune de la limite physique.

La méthode

La méthode est constante sur trente ans et quatre domaines de problèmes.

Comprendre le problème jusqu’à ses fondations. Carmack lit le manuel du matériel, mesure le comportement réel, et travaille à partir des premiers principes plutôt que de la convention. Les arbres BSP, les lightmaps et le timewarp ne figuraient dans aucun manuel ; ils découlaient de ce que le problème exigeait réellement.

Réduire au cœur rapide et simple. Doom n’est pas en 3D parce que la 3D n’était pas nécessaire pour donner une impression de 3D sur le matériel de 1993. La discipline est soustractive : identifier la boucle interne, la rendre rapide, et refuser les fonctionnalités qui la ralentiraient.

Réécrire à partir de zéro quand le problème change. Quake n’a pas prolongé le moteur de Doom. Carmack traite un système qui fonctionne comme jetable dès l’instant où le problème sous-jacent a bougé. Le coût irrécupérable n’est pas un argument.

Une concentration profonde et ininterrompue. Les sessions de programmation marathon de Carmack n’ont jamais été une affaire d’endurance pour elle-même. Tenir un moteur entier en mémoire de travail — l’organisation des données, la boucle interne, tous les cas limites à la fois — prend des heures à charger et se brise à l’instant où l’on change de contexte. Il protégeait cet état comme il protégeait les cycles dans la boucle de rendu : comme la ressource rare sur laquelle le travail tournait réellement.

Plus tard : un style fonctionnel en C. À l’ère de Doom 3 et après, Carmack en est venu à privilégier les fonctions pures et à minimiser l’état mutable, même en C et en C++ — non par mode, mais parce qu’un code sans état caché est un code dont on peut prédire le comportement, ce qui signifie moins de bugs.¹⁰ C’est le même instinct que celui des fichiers .plan : rien qu’on ne puisse inspecter.

Chaîne d’influence

Ceux qui l’ont façonné

Michael Abrash est ce qui se rapproche le plus d’un mentor dans cette lignée. Les écrits d’Abrash sur le graphisme x86 — réunis plus tard dans le Graphics Programming Black Book — ont codifié la culture du comptage de cycles et de la mesure systématique que Carmack pratiquait. Les deux hommes ont ensuite travaillé ensemble chez id et, bien plus tard, chez Oculus, où Abrash est devenu scientifique en chef. (Influence directe)

La demoscene et la culture de l’optimisation en assembleur de la fin des années 1980 lui ont enseigné la conviction fondatrice : le processeur est connaissable exactement, et l’écart entre votre code et le plafond du matériel relève de votre responsabilité. (Influence formatrice)

John Romero, son associé chez id, fut le complément plutôt que le maître. Le travail de Romero sur le design et les niveaux a donné aux moteurs de Carmack quelque chose qui valait la peine d’être exécuté. Ce partenariat rappelle qu’un cœur rapide est nécessaire, pas suffisant — le moteur existe pour être joué.

Ceux qu’il a façonnés

Toute l’industrie des moteurs de jeu. La visibilité BSP, les lightmaps et la publication en open source de moteurs arrivés à maturité sont devenues des pratiques de référence. Toute une génération de programmeurs de moteurs a appris le rendu 3D en lisant le code source d’id Tech que Carmack a choisi de publier.

Le matériel graphique 3D grand public. Le chemin OpenGL de Quake fut l’un des premiers arguments commerciaux en faveur de la carte accélératrice 3D, contribuant à faire entrer le GPU dans le PC grand public.

La réalité virtuelle moderne. Le timewarp et le budget de latence implacable font désormais partie du vocabulaire standard de tout pipeline VR. La cible de 20 millisecondes que Carmack poursuivait est la raison pour laquelle les casques d’aujourd’hui ne rendent pas les gens malades.

Le fil conducteur

Andrej Karpathy reconstruit les réseaux de neurones à partir de zéro parce que la compréhension n’est pas transférable — il faut la dériver soi-même. Carmack dérive ses moteurs de rendu de la même façon : non pas à partir d’un framework, mais à partir du matériel et du problème. Et là où Linus Torvalds prise le « bon goût » — le cas particulier qui se dissout dans le cas général —, Carmack prise la boucle interne qui accomplit le moins de travail que la physique autorise. Les deux sont la même conviction habillée différemment : la bonne structure n’est pas une décoration posée sur le problème ; elle est le problème, correctement vu. (Pont de la série)

Ce que j’en retiens

La leçon que je garde, c’est que la performance est une forme d’honnêteté. Un système lent est généralement un système dont l’auteur n’a jamais assez compris le problème pour en trouver le cœur rapide — il a empilé des abstractions jusqu’à ce que ça marche, et « ça marche » est l’endroit où il s’est arrêté. Carmack, lui, s’arrête à la limite physique. C’est la même exigence que celle qui veut que la qualité soit la seule variable : la question n’est jamais « est-ce assez rapide pour être livré ? », mais « est-ce que je comprends vraiment pourquoi c’est aussi lent ? ».

Dans le monde où je construis aujourd’hui — les agents, les boucles d’outils, les systèmes d’IA — la tentation est l’inverse de la discipline de Carmack : empiler des frameworks, masquer la latence par davantage d’appels au modèle, ne jamais lire ce que le système fait réellement. Le geste à la Carmack consiste à profiler la boucle, à trouver la partie qui domine, à la comprendre jusqu’aux fondations, et à élaguer le reste. Cette conviction — que le goût est un système technique que l’on peut mesurer, et non une vibe que l’on affirme — est le fil conducteur qui relie une astuce de défilement EGA de 1990 à un cadre d’agent de 2026.

FAQ

Quelle est la philosophie d’ingénierie de John Carmack ?

Carmack envisage la performance comme une question morale plutôt que comme une arrière-pensée. La discipline consiste à comprendre un problème jusqu’à ses fondations, à le réduire à son cœur rapide et simple, à refuser les fonctionnalités qui ralentissent ce cœur, et à réécrire à partir de zéro quand le problème sous-jacent change. Il associe cela au travail à découvert — publier son journal d’ingénierie quotidien et diffuser en open source des moteurs arrivés à maturité — avec la conviction qu’un code que l’on peut inspecter est un code écrit plus honnêtement.²⁸

Qu’a construit John Carmack ?

Carmack a cofondé id Software en 1991 et fut le programmeur principal de Commander Keen (1990, adaptive tile refresh), Wolfenstein 3D (1992), Doom (1993, rendu fondé sur le BSP) et Quake (1996, rendu 3D logiciel véritable). Il a publié en open source les moteurs id Tech sur deux décennies, a occupé le poste de CTO d’Oculus VR où il a piloté le travail sur la latence du mouvement au photon, et a plus tard fondé l’entreprise d’IA Keen Technologies.⁵⁶⁷⁹

Qu’est-ce que l’adaptive tile refresh ?

C’est la technique que Carmack a conçue en 1990 pour obtenir un défilement latéral fluide sur le matériel EGA du PC IBM, autrement trop lent parce qu’il redessinait l’écran entier à chaque image. L’adaptive tile refresh fait glisser l’écran déjà dessiné en s’appuyant sur des fonctionnalités du matériel EGA et ne repeint que les tuiles nouvellement exposées sur les bords, réduisant considérablement le travail par image. Elle a rendu Commander Keen possible et a établi le geste signature de Carmack : résoudre le goulet d’étranglement au niveau du matériel.⁴

Pourquoi Carmack a-t-il publié ses fichiers .plan et ouvert le code de ses moteurs ?

Les fichiers .plan étaient un journal d’ingénierie quotidien, à l’origine lisible via le protocole finger, qui documentait le développement d’id quasiment en temps réel.² Carmack a ensuite publié en open source chaque génération d’id Tech une fois sa suivante sortie, faisant valoir que diffuser l’ancien code aide les développeurs plus récents à apprendre comment les jeux sont réellement construits et qu’un logiciel libre de valeur « ajoute de la richesse au monde ».⁸ Ces deux pratiques reflètent le même principe que son code : aucun état caché, rien qu’on ne puisse inspecter.

Sources