Performances — MRTK2

Prise en main

Le moyen le plus simple de rationaliser les performances consiste à utiliser une fréquence d’images ou le nombre de fois que votre application peut afficher une image par seconde. Il est important de répondre à la fréquence d’images cible, comme indiqué par la plateforme ciblée (c’est-à-dire Windows Mixed Reality, Tableaux, etc.). Par exemple, sur HoloLens, la fréquence d’images cible est de 60 FPS. Les applications à faible débit d’images peuvent entraîner des expériences utilisateur détériorées telles que la stabilisation de l’hologramme dégradée, le suivi mondial, le suivi des mains, etc. Pour aider les développeurs à suivre et à atteindre une fréquence d’images de qualité, le kit de ressources Mixed Reality fournit un large éventail d’outils et de scripts.

Profileur visuel

Pour suivre en permanence les performances pendant la durée de vie du développement, il est vivement recommandé d’afficher toujours un visuel à débit d’images lors de l’exécution & du débogage d’une application. Le kit de ressources Mixed Reality fournit l’outil de diagnostic Visual Profiler qui fournit des informations en temps réel sur l’utilisation actuelle des FPS et de la mémoire dans la vue d’application. Le profileur visuel peut être configuré via le système de diagnostic Paramètres sous l’inspecteur de profils MRTK.

En outre, il est particulièrement important d’utiliser visual Profiler pour suivre la fréquence d’images lors de l’exécution sur l’appareil, par opposition à l’exécution dans l’éditeur Unity ou dans un émulateur. Les résultats de performances les plus précis sont décrits lors de l’exécution sur l’appareil avec les builds de configuration Release.

Notes

Si vous générez des Windows Mixed Reality, déployez avec des builds de configuration MASTER

Visual Profiler Interface

Fenêtre d’optimisation

La fenêtre d’optimisation MRTK offre des informations et des outils d’automatisation pour aider les développeurs de réalité mixte à configurer leur environnement pour obtenir les meilleurs résultats et identifier les goulots d’étranglement potentiels dans leurs ressources de scène & . Certaines configurations clés dans Unity peuvent aider à fournir des résultats nettement plus optimisés pour les projets de réalité mixte.

En règle générale, ces paramètres impliquent des configurations de rendu idéales pour la réalité mixte. Les applications de réalité mixte sont uniques par rapport au développement graphique 3D traditionnel, car il existe deux écrans (c’est-à-dire deux yeux) à restituer pour toute la scène.

Les paramètres recommandés référencés ci-dessous peuvent être configurés automatiquement dans un projet Unity en tirant parti de la fenêtre d’optimisation MRTK.

MRTK Optimize Window Settings

Profileur Unity

Unity Profiler est un outil utile pour examiner les détails des performances des applications au niveau de l’image par trame.

Temps passé sur le processeur

Example Unity Profiler Graph

Pour maintenir des fréquences d’images confortables (généralement 60 images par seconde), les applications doivent atteindre une durée maximale de 16,6 millisecondes de temps processeur. Pour vous aider à identifier le coût de la fonctionnalité MRTK, microsoft Mixed Reality Toolkit contient des marqueurs pour les chemins de code de boucle interne (par frame). Ces marqueurs utilisent le format suivant pour vous aider à comprendre les fonctionnalités spécifiques utilisées :

[MRTK] className.methodName

Notes

Il peut y avoir des données supplémentaires en suivant le nom de la méthode. Cette fonctionnalité permet d’identifier les fonctionnalités exécutées de manière conditionnelle, potentiellement coûteuses, qui peuvent être évitées par de petites modifications apportées au code d’application.

Example Unity Profiler Hierarchy

Dans cet exemple, la hiérarchie a été développée pour montrer que la méthode UpdateHandData de la classe WindowsMixedRealityArticulatedHand consomme 0,44 ms de temps processeur pendant l’analyse de l’image. Ces données peuvent être utilisées pour déterminer si un problème de performances est lié au code d’application ou à partir d’un autre emplacement du système.

Il est vivement recommandé aux développeurs d’instrumenter le code d’application de la même manière. Les principaux domaines de focus pour l’instrumentation du code d’application se trouvent dans les gestionnaires d’événements, car ces méthodes sont facturées à la boucle de mise à jour MRTK au fur et à mesure que des événements sont déclenchés. Les temps d’images élevés dans la boucle de mise à jour MRTK peuvent indiquer un code coûteux dans les méthodes du gestionnaire d’événements.

rendu instance Single-Pass

La configuration de rendu par défaut pour XR dans Unity est multi-passe. Ce paramètre indique à Unity d’exécuter l’intégralité du pipeline de rendu deux fois, une fois pour chaque œil. Cela peut être optimisé en sélectionnant le rendu instanced à passe unique à la place. Cette configuration s’appuie sur les tableaux de cibles de rendu pour pouvoir effectuer un seul appel de dessin que les instances dans la cible de rendu appropriée pour chaque œil. En outre, ce mode permet d’effectuer tout le rendu dans une seule exécution du pipeline de rendu. Par conséquent, la sélection du rendu à instance directe unique comme chemin d’accès de rendu pour une application de réalité mixte peut gagner beaucoup de temps sur le GPU processeur & et est la configuration de rendu recommandée.

Toutefois, pour émettre un seul appel de dessin pour chaque maillage à chaque œil, l’instanciation GPU doit être prise en charge par tous les nuanceurs. L’instanciation permet au GPU de dessiner plusieurs appels entre les deux yeux. Les nuanceurs intégrés Unity ainsi que le nuanceur MRTK Standard par défaut contiennent les instructions d’instanciation nécessaires dans le code du nuanceur. Si vous écrivez des nuanceurs personnalisés pour Unity, ces nuanceurs doivent peut-être être mis à jour pour prendre en charge le rendu d’instance à passe unique.

Exemple de code pour le nuanceur personnalisé

struct appdata
{
    float4 vertex : POSITION;
    float2 uv : TEXCOORD0;

    UNITY_VERTEX_INPUT_INSTANCE_ID //Insert
};

struct v2f
{
    float2 uv : TEXCOORD0;
    float4 vertex : SV_POSITION;

    UNITY_VERTEX_OUTPUT_STEREO //Insert
};

v2f vert (appdata v)
{
    v2f o;

    UNITY_SETUP_INSTANCE_ID(v); //Insert
    UNITY_INITIALIZE_OUTPUT(v2f, o); //Insert
    UNITY_INITIALIZE_VERTEX_OUTPUT_STEREO(o); //Insert

    o.vertex = UnityObjectToClipPos(v.vertex);

    o.uv = v.uv;

    return o;
}

Paramètres de qualité

Unity fournit des présélections pour contrôler la qualité du rendu pour chaque point de terminaison de plateforme. Ces présélections contrôlent les fonctionnalités graphiques qui peuvent être activées, telles que les ombres, l’anticrénelage, l’illumination globale, etc. Il est recommandé de réduire ces paramètres et d’optimiser le nombre de calculs effectués pendant le rendu.

Étape 1 : Mettre à jour des projets Unity de réalité mixte pour utiliser le paramètre de niveau de faible qualité
Modifier>Project Paramètres, puis sélectionnez la catégorie >Qualité Sélectionner de faible qualité pour la plateforme UWP

Étape 2 : Pour chaque fichier de scène Unity, désactivez l’illumination globale en temps réel
Fenêtre>Rendu>Éclairage Paramètres>Uncheck Real-time Global Illumination

Partage de mémoire tampon de profondeur (HoloLens)

Si vous développez pour la plateforme Windows Mixed Reality et en particulier HoloLens, l’activation du partage des mémoires tampons de profondeur sous XR Paramètres peut aider à stabiliser l’hologramme. Toutefois, le traitement de la mémoire tampon de profondeur peut entraîner un coût de performances, en particulier si vous utilisez un format de profondeur 24 bits. Par conséquent, il est vivement recommandé de configurer la mémoire tampon de profondeur avec une précision de 16 bits.

Si z-fighting se produit en raison du format bit inférieur, vérifiez que le plan de découpage éloigné de toutes les caméras est défini sur la valeur la plus faible possible pour l’application. Unity définit par défaut un plan de clip éloigné de 1 000m. Sur HoloLens, un plan de clip éloigné de 50 m est généralement plus que suffisant pour la plupart des scénarios d’application.

Notes

Si vous utilisez le format de profondeur 16 bits, les effets requis de la mémoire tampon de gabarit ne fonctionnent pas, car Unity ne crée pas de mémoire tampon de gabarit dans ce paramètre. La sélection à l’inverse d’un format de profondeur 24 bits crée généralement une mémoire tampon de gabarit 8 bits, le cas échéant sur la plateforme graphique de point de terminaison.

Si vous utilisez un composant Mask qui nécessite la mémoire tampon de gabarit, envisagez d’utiliser RectMask2D à la place, ce qui ne nécessite pas la mémoire tampon de gabarit et peut donc être utilisé conjointement avec un format de profondeur 16 bits.

Notes

Pour déterminer rapidement les objets d’une scène qui n’écrivent pas visuellement dans la mémoire tampon de profondeur, vous pouvez utiliser l’utilitaire De mémoire tampon de profondeur de rendu sous l’éditeur Paramètres dans le profil de configuration MRTK.

Optimiser les données Mesh

Les paramètres Optimiser Mesh données tentent de supprimer les attributs de vertex inutilisés au sein de votre application. Le paramètre effectue cette opération en exécutant chaque nuanceur passe dans chaque matériau qui se trouve sur chaque maillage de la build. Cela est bon pour la taille des données de jeu et les performances du runtime, mais peut considérablement entraver les temps de génération.

Il est recommandé de désactiver ce paramètre pendant le développement et de réactiver lors de la création de build « Master ». Le paramètre se trouve sous Edit>Project Paramètres>Player>Other Paramètres>Optimize Mesh Data.

Recommandations générales

Les performances peuvent être un défi ambigu et en constante évolution pour les développeurs de réalité mixte et le spectre des connaissances pour rationaliser les performances est vaste. Il existe toutefois quelques recommandations générales pour comprendre comment aborder les performances d’une application.

Il est utile de simplifier l’exécution d’une application dans les éléments qui s’exécutent sur l’UC ou le GPU et ainsi d’identifier si une application est limitée par l’un des composants. Il peut y avoir des goulots d’étranglement qui s’étendent à la fois aux unités de traitement et à certains scénarios uniques qui doivent être soigneusement examinés. Toutefois, pour commencer, il est judicieux de comprendre où une application s’exécute pendant le plus de temps.

GPU limité

Étant donné que la plupart des plateformes pour les applications de réalité mixte utilisent le rendu stéréoscopique, il est très courant d’être limité par GPU en raison de la nature du rendu d’un écran « double large ». Futhermore, les plateformes de réalité mixte mobile telles que HoloLens ou Developers Quest seront limitées par la puissance de traitement GPU de & la classe mobile.

Lorsque vous vous concentrez sur le GPU, il existe généralement deux étapes importantes qu’une application doit effectuer chaque image.

  1. Exécuter le nuanceur de vertex
  2. Exécuter le nuanceur de pixels (également appelé nuanceur de fragments)

Sans plonger profondément dans le champ complexe des pipelines de rendu graphiques& par ordinateur, chaque étape de nuanceur est un programme qui s’exécute sur le GPU pour produire les éléments suivants.

  1. Les nuanceurs de vertex transforment les sommets de maillage en coordonnées dans l’espace écran (par exemple, le code exécuté par vertex)
  2. Les nuanceurs de pixels calculent la couleur à dessiner pour un fragment de pixel et de maillage donné (par exemple, exécuter le code par pixel)

En ce qui concerne le réglage des performances, il est généralement plus productif de se concentrer sur l’optimisation des opérations dans le nuanceur de pixels. Une application peut seulement avoir besoin de dessiner un cube qui ne sera que de 8 sommets. Toutefois, l’espace d’écran occupé par le cube est probablement sur l’ordre de millions de pixels. Par conséquent, la réduction du code du nuanceur par exemple 10 opérations peut économiser beaucoup plus de travail si elle est réduite sur le nuanceur de pixels que le nuanceur de vertex.

Il s’agit de l’une des principales raisons de tirer parti du nuanceur MRTK Standard , car ce nuanceur exécute généralement beaucoup moins d’instructions par vertex de pixels & que le nuanceur Standard Unity tout en obtenant des résultats esthétiques comparables.

Optimisations de l’UC Optimisations GPU
Logique de simulation d’application Opérations de rendu
Simplifier la physique Réduire les calculs d’éclairage
Simplifier les animations Réduire le nombre & de polygones # d’objets dessinables
Gérer le garbage collection Réduire le nombre d’objets transparents
Références du cache Éviter les effets post-traitement/plein écran

Dessiner l’instanciation d’appel

L’une des erreurs les plus courantes dans Unity qui réduit les performances est le clonage de matériaux au moment de l’exécution. Si GameObjects partagent le même matériau et/ou sont le même maillage, ils peuvent être optimisés en appels de tirage unique via des techniques telles que le traitement par lots statique, le traitement dynamique et l’instanciation GPU. Toutefois, si les propriétés de modification du développeur du matériel d’un renderer au moment de l’exécution, Unity crée une copie clone du matériel affecté.

Par exemple, s’il existe 100 cubes dans une scène, un développeur peut souhaiter affecter une couleur unique à chacun au moment de l’exécution. L’accès à renderer.material.color en C# crée un nouveau matériau en mémoire pour ce renderer/GameObject particulier. Chacun des 100 cubes aura son propre matériel et ne peut donc pas être fusionné en un appel de tirage, mais devient plutôt 100 demandes d’appel de tirage du processeur vers le GPU.

Pour surmonter cet obstacle et toujours attribuer une couleur unique par cube, les développeurs doivent tirer parti de MaterialPropertyBlock.

private PropertyBlock m_PropertyBlock ;
private Renderer myRenderer;

private void Start()
{
     myRenderer = GetComponent<Renderer>();
     m_PropertyBlock = new MaterialPropertyBlock();
}

private void ChangeColor()
{
    // Creates a copy of the material once for this renderer
    myRenderer.material.color = Color.red;

    // vs.

    // Retains instancing capability for renderer
    m_PropertyBlock.SetColor("_Color", Color.red);
    myRenderer.SetPropertyBlock(m_PropertyBlock);
}

Outils de performances Unity

Unity fournit d’excellents outils de performances intégrés à l’éditeur.

Si vous estimez le compromis des performances approximatives entre un nuanceur et un autre, il est utile de compiler chaque nuanceur et d’afficher le nombre d’opérations par étape du nuanceur. Cette opération peut être effectuée en sélectionnant une ressource de nuanceur et en cliquant sur le bouton Compiler et afficher le code . Cela compile toutes les variantes du nuanceur et ouvre Visual Studio avec les résultats. Remarque : Les résultats des statistiques produits peuvent varier en fonction des caractéristiques activées sur les matériaux utilisant le nuanceur donné. Unity compile uniquement les variantes du nuanceur utilisées directement dans le projet actuel.

Exemple de statistiques du nuanceur Standard Unity

Unity Standard Shader Statistics 1

Exemple de statistiques du nuanceur STANDARD MRTK

MRTK Standard Shader Statistics 2

Voir aussi

Unity

Windows Mixed Reality

Oculus

optimisation de Mesh