Profilage dans Unity 2021 LTS : Quoi, quand et comment

Développer une expertise avec la suite d'outils de profilage d'Unity est l'une des compétences les plus utiles que vous pouvez ajouter à votre boîte à outils de développement de jeux. Un profilage approfondi peut considérablement améliorer les performances de votre jeu. Nous voulons donc vous aider à démarrer avec des conseils clés tirés de notre nouveau livre électronique, Ultimate guide to profiling Unity games (Guide ultime pour le profilage des jeux Unity).

Tous les créateurs de jeux savent qu'une performance fluide est essentielle pour créer des expériences de jeu immersives - et pour y parvenir, vous devez profiler votre jeu. Vous devez non seulement savoir quels outils utiliser et comment, mais aussi quand les utiliser.

Notre guide de plus de 70 pages sur le profilage avancé, tout juste sorti de presse, a été créé en collaboration avec des experts internes et externes. Il rassemble des conseils et des connaissances sur la manière de profiler une application dans Unity et d'identifier les goulets d'étranglement en matière de performances, entre autres bonnes pratiques.

Voyons quelques conseils utiles tirés de l'e-book.

Le profilage s'apparente à un travail de détective, permettant de percer les mystères qui expliquent pourquoi les performances de votre application sont insuffisantes ou pourquoi le code alloue trop de mémoire.

Les outils de profilage vous aident à comprendre ce qui se passe "sous le capot" de votre projet Unity. Mais n'attendez pas que des problèmes de performance importants commencent à se manifester pour puiser dans votre boîte à outils de détective.

Les meilleurs résultats du profilage sont obtenus lorsque vous planifiez dès le début du cycle de développement de votre projet, plutôt que juste avant de livrer votre jeu. Il s'agit d'un processus continu, proactif et itératif. En établissant des profils tôt et souvent, vous et votre équipe pouvez comprendre et établir une "signature de performance" pour le projet. Si les performances chutent, par exemple, vous serez en mesure de repérer facilement les problèmes et d'y remédier rapidement.

Vous pouvez également effectuer des comparaisons de performances avant et après en plus petites quantités en utilisant une simple procédure en trois points : Tout d'abord, établissez une base de référence en établissant un profil avant de procéder à des changements majeurs. Ensuite, il faut établir un profil pendant le développement pour suivre les performances et la budgétisation et, enfin, établir un profil après la mise en œuvre des changements pour vérifier s'ils ont eu l'effet escompté.

Il est préférable de profiler une version de développement de votre jeu, plutôt que de le profiler à partir de l'éditeur Unity. Il y a deux raisons à cela :

Les données relatives aux performances et à l'utilisation de la mémoire des versions de développement autonomes sont beaucoup plus précises que les résultats du profilage d'un jeu dans l'éditeur. Cela est dû au fait que la fenêtre du profileur enregistre les données de l'éditeur lui-même, ce qui peut fausser les résultats.

Certains problèmes de performance n'apparaissent que lorsque le jeu tourne sur le matériel ou le système d'exploitation cible, ce qui vous échappera si vous établissez le profil exclusivement dans l'éditeur.

Les résultats de profilage les plus précis sont obtenus en exécutant et en profilant des constructions sur des dispositifs cibles et en utilisant des outils spécifiques à la plate-forme pour approfondir les caractéristiques matérielles de chaque plate-forme ciblée.

Unity est livré avec une gamme d'outils de profilage gratuits et puissants pour analyser et optimiser votre code, à la fois dans l'éditeur et sur le matériel, mais il existe également plusieurs outils de profilage natifs conçus pour chaque plateforme, tels que ceux disponibles chez Arm, Apple, Sony et Microsoft. L'utilisation d'une combinaison permet d'obtenir une vue plus globale des performances des applications sur tous les appareils cibles.

Pour un aperçu complet des outils disponibles, consultez la page des outils de profilage ici.

Les outils de profilage d ' Unity sont disponibles dans l'éditeur et le gestionnaire de paquets. Chaque outil est spécialisé dans le profilage de différentes parties du processus (un flux de travail holistique "somme de toutes les parties"). Familiarisez-vous avec les profileurs suivants afin qu'ils fassent partie de votre boîte à outils quotidienne :

• C'est par le Unity Profiler que vous devez commencer et passer le plus clair de votre temps. Il mesure les performances de l'éditeur Unity, de votre application en mode lecture et se connecte à l'appareil qui exécute votre application en mode développement. Le Unity Profiler recueille et affiche des données sur les performances de votre application, telles que la quantité de temps CPU utilisée pour différentes tâches, de l'audio et de la physique au rendu et à l'animation. Pour commencer, consultez ce cours sur le profilage.
• Le profileur de mémoire fournit une analyse approfondie des performances de la mémoire afin d'identifier les endroits où vous pouvez réduire l'utilisation de la mémoire dans certaines parties de votre projet et de l'éditeur. Le Memory Profiler est actuellement en avant-première mais devrait être vérifié dans Unity 2022 LTS.
• L'analyseur de profil regroupe et visualise les données des images et des marqueurs d'un ensemble d'images Unity Profiler pour vous aider à examiner leur comportement sur plusieurs images (en complément de l'analyse d'une seule image déjà disponible dans l'analyseur Unity Profiler). Il vous permet également de comparer deux ensembles de données de profilage afin de déterminer l'impact de vos modifications sur les performances de l'application.
• Le débogueur d'images vous permet d'arrêter la lecture d'un jeu en cours sur une image particulière, puis de visualiser les appels de dessin individuels utilisés pour rendre cette image. Outre la liste des appels de dessin, le débogueur vous permet de les parcourir un par un, afin que vous puissiez voir comment la scène est construite à partir de ses éléments graphiques.
• Le paquet Profiling Core fournit des API permettant d'ajouter des informations contextuelles aux captures de Unity Profiler.

Steve McGreal, ingénieur Unity senior et co-auteur de notre livre électronique sur le profilage avancé, a élaboré la vue d'ensemble suivante. N'hésitez pas à l'utiliser comme fiche de référence.

Bien que l'explication détaillée de l'utilisation des outils se trouve dans le livre électronique, cet organigramme illustre trois observations principales à prendre en compte pour votre flux de travail :

Téléchargez la version PDF imprimable de ce tableau ici. Pour en savoir plus, consultez les ressources liées à l'utilisation de chacun des outils de profilage à la fin de cet article.

Les joueurs mesurent souvent les performances à l'aide du taux de rafraîchissement, ou nombre d'images par seconde. Cependant, il est recommandé d'utiliser la durée de la trame en millisecondes.

Par exemple, vous pouvez avoir un jeu qui rend 59 images en 0,75 seconde au moment de l'exécution, l'image suivante prenant 0,25 seconde à rendre. Le taux de rafraîchissement moyen de 60 images par seconde semble satisfaisant, mais en réalité, les joueurs remarqueront un effet de bégaiement car la dernière image prend un quart de seconde à être rendue.

Lors du profilage et de l'optimisation de votre jeu, efforcez-vous de respecter un budget temps spécifique par image, car cela est essentiel pour créer une expérience fluide et cohérente pour le joueur. Chaque image disposera d'un budget temps basé sur le nombre d'images par seconde que vous souhaitez atteindre. Une application ciblant 30 fps devrait toujours prendre moins de 33,33 ms par image (1000 ms / 30 fps). De même, un objectif de 60 fps laisse 16,66 ms par image.

La plupart des jeux modernes sur console et sur PC visent à atteindre un taux de rafraîchissement de 60 images par seconde ou plus. Dans les jeux VR, il est en fait plus important d'éviter une fréquence d'images régulièrement élevée, car elle peut provoquer des nausées ou des malaises chez les joueurs. Les jeux mobiles peuvent également nécessiter des budgets d'images restrictifs pour éviter la surchauffe des appareils sur lesquels ils tournent. Par exemple, un jeu mobile peut viser 30 fps avec un budget d'images de seulement 21-22 ms afin que le CPU et le GPU refroidissent entre les images.

Utilisez le Unity Profiler pour vérifier si vous êtes dans les limites de votre budget. Vous trouverez ci-dessous une image d'une capture de profilage d'un jeu mobile Unity avec un profilage et une optimisation continus. Le jeu vise un taux d'images par seconde de 60 sur les téléphones mobiles de haute qualité, et de 30 sur les téléphones de qualité moyenne/faible, comme celui de cette capture :

Il s'agit d'un jeu qui fonctionne confortablement dans le budget d'images de ~22 ms requis pour 30 fps sans surchauffe. Notez que WaitForTargetfps remplit le temps du thread principal, jusqu'à VSync et les temps d'inactivité en gris dans le thread de rendu et le thread de travail. En outre, observez l'intervalle VBlank en regardant les heures de fin de Gfx. Présenter une image après l'autre établit une échelle de temps dans la zone de la ligne de temps ou sur la règle du temps en haut pour mesurer d'une image à l'autre.

Si vous respectez le budget de cadre, y compris les ajustements apportés au budget pour tenir compte de l'utilisation de la batterie et de l'étranglement thermique, vous avez terminé avec succès le profilage des performances jusqu'à la prochaine fois - félicitations ! Examinez maintenant l'utilisation de la mémoire pour voir si elle est également dans les limites du budget.

Cela dit, si votre jeu n'entre pas dans le cadre du budget, l'étape suivante consiste à détecter le goulot d'étranglement. En d'autres termes, il s'agit de déterminer si c'est le processeur ou le processeur graphique qui prend le plus de temps. S'il s'agit de l'unité centrale, déterminez quel thread est le plus occupé - c'est là que se trouve le goulot d'étranglement.

L'objectif du profilage est d'identifier les goulets d'étranglement afin de les optimiser. Si vous vous fiez à vos suppositions, vous risquez d'optimiser des parties du jeu qui ne sont pas des goulets d'étranglement, ce qui n'apportera que peu ou pas d'amélioration. Certaines "optimisations" peuvent même détériorer les performances globales de votre jeu.

Le fil d'exécution principal est l'endroit où toute la logique du jeu et les scripts effectuent leur travail par défaut ; c'est là que les fonctions et les systèmes tels que la physique, l'animation, l'interface utilisateur et le rendu prennent place.

La capture d'écran ci-dessous donne un exemple de ce à quoi ressemble un projet lié au fil principal :

Bien que les threads de rendu et de travail ressemblent à l'exemple précédent qui est dans le budget de l'image, le thread principal ici est clairement occupé à travailler pendant toute l'image. Même si l'on tient compte de la petite quantité d'overhead du Profiler à la fin de l'image, le thread principal est occupé pendant plus de 45 ms, ce qui signifie que ce projet atteint des taux d'images inférieurs à 22 fps. Il n'y a pas de marqueur montrant que le thread principal attend paresseusement la VSync ; il est occupé pendant toute la durée de l'image.

L'étape suivante de l'enquête consiste à identifier les parties du cadre qui prennent le plus de temps et à mettre le doigt sur les causes sous-jacentes. Utilisez le Unity Profiler et le Profile Analyzer pour évaluer et traiter les coûts les plus importants. Les goulets d'étranglement les plus courants sont souvent liés à la physique, aux scripts non optimisés, au collecteur de déchets (GC), à l'animation, aux caméras et à l'interface utilisateur. Si la source du problème n'est pas immédiatement évidente, essayez d'activer le Deep Profiling, les piles d'appels ou d'utiliser un profileur de processeur natif.

Dans notre guide de 95 pages sur l 'optimisation des performances, nous avons dressé une liste des pièges les plus courants que vous pouvez rencontrer et auxquels vous pouvez vous préparer.

Au cours du processus de rendu, le fil d'exécution principal examine la scène et effectue des opérations de Camera culling, de tri de profondeur et de mise en lots des appels de dessin, afin de compiler une liste d'éléments à rendre. Cette liste est transmise au thread de rendu, qui la traduit à partir de la représentation interne d'Unity, indépendante de la plate-forme, en appels à l'API graphique nécessaires pour instruire le GPU sur une plate-forme particulière.

Dans la capture du Profiler présentée ci-dessous, vous pouvez voir que le thread principal attend le thread de rendu avant de commencer le rendu de l'image actuelle, comme l'indique le marqueur Gfx.WaitForPresentOnGfxThread.

Le thread de rendu soumet toujours les commandes d'appel de dessin de l'image précédente, mais n'est pas prêt à accepter de nouveaux appels de dessin de la part du thread principal. Le thread de rendu passe du temps dans Camera.Render.

Le module Rendering Profiler donne un aperçu du nombre de lots d'appels de dessin et d'appels SetPass pour chaque image. Le meilleur outil pour déterminer quel appel de dessin transmet les problèmes de votre thread de rendu au GPU est le débogueur de trames. Les causes courantes des goulots d'étranglement des threads de rendu comprennent un mauvais regroupement des appels de dessin, la présence de plusieurs caméras actives dans la scène et un filtrage inefficace des caméras.

Le fait d'être lié à des threads de l'unité centrale, en dehors du thread principal ou du thread de rendu, n'est pas un problème très courant, mais il peut se poser dans les projets qui utilisent la pile technologique orientée données (DOTS) - en particulier si le travail est déplacé du thread principal vers des threads de travail à l'aide du système de travail C#.

Voici une capture du mode Play in-Editor qui met en évidence un projet DOTS exécutant une simulation de fluide de particules sur l'unité centrale :

Comme vous pouvez le voir, les threads de travail sont très chargés en tâches. Cela suggère qu'une grande partie du travail est déplacée hors du fil principal. Notez que le temps de trame de 48,14 ms et le marqueur gris WaitForJobGroupID de 35,57 ms sur le thread principal indiquent que les threads de travail effectuent plus de travail qu'il n'est possible de le faire de manière réaliste dans une seule trame sur cette unité centrale.

WaitForJobGroupID montre que le thread principal a programmé des tâches à exécuter de manière asynchrone sur des threads de travail, mais qu'il a besoin des résultats de ces tâches avant que les threads de travail n'aient fini de les exécuter. Les marqueurs bleus du Profiler sous WaitForJobGroupID représentent le thread principal qui exécute des tâches pendant qu'il attend, dans le but de terminer les tâches plus rapidement.

Les tâches de votre projet peuvent ne pas être aussi parallélisées que dans cet exemple. Il se peut que vous n'ayez qu'un long travail exécuté dans un seul thread de travail. Cela ne pose pas de problème, tant que le délai entre le moment où la tâche est programmée et celui où elle doit être effectuée est suffisamment long pour que la tâche puisse être exécutée. Si ce n'est pas le cas, vous verrez le thread principal se bloquer, attendant que le travail soit terminé, comme dans la capture d'écran ci-dessus.

Vous pouvez utiliser la fonction Événements de flux dans la vue chronologique du module Profiler d'utilisation du processeur pour voir quand les tâches sont planifiées et quand leurs résultats sont attendus par le thread principal. Pour plus d'informations sur l'écriture d'un code DOTS efficace, consultez nos meilleures pratiques DOTS.

Vous remarquerez peut-être que votre thread principal passe du temps à attendre le thread de rendu (comme le montrent les marqueurs du Profiler tels que Gfx.WaitForPresentOnGfxThread). Mais en même temps, votre thread de rendu peut afficher des marqueurs tels que Gfx.PresentFrame ou <GraphicsAPIName>.WaitForLastPresent. Cela signifie que votre application est liée au GPU. Vous devrez donc concentrer vos efforts d'optimisation sur les goulets d'étranglement du GPU afin d'améliorer les performances globales.

La capture suivante a été réalisée sur un Samsung Galaxy S7 utilisant l'API graphique Vulkan. Bien qu'une partie du temps passé dans Gfx.PresentFrame dans cet exemple puisse être liée à l'attente de VSync, la longueur extrême de ce marqueur Profiler prouve que la majorité du temps est passé à attendre que le GPU ait fini de rendre l'image précédente.

Si votre application semble être liée au GPU, vous pouvez utiliser le débogueur de trames pour obtenir une compréhension rapide des lots d'appels de dessin envoyés au GPU. Cependant, cet outil ne peut pas fournir d'informations spécifiques sur la synchronisation du GPU. Elle ne fait que révéler la façon dont la scène est construite.

Pour étudier attentivement la cause des goulets d'étranglement du GPU, examinez une capture du GPU à partir d'un profileur de GPU approprié. L'outil que vous utilisez dépend du matériel cible et de l'API graphique choisie.

Les causes les plus courantes de mauvaises performances du GPU sont les shaders inefficaces, les effets de post-traitement coûteux, le surdessin transparent (souvent dû aux effets de particules ou à l'interface utilisateur), les textures volumineuses ou non compressées, les maillages avec un nombre de polygones excessivement élevé et les résolutions de sortie excessives (c'est-à-dire le rendu à 4K).

L'optimisation des performances et le profilage sont des sujets d'envergure. Si vous souhaitez obtenir plus d'informations, consultez notre livre électronique récemment publié, Guide ultime pour le profilage des jeux Unity. Vous obtiendrez plus de 80 pages de conseils et d'astuces créés en partenariat avec de nombreux experts, y compris ceux de notre équipe de services d'assistance intégrés.

En fait, certains de ces experts ont également participé à l'élaboration de notre guide de 100 pages sur l'optimisation des performances pour les mobiles et les PC/consoles, qui regorge de conseils pratiques sur la manière d'éviter de créer des goulets d'étranglement. Pour obtenir des ressources supplémentaires, consultez notre série d'articles de blog précédents sur la physique, l'interface utilisateur et les paramètres audio, les graphismes et les ressources sur mobile ou console, ainsi que la mémoire et l'architecture du code.

Si vous souhaitez savoir comment votre équipe peut avoir un accès direct aux ingénieurs, aux conseils d'experts et à l'orientation des projets, consultez les plans de réussite d'Unity ici.

Suivez notre nouveau webinaire " Ultimate profiling tips" avec des experts de SYBO Games, Arm et Unity pour savoir comment identifier les problèmes de performance courants dans les jeux mobiles, en utilisant les outils de profilage Unity et natifs.

Ce webinaire couvrira les points suivants

• Considérations clés pour créer un code allégé et performant et optimiser l'utilisation de la mémoire pour des performances fluides sur les appareils bas et haut de gamme
• Gestion du contrôle thermique pour préserver les précieux cycles de la batterie des appareils mobiles
• Les stratégies de profilage à tous les stades du développement d'un jeu et la manière de les tester pour construire une méthodologie solide.
• Perspectives d'experts sur le profilage des utilisateurs d'Android

Participez à notre table ronde et aux questions-réponses en direct le 14 juin 2022 à 11h00 ET / 8h00 PT.

Nous voulons vous aider à tirer le meilleur parti de vos applications Unity. Si vous souhaitez que nous approfondissions un sujet lié à l'optimisation, n'hésitez pas à nous en faire part dans les forums. Nous aimerions également connaître les formats que vous préférez afin d'améliorer nos livres électroniques et autres matériels d'apprentissage.