Analyse comparative des performances dans Unity : Comment démarrer
En tant que développeur Unity, vous souhaitez que vos utilisateurs adorent jouer à vos jeux, en bénéficiant d'une expérience fluide sur toutes les plateformes sur lesquelles ils peuvent jouer. Et si je vous disais que nous venons de faciliter la création de critères de performance ? Si vous souhaitez apprendre à développer des jeux ou des outils Unity en mettant l'accent sur les performances, lisez la suite !
Dans ce billet, j'explique comment utiliser deux outils Unity qui vous donnent un moyen facile de commencer à collecter des mesures de performance et de créer des benchmarks avec elles : le Unity Test Runner livré avec l'éditeur Unity, l'extension Unity Performance Testing Extension, et le Unity Performance Benchmark Reporter.
En tant que développeur Unity, vous pouvez vous trouver dans la situation suivante : votre projet fonctionnait rapidement et sans problème il y a peu, mais un ou plusieurs changements sont intervenus, et maintenant les scènes sont sensiblement lentes, les images chutent, et d'autres problèmes de performance ont commencé à apparaître. Il peut être difficile de déterminer les changements qui ont entraîné une régression des performances.
Si vous êtes un partenaire d'Unity, vous voulez comprendre les changements de performance à travers vos SDK, pilotes, plateformes, paquets ou autres artefacts. Ou bien vous aimeriez recueillir des données sur les performances de vos produits dans différentes versions d'Unity, mais la manière de procéder et d'établir des comparaisons n'est pas très claire.
Il ne s'agit là que de quelques exemples où l'établissement de critères de performance peut vraiment vous sauver la mise. Maintenant, laissez-moi vous montrer comment vous pouvez commencer à collecter des mesures de performance, créer des points de référence avec eux et visualiser les changements dans les mesures de performance.
Pour cette discussion, nous examinerons le code de test dans l'exemple de projet de test de performance UnityPerformanceBenchmark.
Téléchargez la dernière version de XRAutomatedTests depuis GitHub. Vous trouverez le projet UnityPerformanceBenchmark dans le sous-répertoire PerformanceTests.
Le projet UnityPerformanceBenchmark contient une variété de scènes types qui sont à leur tour utilisées dans les tests de performance Unity à l'aide de l'extension de test de performance Unity.
La première chose que nous allons faire est de regarder comment nous écrivons des tests de performance en utilisant le Unity Test Runner avec l'extension Unity Performance Testing. Avant de poursuivre, voici quelques informations sur ces deux outils.
Nous utilisons le Test Runner d'Unity pour exécuter nos tests de performance. Le Unity Test Runner est un framework d'exécution de tests intégré à l'éditeur Unity qui vous permet de tester votre code en mode édition et en mode lecture sur des plateformes cibles telles que Standalone, Android ou iOS. Si vous n'êtes pas familier avec Unity Test Runner, consultez la documentation de Unity Test Runner.
L'extension de test de performance Unity est un package de l'éditeur Unity qui fournit une API et des attributs de cas de test vous permettant d'échantillonner et d'agréger à la fois les marqueurs de profilage Unity et les métriques personnalisées non profilées, dans l'éditeur Unity et dans les joueurs. Vous pouvez en savoir plus en consultant la documentation de l'extension de test de performance d'Unity, mais nous allons nous pencher sur quelques exemples ici.
L'extension de test de performance Unity nécessite la version 2018.1 ou une version ultérieure d'Unity. Veillez à utiliser la version 2018.1 ou supérieure d'Unity si vous souhaitez exécuter les exemples de tests de performance dans le projet UnityPerformanceBenchmark ou chaque fois que vous utilisez l'extension de test de performance Unity.
Le projet UnityPerformanceBenchmark met en œuvre l'interface IPrebuildSetup, une fonctionnalité d'Unity Test Runner, où nous pouvons mettre en œuvre une méthode Setup qui est automatiquement appelée avant que le test ne soit exécuté par Unity Test Runner.
La première chose que fait la méthode IPrebuildSetup.Setup du projet UnityPerformanceBenchmark est d'analyser les arguments de la ligne de commande à la recherche des paramètres de construction du lecteur. Cela nous permet de construire de manière flexible le lecteur pour nos tests de performance en utilisant le même projet Unity sur différentes plates-formes, modes de threads de rendu, API graphiques du lecteur, implémentations de scripts et paramètres activés par XR tels que le chemin de rendu stéréo et les SDK VR.
Nous devrons donc ouvrir le projet UnityPerformanceBenchmark avec Unity à partir de la ligne de commande, en passant les options de construction du lecteur que nous voulons utiliser lorsque nous exécutons les tests dans le Unity Test Runner.
Exemple : Lancez le projet UnityPerformanceBenchmark depuis Windows pour construire le lecteur Android :
Unity.exe -projectPath
C:\XRAutomatedTests-2018.2\PerformanceTests\UnityPerformanceBenchmark
-testPlatform Android -buildTarget Android -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono
Ici, nous lançons Unity sur Windows pour construire pour Android avec l'API graphique OpenGLES3, le rendu multithread et le backend de script mono.
Exemple : Lancez le projet UnityPerformanceBenchmark depuis OSX pour construire le lecteur iOS
./Unity -projectPath /XRAutomatedTests-2018.2/PerformanceTests/UnityPerformanceBenchmark
-testPlatform iOS -buildTarget iOS -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono
-appleDeveloperTeamID=<votreAppleDeveloperTeamID>
-iOSProvisioningProfileID=<votreIosProvisionProfileID>.
Ici, nous lançons Unity sur OSX pour construire pour iOS avec l'API graphique OpenGLES3, le rendu multithread et le backend de script mono. Nous fournissons également l'équipe de développeurs Apple et les informations de profil de provisionnement nécessaires au déploiement sur un appareil iOS.
Lorsque vous ouvrez le projet UnityPerformanceBenchmark avec Unity à partir de la ligne de commande, comme dans les exemples ci-dessus, les paramètres de la ligne de commande seront en mémoire pour que la méthode IPrebuildSetup.Setup les analyse et les utilise pour construire le lecteur.
Bien que cette approche de lancement à partir de la ligne de commande ne soit pas nécessaire pour exécuter les tests dans le Test Runner d'Unity, c'est un bon modèle à utiliser pour éviter d'utiliser un projet de test distinct pour chaque configuration de lecteur.
J'ai détaillé les options de ligne de commande pour ouvrir le projet, ou simplement exécuter les tests, à partir de la ligne de commande sur le wiki pour le projet de test : Comment exécuter les tests d'évaluation des performances d'Unity. Pour en savoir plus sur la façon dont nous analysons les paramètres de construction du lecteur dans le projet de test, consultez le fichier RenderPerformancePrebuildStep.cs dans le répertoire Scripts du projet de test UnityPerformanceBenchmark.
Après avoir ouvert le test UnityPerformanceBenchmark, nous devons ouvrir la fenêtre Unity Test Runner dans l'éditeur Unity.
- dans Unity 2018.1, allez dans Fenêtre > Test Runner.
- dans Unity 2018.2, allez dans Fenêtre > Général > Test Runner.
La fenêtre d'Unity Test Runner s'ouvre et ressemble à l'image ci-dessous.
Il s'agit de nos tests de performance Unity. Nous pouvons les exécuter dans l'éditeur à l'aide du bouton Exécuter situé en haut à gauche de la fenêtre, ou sur l'appareil ou la plate-forme en question à l'aide du bouton "Exécuter tout dans le lecteur" situé en haut à droite de la fenêtre.
Conseil de débogage
Si vous souhaitez déboguer du code dans votre méthode IPrebuildSetup.Setup
1. Placez des points d'arrêt dans votre code IPrebuildSetup.Setup dans Visual Studio.
2. Attachez-vous à l'éditeur Unity avec l'extension Visual Studio Tool for Unity
3. Exécutez vos tests dans l'éditeur en utilisant le bouton "Run All" ou "Run Select" dans la fenêtre Unity Test Runner.
À ce stade, le débogueur de Visual Studio s'introduit dans votre code et vous pouvez le déboguer si nécessaire.
Examinons un exemple de test de performance afin de mieux comprendre son fonctionnement.
Exemple : Échantillonnage des marqueurs du Profiler dans un test de performance d'Unity
[PerformanceUnityTest]
public IEnumerator SpiralFlame_RenderPerformance()
{
yield return SceneManager
.LoadSceneAsync(spiralSceneName, LoadSceneMode.Additive);
SetActiveScene(spiralSceneName);
// Instantiate performance test object in scene
var renderPerformanceTest =
SetupPerfTest<DynamicRenderPerformanceMonoBehaviourTest>();
// allow time to settle before taking measurements
yield return new WaitForSecondsRealtime(SettleTime);
// use ProfilerMarkers API from Performance Test Extension
using (Measure.ProfilerMarkers(SamplerNames))
{
// Set CaptureMetrics flag to TRUE;
// let's start capturing metrics
renderPerformanceTest.component.CaptureMetrics = true;
// Run the MonoBehaviour Test
yield return renderPerformanceTest;
}
yield return SceneManager.UnloadSceneAsync(spiralSceneName);
}Dans cet exemple, notre méthode de test s'appelle SpiralFlame_RenderPerformance. Le décorateur de la méthode [PerformanceUnityTest] nous indique qu'il s'agit d'un test de performance Unity.
Tous les tests du projet de test UnityPerformanceBenchmark suivent le même schéma que cette méthode de test :
1. Chargez la scène pour le test
2. Activez la scène afin de pouvoir interagir avec elle dans la méthode de test.
3. Créez un objet de test de type DynamicRenderPerformanceMonoBehaviourTest et ajoutez-le à la scène de test (dans la méthode SetupPerfTest<T>).
4. Attendez que la scène se stabilise après le chargement et l'ajout de l'objet de test à la scène avant de lancer les mesures de l'échantillon.
5. Configurez nos marqueurs de profilage pour qu'ils soient capturés par l'API d'extension des tests de performance.
6. Faites savoir au test de performance que nous sommes prêts à commencer à capturer des mesures.
7. Ensuite, le yield renvoie l'objet de test (un IMonoBehaviourTest) pour capturer les métriques pendant la boucle de rendu.
Nous échantillonnons également des mesures personnalisées (mesures qui n'appartiennent pas à l'un des marqueurs de profilage d'Unity, le nombre d'images ou le temps d'exécution) dans la classe de base RenderPerformanceMonoBehaviourTestBase (cette classe hérite de MonoBehaviour).
Exemple : Échantillonnage de mesures personnalisées dans un script MonoBehaviour
private void Update()
{
if (CaptureMetrics)
{
FrameCount++;
SampleFps();
#if ENABLE_VR
if (XRSettings.enabled)
{
SampleGpuTimeLastFrame();
}
#endif
}
if (IsMetricsCaptured)
{
EndMetricCapture();
}
}
private void SampleFps()
{
Fps = GetFps();
Measure.Custom(FpsSg, Fps);
startFrameCount = Time.renderedFrameCount;
}
private void SampleGpuTimeLastFrame()
{
var gpuTimeLastFrame = GetGpuTimeLastFrame();
Measure.Custom(GpuTimeLastFrameSg, gpuTimeLastFrame * 1000);
}
public void EndMetricCapture()
{
CaptureMetrics = false;
#if UNITY_ANALYTICS && UNITY_2018_2_OR_NEWER
Measure.Custom(startupTimeSg, appStartupTime);
#endif
}Dans l'exemple ci-dessus, nous capturons les FPS, GpuTimeLastFrame (si XR est activé) et le temps de démarrage de l'application (si Unity Analytics est activé et que nous fonctionnons sur Unity 2018.2- ou plus récent où l'API dont nous avons besoin est disponible).
Enfin, remarquez que dans la même classe de base RenderPerformanceMonoBehaviourTestBase, nous avons implémenté une propriété public bool IsTestFinished. Nous sommes tenus d'implémenter cette propriété parce que notre RenderPerformanceMonoBehaviourTestBase implémente l'interface IMonoBehaviourTest.
Cette propriété est importante car le Test Runner d'Unity l'utilise pour savoir quand arrêter le test. Lorsque sa valeur est vraie, le test se termine. C'est à vous d'implémenter la logique que vous souhaitez afin de déterminer quand le Test Runner d'Unity doit arrêter l'exécution du test.
Exemple : Échantillonnage de mesures personnalisées dans la propriété IsTestFinished
public bool IsTestFinished
{
get
{
bool isTestFinished = false;
if (IsMetricsCaptured)
{
Measure.Custom(objCountSg, RenderedGameObjects);
Measure.Custom(trianglesSg, Tris);
Measure.Custom(verticesSg, Verts);
isTestFinished = true;
}
return isTestFinished;
}
}Dans ce dernier exemple, nous enregistrons le nombre d'objets, de triangles et de sommets rendus dans la scène à la fin du test.
Maintenant que nous avons vu quelques exemples de la manière dont nous faisons appel à l'extension Performance Testing pour échantillonner des mesures, parlons de la manière dont nous configurons ces mesures pour commencer.
Les méthodes Measure.* prennent généralement en paramètre une structure appelée SampleGroupDefinition. Lorsque nous créons un nouveau SampleGroupDefinition, nous définissons certaines propriétés pour les échantillons que nous souhaitons collecter.
Exemple : Définir un nouveau SampleGroupDefinition pour GpuTimeLastFrame, en utilisant les millisecondes comme unité d'échantillonnage, agréger les échantillons en utilisant une valeur minimale.
Vous trouverez ci-dessous un exemple de définition de groupe pour GpuTimeLastFrame. C'est ainsi que nous indiquons à Performance Testing Extension comment collecter des échantillons et les agréger pour GpuTimeLastFrame.
Ce SampleGroupDefinition provient de l'exemple de test de performance du rendu de scène dynamique, nous avons donc choisi ici d'agréger nos échantillons en utilisant la valeur minimale collectée. Mais pourquoi faire cela plutôt que d'utiliser une mesure d'agrégation plus courante, comme la médiane ou la moyenne ?
La réponse est que la scène est dynamique. Dans une scène dynamique, l'utilisation d'une agrégation médiane ou moyenne ne serait pas fiable ou incohérente pour la même scène exécutée avec le même code, étant donné la nature changeante du rendu. C'est probablement le mieux que nous puissions faire si nous voulons suivre un agrégat unique pour une mesure de rendu dans une scène dynamique. Cependant, lorsque nous définissons un SampleGroupDefinition similaire pour nos scènes statiques, nous utilisons définitivement une agrégation médiane.
new SampleGroupDefinition(GpuTimeLastFrameName, SampleUnit.Millisecond, AggregationType.Min)
Exemple : Définir un nouveau SampleGroupDefinition pour les FPS, en utilisant none comme unité d'échantillonnage, agréger les échantillons en utilisant une valeur médiane, une augmentation de la valeur est meilleure.
Vous trouverez ci-dessous la définition du groupe d'échantillons pour les FPS (images par seconde). Le FPS n'a pas d'unité de mesure distincte ; il s'agit simplement du FPS, c'est pourquoi nous spécifions ici SampleUnit.None. Nous utiliserons ici un type d'agrégation médian ; il s'agit d'une scène statique, de sorte que nous n'avons pas à nous soucier d'un rendu imprévisible. Nous établissons explicitement un seuil de 15 % pour le groupe échantillon, et nous passons à true pour l'argument increaseIsBetter parce que, si le FPS augmente, c'est une bonne chose !
Ces deux derniers arguments sont collectés et enregistrés dans notre fichier .xml de résultats de tests de performance lors de l'exécution à partir de la ligne de commande, et peuvent être utilisés ultérieurement dans l'outil Unity Performance Benchmark Reporter pour établir des points de référence.
new SampleGroupDefinition(FpsName, SampleUnit.None, AggregationType.Median, threshold : 0,15, increaseIsBetter : true)
Lorsque le test est terminé, tous les échantillons de mesures que nous avons activés précédemment sont alors agrégés par l'extension Performance Testing.
Je tiens à souligner que dans nos exemples de code, nous utilisons deux API différentes de l'extension de test de performance d'Unity, à savoir
- Measure.ProfilerMarkers, et
- Mesure.personnalisée
L'extension de test de performance Unity fournit également d'autres méthodes de mesure qui peuvent répondre à vos besoins spécifiques en fonction de ce que vous voulez mesurer dans Unity et de la manière dont vous voulez le faire. Ces méthodes supplémentaires sont les suivantes
- Mesure.Méthode
- Mesure.des.cadres
- Mesure.portée
- Measure.FrameTimes
Pour en savoir plus sur les différentes méthodes de mesure, consultez la documentation de l'extension Unity Performance Testing Extension, et plus particulièrement la section "Taking measurements".
Maintenant que nous avons vu quelques exemples de la façon dont nous écrivons des tests de performance à l'aide du Unity Test Runner en utilisant l'extension Unity Performance Testing, regardons comment nous les exécutons.
Nous pouvons exécuter nos tests de performance de deux manières principales
1. À partir de la ligne de commande, lancez Unity avec l'option -runTests. C'est la méthode préférée pour les tests de performance car Unity Performance Test Extension génère un fichier .xml que nous pouvons utiliser dans Unity Performance Benchmark Reporter pour visualiser et comparer nos résultats.
2. Directement à partir de l'éditeur. Cette approche est utile si vous
a. Vous souhaitez simplement exécuter les tests et visualiser les résultats dans la fenêtre du Test Runner d'Unity sans avoir besoin de capturer les résultats pour un usage ultérieur, ou
b. Vous voulez vérifier que vos tests s'exécutent ou vous avez besoin de déboguer le code de test.
Voici deux exemples d'exécution de tests de performance avec Unity Test Runner à partir de la ligne de commande. Ces exemples devraient vous sembler très familiers, car nous nous basons sur les mêmes exemples que ceux que nous avons vus plus tôt dans notre discussion sur l'ouverture du projet UnityPerformanceBenchmark à partir de la ligne de commande.
Exemple : Exécution des tests de performance du test UnityPerformanceBenchmark à partir de Windows contre un lecteur Android
Ici, nous lançons Unity sur Windows pour construire pour Android avec l'API graphique OpenGLES3, le rendu multithread et le backend de script mono.
Unity.exe -runTests [-batchmode] -projectPath
C:\N- XRAutomatedTests-2018.2\NPerformanceTests\NUnityPerformanceBenchmark -testPlatform Android -buildTarget Android -playergraphicsapi=OpenGLES3 -mtRendering -scriptingbackend=mono -testResults
C:\PerfTests\results\PerfBenchmark_Android_OpenGLES3_MtRendering_Mono.xml -logfile
C:\PerfTests\logs\PerfBenchmark_Android_OpenGLES3_MtRendering_Mono_UnityLog.txt
Exemple : Exécution des tests de performance UnityPerformanceBenchmark à partir d'OSX contre un lecteur iOS
Ici, nous lançons Unity sur OSX pour construire pour iOS avec l'API graphique OpenGLES3, le rendu multithread et le backend de script mono. Nous fournissons également l'équipe de développeurs Apple et les informations de profil de provisionnement nécessaires au déploiement sur un appareil iOS.
./Unity -runTests [-batchmode] -projectPath /XRAutomatedTests-2018.2/PerformanceTests/UnityPerformanceBenchmark
-testPlatform iOS -buildTarget iOS -playergraphicsapi=OpenGLES3
-mtRendering -scriptingbackend=mono
-appleDeveloperTeamID=<votreAppleDeveloperTeamID>
-iOSProvisioningProfileID=<votreIosProvisionProfileID> -testResults /PerfTests/results/PerfBenchmark_Android_OpenGLES3_MtRendering_Mono.xml
-logfile /PerfTests/logs/PerfBenchmark_Android_OpenGLES3_MtRendering_Mono_UnityLog.txt
Pour ces deux exemples, nous avons introduit trois ou quatre nouvelles options de ligne de commande qui nous aideront à exécuter nos tests au lieu de simplement ouvrir l'éditeur Unity avec les arguments de ligne de commande disponibles pour la méthode IPrebuildSetup.Setup.
-runTests
Cette option indique au Test Runner d'Unity que vous souhaitez exécuter vos tests
-testResults <pathToWritePerformanceTestResultsFile>
Cette option spécifie le nom et le chemin du fichier .xml dans lequel Unity Test Runner doit enregistrer les résultats de vos tests de performance.
-logfile <pathToWriteUnityEditorLogFile>
Cette option spécifie le nom et le chemin d'accès au fichier dans lequel l'éditeur Unity doit écrire sa journalisation. Cette option est facultative, mais elle peut s'avérer très utile lorsque vous enquêtez sur des échecs ou des problèmes, car elle vous permet d'accéder rapidement au fichier journal de l'éditeur Unity.
-batchmode
Cette option force l'éditeur Unity à s'ouvrir en mode sans tête. Nous utilisons cette option lorsque nous effectuons uniquement des tests de performance du lecteur et qu'il n'est pas nécessaire d'ouvrir la fenêtre de l'éditeur Unity. Cela permet de gagner du temps lors de l'exécution des tests automatisés. Si cette option n'est pas utilisée, l'éditeur Unity s'ouvrira à l'écran avant l'exécution des tests.
Chez Unity, nous exécutons nos tests de performance à partir de la ligne de commande, souvent en mode batch, dans notre système d'intégration continue.
Exemple : Exécution des tests UnityPerformanceBenchmark à partir de la ligne de commande
Avec la fenêtre du Test Runner d'Unity ouverte vers le haut lorsque PlayMode est sélectionné (les tests PlayMode s'exécutent soit dans le lecteur de compilation, soit dans la fenêtre PlayMode de l'éditeur), nous avons
1. Exécuter tout - cliquez sur ce bouton pour exécuter tous les tests de l'onglet PlayMode.
2. Exécuter la sélection - cliquez sur ce bouton pour exécuter le test ou le nœud sélectionné et tous les tests situés en dessous.
3. Run all in player - cliquez sur ce bouton pour que l'éditeur Unity construise le type de lecteur configuré dans les paramètres de construction et exécute les tests à cet endroit.
Condition importante L'exécution de tests de performance antérieurs à la version 0.1.50 de l'extension de test de performance dans l'éditeur Unity à partir de la fenêtre Test Runner ne produira pas de fichier .xml de résultat nécessaire pour le Unity Performance Benchmark Reporter. Cependant, si vous utilisez la version 0.1.50 ou une version ultérieure de l'extension Performance Testing, un fichier results.xml sera écrit dans le dossier du projet `Assets\StreamingAssets`.
Si vous utilisez une version de l'extension de test de performance antérieure à la version 0.1.50 et que vous souhaitez créer un fichier .xml de résultats lorsque vous avez effectué vos tests de performance, vous devez exécuter les tests en lançant Unity à partir de la ligne de commande avec l'option de ligne de commande -runTests. Sachez cependant que lorsque vous exécutez Unity avec l'option de ligne de commande -runTests, l'éditeur s'ouvre et commence à exécuter les tests.
Les fichiers .xml de résultats contiendront les résultats et les métadonnées des essais que nous utiliserons avec l'outil Unity Performance Benchmark Reporter pour créer des résultats de référence et les comparer aux essais suivants.
Exemple : Exécution de tests de performance dans l'éditeur Unity
Si vous exécutez ces tests à partir de l'éditeur, vous pouvez voir les valeurs agrégées en bas de la fenêtre du Test Runner d'Unity en sélectionnant chaque test.
Exemple : Visualisation des agrégations d'échantillons de tests de performance depuis Unity Test Runner
Si vous voulez voir les résultats de vos tests de performance Unity depuis la ligne de commande, vous devrez utiliser le Unity Performance Benchmark Reporter (ou simplement ouvrir le fichier .xml des résultats, mais ce n'est pas facile à lire).
Passons maintenant à l'utilisation de l'outil Unity Performance Benchmark Reporter pour visualiser et comparer les résultats.
Unity Performance Benchmark Reporter permet de comparer les lignes de base des métriques de performance et les métriques de performance ultérieures (telles que générées à l'aide de Unity Test Runner avec l'extension Unity Performance Testing) dans un rapport html avec des visualisations graphiques.
Le rapporteur est construit en tant qu'assemblage .NET Core 2.x afin qu'il soit compatible avec les différentes plateformes supportées par .NET (Windows, OSX, etc.). Par conséquent, pour l'exécuter, vous devez vous assurer que vous avez installé le SDK .NET Core.
L'exécution du rapport Unity Performance Benchmark consiste à invoquer l'assemblage avec la commande dotnet comme suit :
dotnet UnityPerformanceBenchmarkReporter.dll
--baseline=D:\UnityPerf\baseline.xml
--results=D:\UnityPerf\results --reportdirpath=d:\UnityPerf
Après l'exécution du rapporteur, un répertoire nommé UnityPerformanceBenchmark sera créé avec un rapport html et les fichiers .css, .js et image correspondants. Ouvrez le rapport html pour visualiser les mesures de performance capturées dans les fichiers de résultats .xml.
--résultats
Le chemin d'accès à un répertoire où se trouvent un ou plusieurs fichiers .xml de résultats non basiques à inclure dans le rapport html.
Au moins une valeur --results doit être transmise à l'assembly UnityPerformanceBenchmarkReporter.dll. Il s'agit du seul champ obligatoire.
Cette option de ligne de commande peut également être utilisée pour spécifier le chemin d'accès à un seul fichier de résultats non basiques .xml. En outre, vous pouvez spécifier plusieurs répertoires ou fichiers en répétant l'option comme suit :
--results=D:\UnityPerf\results --results=D:\UnityPerf\results.xml
--baseline
Le chemin d'accès à un fichier .xml de résultat qui sera utilisé pour comparer d'autres résultats.
--reportdirpath
Chemin d'accès au répertoire dans lequel le rapporteur créera le rapport de performance. Il est créé dans un sous-répertoire UnityPerformanceBenchmark.
Si l'emplacement du rapport n'est pas spécifié, le sous-répertoire UnityPerformanceBenchmark sera créé dans le répertoire de travail dans lequel UnityPerformanceBenchmarkReporter.dll a été invoqué.
Comparons quelques résultats de tests de performance avec le Performance Benchmark Reporter.
Exemple : Expérimentez des changements de configuration dans une scène du Gear VR pour améliorer le taux de rafraîchissement.
J'ai une scène Unity avec les caractéristiques de complexité suivantes.
- 732 objets
- 95 898 triangles
- 69 740 vertices
J'ai lancé un test de performance Unity sur cette scène en échantillonnant des mesures qui m'aideraient à comprendre si je pouvais maintenir près de 60 FPS en utilisant le rendu stéréo multi-passe. Ensuite, j'ai lancé le Performance Benchmark Reporter avec les résultats de mon test.
Ce que j'ai constaté, c'est que mon FPS est plus proche de 30 FPS, soit la moitié de ce que j'aimerais obtenir.
Ensuite, je vais essayer d'utiliser le Single Pass Multiview Stereo Rendering pour voir si je peux approcher les 60 FPS. Je vais réexécuter mon test de performance avec le changement de configuration, puis créer un autre rapport d'évaluation comparative des performances d'Unity en comparant mes premiers résultats avec les nouveaux.
Il semble que le passage de la configuration au rendu Single Pass Multiview ait permis d'améliorer notre FPS à 37. Nous devons encore nous rapprocher de 60 FPS si nous voulons que cette scène s'exécute sans baisse significative du nombre d'images sur le Gear VR.
La dernière chose que je vais expérimenter est de réduire le nombre de cubes rotatifs dans ma scène pour voir si nous pouvons augmenter le FPS.
Après quelques essais, j'arrive à améliorer les performances jusqu'à ~55 FPS. Mais j'ai dû réduire le nombre d'objets dans la scène de 732 à 31. C'est beaucoup.
Je reviendrai sur les autres améliorations que je peux apporter pour optimiser les performances, mais pour l'instant, je vais utiliser ce résultat comme base de référence pour le FPS. Je m'en servirai comme point de référence à l'avenir, en espérant l'améliorer si possible.
L'établissement de critères de référence peut avoir plusieurs significations en fonction de votre projet. Dans ce contexte, l'exécution de tests de performance dans Unity vise à établir un ensemble de résultats de référence, un dernier ensemble de mesures de performance connu auquel nous pourrons comparer les résultats ultérieurs au fur et à mesure que nous apporterons des modifications. Ceux-ci deviennent notre référence.
Dans la section précédente, je suis arrivé à une configuration utilisant le rendu stéréo multi-vues à passage unique pour le Gear VR, et une diminution du nombre d'objets de la scène, qui a permis d'obtenir un FPS " acceptable ". Je décide alors d'utiliser les résultats de mes tests comme référence. Voyons un exemple de la manière dont nous pouvons utiliser ce benchmark lorsque nous apportons d'autres modifications à la configuration du lecteur.
Exemple : Utilisez l'analyse comparative des performances pour détecter une régression des performances suite à des modifications de la configuration.
J'aimerais activer l'anticrénelage dans ma scène afin de lisser l'apparence. Les paramètres de qualité par défaut dans Unity pour Android désactivent l'anticrénelage, mais j'aimerais voir si nous pouvons l'activer tout en conservant un FPS acceptable pour notre scène Gear VR.
Tout d'abord, j'ai réglé la valeur de l'anticrénelage dans ma méthode IPrebuildSetup.Setup sur 4.
QualitySettings.antiAliasing = 4;
Ensuite, je ré-exécute le test de performance de tout à l'heure sur mon téléphone Android équipé du Gear VR. J'utilise ensuite l'outil Unity Performance Benchmark Reporter pour comparer cette nouvelle exécution avec les résultats de mon nouveau benchmark.
Mais regardez, avec la reconfiguration de mon lecteur Unity pour utiliser l'anticrénelage au niveau 4, mon FPS est tombé à 32 FPS, ce qui correspond à peu près à mon point de départ lorsque j'ai créé cette scène avec 732 objets.
J'aimerais expérimenter avec quelques valeurs d'anticrénelage plus basses pour voir si je peux retrouver un FPS acceptable pour la scène avant de renoncer à cette idée. J'essaie donc de régler l'anticrénelage sur 2, puis sur 1. Les résultats sont présentés dans l'image ci-dessous.
Dans ce scénario de reconfiguration, à l'aide de la référence de performance que j'ai établie précédemment, j'ai pu expérimenter des changements dans les paramètres de mon lecteur Unity, puis vérifier les impacts sur les performances avant de m'engager.
Même si je suis dans mon seuil de 15% de variance par défaut pour le FPS en utilisant l'anti-crénelage réglé sur 1, le FPS est maintenant à 49, un peu trop loin des 60 FPS pour ma scène avec VR que j'aimerais atteindre. Je ne pense pas m'engager dans ces changements aujourd'hui.
Unity met l'accent sur les performances par défaut. Mais le moteur Unity n'est qu'une partie de ce qui fait qu'au final, les utilisateurs aiment jouer à vos jeux, en bénéficiant d'une expérience fluide et performante sur toutes les plateformes sur lesquelles ils peuvent jouer. Et les SDK, les pilotes ou les paquets Unity, par exemple, qui fonctionnent parfaitement sans introduire de régression des performances, sont essentiels à une expérience de performance globalement excellente pour tout le monde.
Je vous ai présenté quelques outils Unity qui facilitent la collecte de mesures de performance et la création de benchmarks : l'extension Unity Performance Testing Extension et le Unity Performance Benchmark Reporter. Je vous encourage à expérimenter ce qu'ils peuvent faire pour vous et vos efforts axés sur la performance.
Nous avons examiné
- Comment utiliser le Test Runner d'Unity pour écrire des tests de performance afin d'échantillonner le profiler et d'autres métriques,
- Différentes façons d'exécuter des tests de performance à l'aide du Test Runner d'Unity, et
- Comment utiliser le Performance Benchmark Reporter d'Unity pour analyser et comparer les mesures de performance, run après run, alors que vous commencez à améliorer votre jeu de test de performance.
Établir des lignes de base pour ces mesures et les utiliser pour créer une référence pour vos scènes, jeux, SDK, pilotes, packages ou autres intégrations Unity peut être un moyen efficace de commencer à créer de la visibilité sur les impacts de vos changements. Bonne chance !
Je tiens à remercier mes collègues de l'Unity pour leur contribution, leur brainstorming, leur expérimentation, leur développement et leur itération sur ce travail.
- Qi Jiang
- Sakari Pitkänen
- Gintautas Skersys
- Benjamin Smith