16,7 millisecondes. À 60 images par seconde, c’est le budget complet pour lire la manette, simuler le monde, préparer les commandes graphiques et afficher. La moyenne ne suffit pas : une seule image de 80 ms produit un accroc visible même si les suivantes sont rapides.

Le CPU met à jour logique, animation, physique et appels de rendu. Le GPU transforme les sommets, rasterise les triangles, exécute les shaders de pixels et écrit l’image. Les deux travaillent en pipeline. Si le CPU prépare trop lentement, le GPU attend; si les shaders sont trop lourds, la file de commandes s’accumule.

Découper le budget avant de l’épuiser

Un budget approximatif pourrait être :

1. entrées et logique : 2 ms;
2. animation et IA : 3 ms;
3. physique : 2 ms;
4. préparation du rendu : 3 ms;
5. GPU : 6 ms;
6. marge : 0,7 ms.

Ces valeurs ne s’additionnent pas toujours simplement parce que CPU et GPU se chevauchent, mais elles donnent des propriétaires. Un profileur capture chaque image, montre les appels et repère le pic. Optimiser une fonction appelée une fois ne sert pas si mille allocations de petites particules provoquent la pause.

Le GPU gagne en regroupant les objets qui partagent état et texture. Chaque changement de shader ou appel de rendu a un coût CPU. Les niveaux de détail réduisent géométrie et texture avec la distance. L’occlusion évite d’envoyer ce qui est caché. Ces techniques échangent fidélité, mémoire et calcul.

Les pannes de performance sont des pannes fonctionnelles

Charger une texture depuis le disque au moment où elle devient visible peut bloquer. Le streaming prédit les besoins, utilise des files asynchrones et garde une limite mémoire. Si la mémoire est pleine, il choisit quoi évincer. Une mauvaise politique produit du thrashing : la même ressource sort et revient sans cesse.

Le réseau ajoute un autre budget. Le client prédit le mouvement local, interpole les autres joueurs et réconcilie avec le serveur. Une trame perdue ne doit pas suspendre l’image. La simulation et le rendu continuent avec les dernières informations plausibles.

Les consoles ont un matériel fixe, ce qui aide l’optimisation, mais les scènes réelles varient. Je testerais combat chargé, sauvegarde longue, changement de zone et plusieurs heures de jeu. Les percentiles et le pire cadre racontent davantage que les FPS moyens dans une salle vide.

Prévenir la régression dans le build

Je conserverais une scène de référence et un parcours automatisé qui capture temps CPU, GPU, mémoire et nombre d’appels de rendu. Le build compare aux budgets et signale une hausse avant la fusion. Le matériel et les pilotes restent identifiés pour éviter de comparer deux machines différentes. Un seuil trop rigide crée du bruit; une tendance sur plusieurs commits montre mieux la dérive. Les captures de profileur sont attachées au changement responsable. Cette boucle transforme la performance en caractéristique testée et empêche que cent petites features consomment chacune « seulement » 0,2 milliseconde jusqu’à dépasser le budget.

Dans une application d’entreprise, l’échelle change mais la discipline reste. Définir un budget par interaction, profiler le chemin complet et conserver une marge évite de découvrir la performance après l’architecture. Pour un jeu, 16,7 ms force cette honnêteté à chaque image.