Découvrez ces conseils utiles sur le profilage avancé

En juin, nous avons organisé un webinaire avec des experts d'Arm, de l'équipe Unity Studio Productions et de SYBO Games, le créateur de Subway Surfers. La table ronde qui en a résulté s'est concentrée sur des conseils et des stratégies de profilage pour les jeux mobiles, les implications commerciales d'une mauvaise performance et comment SYBO a lancé un jeu mobile à succès avec 3 milliards de téléchargements à ce jour.

Plongeons dans certaines des questions de suivi que nous n'avons pas eu le temps de couvrir lors du webinaire. Vous pouvez également regarder l'enregistrement complet.

Nous entendons beaucoup parler du Profiler Unity en relation avec le profilage CPU, mais pas autant du Profile Analyzer (disponible en tant que package Unity). Y a-t-il des plans pour l'améliorer ou l'intégrer dans l'ensemble d'outils Profiler de base ?

Il n'y a pas de plans immédiats pour intégrer le Profile Analyzer dans l'éditeur de base, mais cela pourrait changer à mesure que nos outils de profilage évoluent.

Unity a-t-il des plans pour ajouter une option pour que le module GPU Usage Profiler apparaisse en pourcentages comme il le fait en millisecondes ?

C'est une excellente idée, et bien que nous ne puissions pas dire oui ou non au moment de la publication de ce blog, c'est une demande qui a été partagée avec nos équipes R&D pour une éventuelle considération future.

Avez-vous des plans pour traiter les erreurs "Application Not Responding" (ANR) qui sont signalées par le Google Play store et ne contiennent pas de trace de pile ?

Bien que nous n'ayons pas de plans spécifiques pour suivre les ANR sans trace de pile pour le moment, nous le considérerons pour la feuille de route future.

Comment puis-je partager mes retours pour aider à influencer le développement futur des outils de profilage de Unity ?

Vous pouvez suivre les fonctionnalités à venir et partager vos retours via notre tableau de produits et forums. Nous sommes également en train de mener une enquête pour en savoir plus sur l'expérience de nos clients avec les outils de profilage. Si vous avez utilisé des outils de profilage auparavant (soit quotidiennement, soit juste une fois) ou si vous travaillez sur un projet nécessitant une optimisation, nous aimerions avoir votre avis. L'enquête est conçue pour ne pas prendre plus de 5 à 10 minutes à compléter.

En participant, vous aurez également la chance de vous inscrire à un entretien de suivi pour partager plus de retours directement avec l'équipe de développement, y compris l'opportunité de discuter des prototypes potentiels de nouvelles fonctionnalités.

Y a-t-il une bonne règle pour déterminer ce qui compte comme un appareil d'entrée de gamme viable à cibler ?

Une règle générale que nous entendons de nombreux développeurs de jeux Unity est de cibler des appareils âgés de cinq ans au moment de la sortie de votre jeu, car cela aide à garantir la plus grande base d'utilisateurs. Mais nous voyons également des équipes réduire leur portée de date de sortie aux appareils âgés de seulement trois ans si elles visent une qualité graphique supérieure. Une application 3D visuellement complexe, par exemple, aura des exigences d'appareil plus élevées qu'une simple application 2D. Cette approche permet un "min spec" plus élevé, mais réduit la taille de la base d'installation initiale. C'est essentiellement une décision commerciale : Cela coûtera-t-il plus cher de développer et de prendre en charge d'anciens appareils que ce que votre jeu gagnera en fonctionnant sur eux ?

Parfois, les exigences techniques de votre jeu dicteront vos spécifications cibles minimales. Donc, si votre jeu utilise de grandes quantités de mémoire de texture même après optimisation, mais que vous ne pouvez absolument pas réduire la qualité ou la résolution, cela exclut probablement l'exécution sur des téléphones avec une mémoire insuffisante. Si votre solution de rendu nécessite des shaders de calcul, cela exclut probablement les appareils avec des pilotes qui ne peuvent pas prendre en charge OpenGL ES 3.1, Metal ou Vulkan.

Il est judicieux de consulter les données du marché pour votre public cible prioritaire. Par exemple, les spécifications des appareils mobiles peuvent varier considérablement entre les pays et les régions. N'oubliez pas de définir certains "budgets" cibles afin que les objectifs de référence pour ce qui est acceptable soient fixés avant de choisir des appareils d'entrée de gamme pour les tests.

Pour les jeux de service en direct qui fonctionneront pendant des années, vous devrez surveiller leur compatibilité en continu et vous adapter au fil du temps en fonction de votre base d'utilisateurs réelle et des appareils actuels sur le marché.

Est-il suffisant de tester les performances exclusivement sur des appareils d'entrée de gamme pour garantir que le jeu fonctionnera également sans problème sur des appareils haut de gamme ?

Cela pourrait l'être, si vous avez une charge de travail uniforme sur tous les appareils. Cependant, vous devez toujours tenir compte des variations entre le matériel de différents fournisseurs et/ou des versions de pilotes.

Il est courant que les jeux graphiquement riches aient des niveaux de fidélité graphique - plus le niveau visuel est élevé, plus les ressources requises sur les appareils capables sont importantes. Cette sélection de niveau pourrait être automatique, mais de plus en plus, les utilisateurs eux-mêmes peuvent contrôler le choix via un menu de paramètres graphiques. Pour ce style de développement, vous devrez tester au moins un appareil cible « min spec » par fonctionnalité/niveau de charge de travail que votre jeu prend en charge.

Si votre jeu détecte les capacités de l'appareil sur lequel il s'exécute et adapte la sortie graphique en conséquence, il pourrait fonctionner différemment sur des appareils haut de gamme. Assurez-vous donc de tester sur une gamme d'appareils avec les différents niveaux de qualité pour lesquels vous avez programmé le titre.

Remarque : Dans cette section, nous avons spécifié si l'expert répondant est de Arm ou Unity.

Avez-vous des conseils pour détecter la plage de puissance d'un appareil afin de prendre en charge les paramètres de qualité automatiques, en particulier pour mobile ?

Arm : Nous voyons généralement les développeurs effectuer un regroupement grossier des capacités basé sur les modèles de CPU et de GPU, ainsi que sur le nombre de cœurs de shader GPU. Ce n'est jamais parfait, mais c'est « à peu près juste ». Beaucoup de studios collectent des analyses en direct à partir des appareils déployés, afin de pouvoir compléter le regroupement automatisé avec des options spécifiques à l'appareil pour contourner les problèmes ponctuels où le regroupement des capacités n'est pas assez précis.

En rapport avec la question précédente, pour un contenu riche en graphismes, nous constatons une tendance sur mobile vers des menus de paramètres où les utilisateurs peuvent choisir d'activer ou de désactiver les effets, leur permettant ainsi de faire des choix de performance qui correspondent à leurs préférences.

Unity : La mémoire de l'appareil et la résolution de l'écran sont également des facteurs importants pour choisir les paramètres de qualité. Concernant les textures, les développeurs doivent être conscients que Render Textures utilisées par les effets ou le post-traitement peuvent devenir un problème sur les appareils avec des écrans haute résolution, mais sans beaucoup de mémoire pour correspondre.

Étant donné l'éventail des configurations disponibles (CPU, GPU, SOC, mémoire, mobile, bureau, console, etc.), pouvez-vous suggérer un moyen de catégoriser les appareils pour réduire le nombre de niveaux que vous devez optimiser ?

Arm : Le nombre de niveaux pour lesquels votre équipe optimise est vraiment une décision de conception de jeu et commerciale, et devrait être basé sur l'importance de la qualité visuelle pour la proposition de valeur du jeu. Pour certains genres, cela pourrait ne pas avoir d'importance, mais pour d'autres, les utilisateurs auront de grandes attentes en matière de fidélité visuelle.

La limite de mémoire de texture diffère-t-elle entre les modèles et les marques d'appareils Android qui ont la même quantité de mémoire système totale ?

Arm : Pour une première approximation, nous nous attendrions à ce que la quantité totale de mémoire de texture soit similaire entre les fournisseurs et les générations de matériel. Il y aura de légères différences causées par la disposition de la mémoire et les restrictions d'alignement, donc ce ne sera pas exactement la même.

Est-ce l'utilisation du CPU ou du GPU qui contribue le plus à la surchauffe des appareils mobiles ?

Arm : Cela dépend entièrement du contenu. Le CPU, le GPU ou la DRAM peuvent individuellement surchauffer un appareil haut de gamme s'ils sont poussés suffisamment fort, même si vous ignorez complètement les deux autres. L'équilibre exact variera en fonction de la charge de travail que vous exécutez.

Quels conseils pouvez-vous donner pour le profilage sur des appareils qui ont un throttling thermique ? Quelle marge viseriez-vous pour éviter le throttling thermique (c'est-à-dire, viser 20 ms au lieu de 33 ms) ?

Arm : L'optimisation du temps de trame peut être trompeuse sur Android car les appareils ajusteront constamment la fréquence pour optimiser la consommation d'énergie, rendant le temps de trame une mesure incomplète en soi. De préférence, surveillez les cycles CPU et GPU par trame, ainsi que la bande passante mémoire GPU par trame, pour obtenir une valeur indépendante de la fréquence. L'objectif de cycle dont vous avez besoin dépendra de la conception du chip de chaque appareil, donc vous devrez expérimenter.

Toute optimisation aide lorsqu'il s'agit de gérer la consommation d'énergie, même si cela n'améliore pas directement le taux de trame. Par exemple, réduire les cycles CPU réduira la charge thermique même si le CPU n'est pas le chemin critique pour votre jeu.

Au-delà de cela, optimiser la bande passante mémoire est l'une des plus grandes économies que vous pouvez réaliser. Accéder à la DRAM est de plusieurs ordres de grandeur plus coûteux que d'accéder à des données locales sur puce, donc surveillez votre budget de triangle et gardez les types de données en mémoire aussi petits que possible.

Unity : Pour limiter l'impact de la fréquence d'horloge du CPU sur les métriques de performance, nous recommandons d'essayer de fonctionner à une température constante. Il existe quelques approches pour faire cela :

• Fonctionner chaud : Faites fonctionner l'appareil pendant un certain temps afin qu'il atteigne un état chaud stable avant le profilage.
• Fonctionner frais : Laissez l'appareil refroidir pendant un certain temps avant le profilage. Cette stratégie peut éliminer la confusion et l'incohérence dans les sessions de profilage en prenant des captures qui sont peu susceptibles d'être limitées thermiquement. Cependant, de telles captures représenteront toujours la meilleure performance qu'un utilisateur verra plutôt que ce qu'il pourrait réellement voir après de longues sessions de jeu. Cette stratégie peut également retarder le temps entre les exécutions de profilage en raison de la nécessité d'attendre d'abord la période de refroidissement.

Avec certains matériels, vous pouvez fixer la fréquence d'horloge pour des métriques de performance plus stables. Cependant, cela n'est pas représentatif de la plupart des appareils que vos utilisateurs utiliseront, et ne rapportera pas de performances réelles précises. Fondamentalement, c'est une technique pratique si vous utilisez une configuration d'intégration continue pour vérifier les changements de performance dans votre code au fil du temps.

Des réflexions sur Vulkan vs OpenGL ES 3 sur Android ? Vulkan est généralement plus lent en termes de performance. En même temps, de nombreux appareils manquent de support pour diverses fonctionnalités sur ES3.

Arm : Les pilotes récents et les versions de moteur ont considérablement amélioré la qualité des implémentations Vulkan disponibles ; donc pour une charge de travail équivalente, il ne devrait pas y avoir d'écart de performance entre OpenGL ES et Vulkan (s'il y en a, veuillez nous le faire savoir). Le passage à Vulkan prend de l'ampleur et nous nous attendons à voir plus de personnes choisir Vulkan par défaut au cours de l'année ou des deux prochaines années. Si vous avez des contre-exemples d'endroits où Vulkan ne fonctionne pas bien, veuillez nous contacter. Nous aimerions avoir de vos nouvelles.

Quels outils pouvons-nous utiliser pour surveiller la bande passante mémoire (RAM <-> VRAM) ?

Arm : Le profilage Streamline dans Arm Mobile Studio peut mesurer la bande passante entre les GPU Mali et la DRAM externe (ou le cache système).

Devriez-vous diviser les actifs graphiques par niveaux d'appareil ou par résolution d'appareil ?

Arm : Vous pouvez obtenir le meilleur résultat en retouchant les actifs, mais cela coûte cher à faire. Commencez par réduire la résolution et le taux de rafraîchissement, ou désactiver certains effets de post-traitement optionnels.

Quelle est la meilleure façon d'enregistrer les statistiques des métriques de performance de notre version de développement ?

Arm : Vous pouvez utiliser l'outil Performance Advisor dans Arm Mobile Studio pour capturer et exporter automatiquement les métriques de performance des GPU Mali, bien que cela comporte une mise en garde : La génération de rapports JSON nécessite une licence Professional Edition.

Unity : Le Profiler Unity peut être utilisé pour afficher des métriques de rendu courantes, telles que le nombre de sommets et de triangles dans le module de rendu. De plus, vous pouvez inclure des packages personnalisés, tels que System Metrics Mali, dans votre projet pour ajouter des métriques GPU Mali de bas niveau au Profiler Unity.

Quelles sont vos recommandations pour le profilage du code shader ?

Vous avez besoin d'un Profiler GPU pour cela. Celui que vous choisissez dépend de votre plateforme cible. Par exemple, sur les appareils iOS, le Profiler GPU d'Xcode inclut le Shader Profiler, qui décompose la performance des shaders ligne par ligne.

Arm Mobile Studio prend en charge Mali Offline Compiler, un outil d'analyse statique pour le code shader et les noyaux de calcul. Cet outil fournit des estimations de performance globales et des recommandations pour la famille de GPU Arm Mali.

Lors du profilage, la règle générale est de tester votre jeu ou application sur le(s) appareil(s) cible(s). Avec l'industrie se dirigeant vers plus de types de chipsets (Apple M1, Arm, x86 par Intel, AMD, etc.), comment les développeurs peuvent-ils profiler et identifier les problèmes sur les nombreuses configurations matérielles différentes dans un délai raisonnable ?

La prolifération des chipsets est principalement une préoccupation sur les plateformes de bureau. Il y a un nombre limité d'architectures matérielles à tester pour les jeux de console. Sur mobile, il y a la série A d'Apple pour les appareils iOS et une gamme d'architectures Arm et Qualcomm pour Android - mais sélectionner une liste gérable d'appareils mobiles représentatifs est assez simple.

Sur bureau, c'est plus compliqué car il existe une large gamme de chipsets et d'architectures disponibles, et acheter des Macs et des PC pour les tests peut être coûteux. Notre meilleur conseil est de faire ce que vous pouvez. Aucun studio n'a un temps et un budget infinis pour les tests. En général, nous ne nous attendrions pas à de grandes surprises en comparant les performances entre un CPU Intel x86 et un processeur AMD de spécifications similaires, par exemple. Tant que le jeu fonctionne confortablement sur votre machine avec des spécifications minimales, vous devriez être raisonnablement confiant quant aux autres machines. Il vaut également la peine de considérer l'utilisation d'analytique, comme Unity Analytics, pour enregistrer les taux de trame, les spécifications système et les paramètres des options des joueurs afin d'identifier les points chauds ou les configurations problématiques.

Nous voyons de plus en plus de studios passer à l'utilisation d'au moins un certain niveau de tests automatisés pour le profilage régulier sur appareil, avec des statistiques résumées publiées où toute l'équipe peut garder un œil sur les performances sur la gamme de dispositifs cibles. Avec des scènes de test bien conçues, cela peut généralement être transformé en un processus mécanique adapté à l'automatisation, donc vous n'avez pas besoin d'un artiste technique expérimenté ou d'un testeur QA pour exécuter manuellement les builds à travers le processus.

Voyez-vous parfois des problèmes de performance sur des appareils haut de gamme qui ne se produisent pas sur les appareils bas de gamme ?

C'est rare, mais nous l'avons vu. Souvent, le problème réside dans la façon dont le projet est configuré, comme avec l'utilisation de shaders sophistiqués et de textures haute résolution sur des appareils haut de gamme, ce qui peut exercer une pression supplémentaire sur le GPU ou la mémoire. Parfois, un appareil mobile haut de gamme ou une console utilisera un écran de téléphone haute résolution ou une sortie TV 4K comme argument de vente, mais n'aura pas nécessairement assez de puissance GPU ou de mémoire pour tenir cette promesse sans optimisation supplémentaire.

Si vous utilisez les versions actuelles du système de travail C#, vérifiez s'il y a un surcoût de planification de travail qui évolue avec le nombre de threads de travail, qui à son tour, évolue avec le nombre de cœurs CPU. Cela peut entraîner un code qui s'exécute plus lentement sur un Threadripper™ à 64+ cœurs que sur un CPU modeste à 4 cœurs ou 8 cœurs. Ce problème sera abordé dans les futures versions de Unity, mais en attendant, essayez de limiter le nombre de threads de travail en définissant JobsUtility.JobWorkerCount.

Quels sont quelques conseils pour établir un bon budget de trame ?

La plupart du temps, lorsque nous parlons de budgets de trame, nous parlons du budget de temps global pour la trame. Vous calculez 1000/frames par seconde cible (fps) pour obtenir votre budget de trame : 33,33 ms pour 30 fps, 16,66 ms pour 60 fps, 8,33 ms pour 120 Hz, etc. Réduisez ce nombre d'environ 35 % si vous êtes sur mobile pour donner aux puces une chance de refroidir entre chaque trame. Diviser le budget pour obtenir des sous-budgets spécifiques pour différentes fonctionnalités et/ou systèmes est probablement excessif sauf pour les projets avec des systèmes très spécifiques et prévisibles, ou ceux qui font un usage intensif du découpage temporel.

En général, le profilage est le processus de recherche des plus gros goulets d'étranglement – et donc, des plus grands gains de performance potentiels. Donc, plutôt que de dire : « La physique prend 1,2 ms alors que le budget n'autorise que 1 ms », vous pourriez regarder une trame et dire : « Le rendu prend 6 ms, ce qui en fait le coût CPU principal du thread principal dans la trame. Comment pouvons-nous réduire cela ?

Il semble que le profilage précoce et fréquent ne soit toujours pas une connaissance courante. Quelles sont vos réflexions sur les raisons pour lesquelles cela pourrait être le cas ?

Construire, publier, promouvoir et gérer un jeu est un travail difficile sur plusieurs fronts. Il y aura donc toujours de nombreuses priorités en concurrence pour l'attention d'un développeur, et le profilage peut être négligé. Ils savent que c'est quelque chose qu'ils devraient faire, mais peut-être qu'ils ne sont pas familiers avec les outils et ne se sentent pas le temps d'apprendre. Ou, ils ne savent pas comment intégrer le profilage dans leurs flux de travail car ils sont poussés à terminer des fonctionnalités plutôt qu'à optimiser les performances.

Tout comme avec les bogues et la dette technique, les problèmes de performance sont moins chers et moins risqués à traiter tôt, plutôt que plus tard dans le cycle de développement d'un projet. Notre objectif est d'aider à démystifier les outils et techniques de profilage pour les développeurs qui ne les connaissent pas. C'est ce que le livre électronique de profilage et ses articles de blog et webinaires connexes visent à soutenir.

Y a-t-il un moyen d'exclure certaines méthodes de l'instrumentation ou d'inclure uniquement des méthodes spécifiques lors de l'utilisation du Profilage Profond dans le Profiler Unity ? Lors de l'utilisation de nombreuses tâches async/await, nous créons de grandes traces de pile, mais comment pouvons-nous éviter de ralentir à la fois le client et le Profiler lors du Profilage Profond ?

Vous pouvez activer les piles d'appels d'allocation pour voir les piles d'appels complètes qui mènent à des allocations gérées (affichées en magenta dans la vue de la chronologie du Profiler CPU Unity). De plus, vous pouvez – et devez ! – instrumenter manuellement les méthodes et processus de longue durée en saupoudrant ProfilerMarkers dans votre code. Il n'y a actuellement aucun moyen d'activer automatiquement le Profilage Profond ou de désactiver complètement le profilage dans certaines parties de votre application. Mais ajouter manuellement des ProfilerMarkers et activer les piles d'appels d'allocation lorsque cela est nécessaire peut vous aider à explorer les zones problématiques sans avoir à recourir au Profilage Profond.

Depuis Unity 2022.2, vous pouvez également utiliser notre IgnoredByDeepProfilerAttribute pour empêcher le Profiler Unity de capturer les appels de méthode. Il suffit d'ajouter l'attribut IgnoredByDeepProfiler aux classes, structures et méthodes.

Où puis-je trouver plus d'informations sur le Profilage Profond dans Unity ?

Le Profilage Approfondi est couvert dans notre documentation du Profiler. Ensuite, il y a la ressource la plus complète pour les informations de profilage, le Guide Ultime pour le profilage des jeux Unity e-book, qui renvoie à la documentation pertinente et à d'autres ressources tout au long.

Est-il correct que le Profilage Approfondi n'est utile que pour le Profiler des Allocations et qu'il fausse les résultats au point de ne pas être utile pour trouver des ralentissements dans le jeu ?

Le Profilage Approfondi peut être utilisé pour trouver les causes spécifiques des allocations gérées, bien que les piles d'appels d'allocation puissent faire la même chose avec moins de surcharge, dans l'ensemble. En même temps, le Profilage Approfondi peut être utile pour enquêter rapidement sur pourquoi un ProfilerMarker spécifique semble prendre autant de temps, car il est plus pratique de l'activer que d'ajouter de nombreux ProfilerMarkers à vos scripts et de reconstruire votre jeu. Mais oui, cela fausse les performances de manière assez importante et ne devrait donc pas être activé pour le profilage général.

VSync vaut-il la peine d'être réglé sur chaque VBlank ? Mon jeu mobile fonctionne à un fps très bas lorsqu'il est désactivé.

Les appareils mobiles forcent VSync à être activé au niveau du pilote/matériel, donc le désactiver dans les paramètres de qualité de Unity ne devrait pas faire de différence sur ces plateformes. Nous n'avons pas entendu parler d'un cas où désactiver VSync affecte négativement les performances. Essayez de prendre une capture de profil avec VSync activé, ainsi qu'une autre capture de la même scène mais avec VSync désactivé. Ensuite, comparez les captures en utilisant Profile Analyzer pour essayer de comprendre pourquoi les performances sont si différentes.

Comment pouvez-vous déterminer si le thread principal attend le GPU et non l'inverse ?

Cela est couvert dans le Guide Ultime pour le profilage des jeux Unity. Vous pouvez également obtenir plus d'informations dans l'article de blog, Détecter les goulets d'étranglement de performance avec le Gestionnaire de Timing de Frame Unity.

En général, le signe révélateur est que le thread principal attend le thread de Rendu tandis que le thread de Rendu attend le GPU. Les noms de marqueurs spécifiques varieront en fonction de votre plateforme cible et de l'API graphique, mais vous devriez rechercher des marqueurs avec des noms tels que "PresentFrame" ou "WaitForPresent."

Y a-t-il un processus solide pour trouver des fuites de mémoire dans le profilage ?

Utilisez le Memory Profiler pour comparer les instantanés de mémoire et vérifier les fuites. Par exemple, vous pouvez prendre un instantané dans votre menu principal, entrer dans votre jeu puis quitter, revenir au menu principal et prendre un deuxième instantané. Comparer ces deux éléments vous dira si des objets/allocation du jeu sont toujours présents en mémoire.

A-t-il du sens d'optimiser et de réécrire une partie du code pour le système DOTS, pour les appareils mobiles y compris VR/AR ? Utilisez-vous ce système dans vos projets ?

Un certain nombre de projets de jeu utilisent maintenant des parties de la Data-Oriented Technology Stack (DOTS). Native Containers, le C# Job System, Mathematics, et le Burst compiler sont tous des packages entièrement pris en charge que vous pouvez utiliser immédiatement pour écrire un code C# optimal, parallélisé et haute performance (HPC#) afin d'améliorer les performances CPU de votre projet.

Un nombre plus restreint de projets utilise également Entities et des packages associés, tels que le Hybrid Renderer, Unity Physics, et le NetCode. Cependant, à ce moment, les packages listés sont expérimentaux, et leur utilisation implique d'accepter un certain degré de risque technique. Ce risque provient d'une API qui est encore en évolution, de fonctionnalités manquantes ou incomplètes, ainsi que de la courbe d'apprentissage en ingénierie nécessaire pour comprendre le Design Orienté Données (DOD) afin de tirer le meilleur parti du Système de Composants d'Entités (ECS) de Unity. L'ingénieur Unity Steve McGreal a écrit un guide sur les meilleures pratiques DOTS, qui inclut quelques fondamentaux DOD et des conseils pour améliorer les performances ECS.

Comment procédez-vous pour définir des limites sur les appels SetPass ou la complexité des shaders ? Pouvez-vous même définir des limites à l'avance ?

Le rendu est un processus complexe et il n'existe pas de moyen pratique pour définir une limite stricte sur le nombre maximum d'appels SetPass ou une métrique pour la complexité des shaders. Même sur une plateforme matérielle fixe, comme une console unique, les limites dépendront du type de scène que vous souhaitez rendre, et du travail supplémentaire qui se déroule sur le CPU et le GPU pendant une image.

C'est pourquoi la règle sur le moment de profiler est "tôt et souvent". Les équipes ont tendance à créer une démo de "tranche verticale" tôt dans la production - généralement une courte période de jeu développée au niveau de fidélité visuelle prévu pour le jeu final. C'est votre première occasion de profiler le rendu et de déterminer quelles optimisations et limites pourraient être nécessaires. Le processus de profilage doit être répété chaque fois qu'une nouvelle zone ou un autre élément majeur de contenu visuel est ajouté.

Voici des ressources supplémentaires pour apprendre sur l'optimisation des performances :

Blogs

• Optimisez les performances de vos jeux mobiles : Conseils d'experts sur les graphiques et les ressources
• Optimisez les performances de vos jeux mobiles : Conseils d'experts sur la physique, l'interface utilisateur et les paramètres audio
• Optimisez les performances de vos jeux mobiles : Conseils d'experts sur le profilage, la mémoire et l'architecture du code des meilleurs ingénieurs de Unity
• Conseils d'experts pour optimiser les graphiques de votre jeu sur consoles
• Profilage dans Unity 2021 LTS : Quoi, quand et comment

Pages de tutoriels

• Outils de profilage et de débogage
• Comment profiler la mémoire dans Unity
• Meilleures pratiques pour le profilage des performances de jeu

E-books

• Optimisez les performances de vos jeux sur console et PC
• Optimisez les performances de vos jeux mobiles
• Guide ultime pour le profilage des jeux Unity

Apprendre des tutoriels

• Profilage des performances CPU dans les builds Android avec Android Studio
• Applications de profilage – Fabriqué avec Unity

Encore plus de contenu technique avancé arrive bientôt – mais en attendant, n'hésitez pas à suggérer des sujets que nous pourrions aborder sur le forum et consultez l'enregistrement complet du webinaire de table ronde.