Profilage CPU et GPU des frames : identifier le travail limitant

Partir d'une question reproductible

Un faible nombre d'images par seconde est une observation, pas un diagnostic. Choisissez une scène et une action du joueur qui reproduisent le problème, puis fixez l'objectif de performance. Un combat avec beaucoup de personnages et l'ouverture d'un inventaire peuvent avoir des causes différentes, même si les deux paraissent lents. Conservez leurs captures séparément, afin qu'une moyenne unique ne masque pas deux problèmes sans rapport.

Lire des timelines qui se chevauchent

La simulation CPU, la soumission du rendu et l'exécution GPU peuvent se chevaucher. Le module Highlights d'Unity compare donc séparément le temps actif du CPU et le temps GPU au budget de frame cible. Son calcul du temps actif exclut certains marqueurs d'attente précis. [1] Examinez la timeline environnante avant d'interpréter une longue attente : le thread peut attendre une autre étape ou l'ordonnancement de la présentation. Le nom d'un timer ne suffit pas à établir qu'il mesure du calcul utile.

Raisonner sur un budget de frame

Pour un objectif de 60 images par seconde pris à titre d'illustration, le budget est d'environ 16,67 ms. Supposons qu'une frame représentative comporte 10 ms de travail CPU et 14 ms de travail GPU. Additionner ces valeurs pour conclure à une frame de 24 ms revient à ignorer le chevauchement possible. Ces mesures fictives ne garantissent pas non plus un intervalle de présentation de 14 ms : les dépendances, la synchronisation et la cadence de présentation (pacing) restent déterminantes.

Supposons maintenant qu'une baisse de la résolution de rendu réduise le temps GPU alors que le travail CPU reste comparable. C'est un indice pour examiner le travail lié aux pixels, pas la preuve qu'un shader précis en est responsable. Comparez les passes une à une avant de choisir une optimisation.

Réaliser une comparaison contrôlée

Utilisez un build sur un matériel cible représentatif. Notez la version du moteur, l'API graphique, la résolution, les réglages de qualité et les conditions d'alimentation. Répétez le même parcours de caméra, y compris le chargement des assets et les effets que les joueurs rencontrent réellement. Séparez les captures de première utilisation de celles en régime stable, après préchauffage.

Modifiez une seule variable pertinente, effectuez plusieurs exécutions et examinez la distribution des temps de frame, y compris les valeurs aberrantes lentes. Corrélez les pics avec les tâches CPU, les passes GPU, les allocations et les événements de chargement. Conservez la capture et la configuration exacte, afin qu'un autre développeur puisse reproduire la comparaison. Indiquez l'intervalle observé et la charge de travail, plutôt que de présenter une seule frame favorable comme une accélération générale.

Tenir compte des limites de la mesure

L'instrumentation modifie la charge de travail. Le Frame Timing Manager d'Unity est volontairement plus restreint qu'un profileur généraliste et conçu pour avoir un surcoût plus faible, mais ses mesures présentent malgré tout des limitations selon la plateforme. [2] Vérifiez que le compteur choisi est pris en charge et que ses valeurs sont valides.

Après une modification, contrôlez le rendu visuel et le gameplay en plus des temps. Une passe plus courte peut déplacer le goulot d'étranglement ailleurs. Suivez séparément la cadence des frames et la réactivité aux entrées : un graphe de débit régulier n'établit pas à lui seul une faible latence de bout en bout.

Sources

[1] Highlights Profiler module reference — Unity Technologies.

[2] Detecting performance bottlenecks with Unity Frame Timing Manager — Anton Kruglyakov, Unity Technologies.