J’aime le jeu vidéo pour une raison très technique : il doit répondre vite. Une image magnifique calculée dix secondes trop tard ne sert plus à rien, parce que le joueur a déjà bougé la caméra et senti l’attente.

Une image traverse plusieurs producteurs. Le CPU lit les commandes, avance la logique et la physique, anime les objets, détermine ce qui est visible et prépare les commandes graphiques. Le pilote remplit une file. Le GPU transforme les sommets, rasterise les triangles et exécute les shaders sur beaucoup de pixels en parallèle. L’écran présente enfin un tampon terminé.

entrée → simulation CPU → préparation scène → commandes GPU
       → vertex/pixel/compute shaders → tampon → affichage

À 60 images par seconde, le budget est 16,7 ms. Si le CPU prend 12 ms et le GPU 8 ms en parallèle, l’image peut approcher 12 ms plus synchronisation, pas nécessairement 20. Si le CPU attend une lecture du résultat GPU à chaque image, les deux se sérialisent et le parallélisme disparaît. Les profileurs doivent donc montrer temps CPU, temps GPU, attentes et files séparément.

Le GPU convient à des opérations similaires sur de grands tableaux : pixels, sommets, matrices. CUDA et d’autres outils ont ouvert cette organisation au calcul scientifique et à l’apprentissage profond. L’échange va dans les deux directions : les centres de données demandent mémoire, précision et interconnexion; le jeu réutilise accélérateurs d’IA, débruitage et reconstruction.

Faire entrer le jeu dans une enveloppe

Le Steam Deck, arrivé cette année, combine CPU et GPU dans une enveloppe de puissance portable. La batterie, la chaleur et le bruit deviennent des contraintes de produit. Monter la fréquence donne plus d’images jusqu’à ce que la puce atteigne sa limite thermique ou énergétique, puis réduise sa cadence.

Une estimation simple : une batterie de 40 Wh alimentant un appareil à 20 W donne environ deux heures idéales (40/20). À 10 W, elle approche quatre heures. L’écran, le stockage et les pertes consomment leur part; l’autonomie réelle est moindre. Limiter à 40 FPS, réduire la résolution ou la qualité peut offrir un meilleur équilibre que viser 60 instables.

Le moteur dispose de plusieurs leviers :

1. éliminer objets hors caméra et niveaux de détail invisibles;
2. distribuer animation, physique et préparation en jobs CPU;
3. regrouper les commandes pour réduire les changements GPU;
4. ajuster dynamiquement la résolution selon le temps GPU;
5. reconstruire une image plus grande avec historique et vecteurs de mouvement;
6. charger textures et géométrie avant qu’elles entrent dans le champ;
7. plafonner la fréquence pour stabiliser consommation et temps d’image.

La moyenne de FPS ne suffit pas. Un accroc de 100 ms au chargement se sent même au milieu de secondes rapides. Je regarde les percentiles du temps d’image et capture la scène exacte. Une texture absente, un shader compilé à la première utilisation ou une page lue du SSD peut être la vraie cause.

La compatibilité impose un chemin de repli. Un pilote ou shader peut échouer sur une famille de GPU; le moteur détecte les capacités, garde un mode plus simple et journalise matériel/version. Une corruption d’asset ou un manque de mémoire ne devrait pas faire perdre la sauvegarde du joueur. Les tâches réseau et disque ont des timeouts et ne bloquent pas la boucle d’affichage.

Une approximation crédible dans une poursuite n’est pas acceptable dans un calcul financier, mais la méthode se transpose : budget par étape, parallélisme sans synchronisation inutile, qualité dégradée explicitement et mesure de la pire latence. Le jeu vidéo n’est pas le parent unique de toutes les innovations; c’est un laboratoire qui doit rendre leurs compromis jouables avant la prochaine image.