Profilage des applications DirectX

Cela vous montre comment mesurer certaines des mesures de temps de performance les plus importantes pour une application DirectX à l’aide des outils XPerf et GPUView fournis dans le cadre du Kit de ressources Windows Performance Toolkit. Ce n’est pas un guide complet pour comprendre les outils, plutôt leur applicabilité spécifique pour l’analyse des performances des applications DirectX. Bien que la plupart des techniques décrites ici soient pertinentes pour toutes les applications DirectX, il est le plus pertinent pour les applications qui utilisent des chaînes d’échange et non pour les applications DirectX basées sur XAML qui utilisent des animations SIS/VSIS et XAML. Nous vous guideons dans les mesures clés du temps de performance, comment acquérir et installer les outils, et prendre des traces de mesure des performances, puis les analyser pour comprendre les goulots d’étranglement des applications.

À propos des outils

XPerf

XPerf est un ensemble d’outils d’analyse des performances basés sur le suivi des événements pour Windows (ETW) conçu pour mesurer et analyser les performances détaillées du système et des applications et l’utilisation des ressources. À partir de Windows 8, cet outil en ligne de commande a une interface utilisateur graphique et est appelé l’enregistreur de performances Windows (WPR) et l’analyseur de performances Windows (WPA). Pour plus d’informations sur ces outils, consultez la page web de Windows Performance Toolkit (WPT) : Windows Performance Toolkit.

Un etW collecte les événements de noyau demandés et les enregistre dans un fichier appelé fichier ETL (Event Trace Log). Ces événements de noyau fournissent des informations détaillées sur une application et des caractéristiques système lors de l’exécution de l’application. Les données sont collectées en activant la capture de trace, en effectuant le scénario d’application souhaité qui nécessite une analyse, en arrêtant la capture qui enregistre les données dans un fichier ETL. Vous pouvez ensuite analyser le fichier sur le même ordinateur ou un autre ordinateur à l’aide de l’outil en ligne de commande xperf.exe ou de l’outil d’analyse de trace visuelle xperfview.exe.

GPUView

GPUView est un outil de développement permettant de déterminer les performances de l’unité de traitement graphique (GPU) et du processeur. Il examine les performances en ce qui concerne le traitement direct de la mémoire tampon (DMA) et tout autre traitement vidéo sur le matériel vidéo.

Pour les applications DirectX qui s’appuient fortement sur le GPU, GPUView est un outil puissant pour comprendre la relation entre le travail effectué sur le processeur et le GPU. Pour plus d’informations sur GPUView, consultez Utilisation de GPUView.

À l’instar de XPerf, une trace ETW est d’abord effectuée en démarrant le service de suivi, en effectuant l’exercice du scénario qui nécessite une analyse de l’application, en arrêtant le service et en enregistrant les informations dans un fichier ETL. GPUView présente les données présentes dans le fichier ETL dans un format graphique.

Après avoir installé l’outil GPUView , nous vous recommandons de lire la rubrique « Affichage principal de GPUView » sous le menu « Aide GPUView ». Il contient des informations utiles sur l’interprétation de l’interface utilisateur GPUView .

Installation des outils

XPerf et GPUView sont inclus dans windows Performance Toolkit (WPT).

XPerf est fourni dans le cadre du Kit de développement logiciel Windows (SDK) pour Windows. Téléchargez le Kit de développement logiciel (SDK) Windows.

GPUView est disponible dans le Kit de déploiement et d’évaluation Windows (Windows ADK). Téléchargez Windows ADK.

Après l’installation, vous devez ajouter les répertoires qui contiennent XPerf et GPUView à la variable système « Path ».

Cliquez sur le bouton Démarrer et tapez « Variables système ». La fenêtre Propriétés système s’ouvre. Cliquez sur « Modifier les variables d’environnement système ». Sélectionnez « Variables d’environnement » dans la boîte de dialogue « Propriétés système ». La variable « Path » se trouve sous « Variables système ». Ajoutez le répertoire contenant xperf.exe et GPUView.exe au chemin d’accès. Ces exécutables se trouvent dans le répertoire « Windows Performance Toolkit » dans les « Kits Windows ». L’emplacement par défaut est : C :\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit.

Mesures du temps de performance

La plupart des applications s’attendent à s’exécuter en douceur et à être réactives à l’entrée utilisateur. Toutefois, selon le scénario souhaité, un aspect des performances peut être plus important qu’un autre. Par exemple, pour une application lecteur d’actualités s’exécutant sur un PC tablette tactile, l’aspect le plus important consiste à afficher un seul article à la fois et à parcourir/zoomer/faire défiler le même ou un autre article. Dans ce scénario, la capacité de rendre tout le contenu à chaque image n’est pas nécessaire. Toutefois, la possibilité de faire défiler l’article en douceur sur un geste tactile est extrêmement importante.

Dans une autre instance, un jeu ou une application de rendu vidéo qui utilise beaucoup de glitches d’animations si des images sont supprimées. Dans ce cas, la possibilité de présenter du contenu à l’écran sans interruption de l’entrée utilisateur est extrêmement importante.

Pour comprendre quelle partie de l’application pose problème, la première étape consiste à décider des scénarios les plus importants. Une fois que les principaux aspects de l’application sont compris et comment ils seront exercés, la recherche de problèmes à l’aide des outils devient plus facile.

Voici quelques-unes des métriques de temps de performances les plus courantes :

Heure de démarrage

Durée mesurée du lancement du processus à la première présentation sur l’écran. Cette mesure est plus utile lorsque le système est chaud, ce qui signifie que la mesure est prise après le lancement de l’application quelques fois.

Temps processeur par frame

Heure pendant laquelle le processeur traite activement la charge de travail de l’application pour une trame. Si l’application s’exécute en douceur, tout le traitement requis pour une image se produit dans un intervalle de synchronisation v. Avec le taux d’actualisation du moniteur de 60Hz, il s’agit de 16 ms par image. Si le temps CPU par image est supérieur à 16 ms, des optimisations du CPU peuvent être nécessaires pour assurer une expérience d'application fluide.

Temps GPU par frame

Heure pendant laquelle le GPU traite activement la charge de travail de l’application pour une trame. Une application est liée au GPU lorsque le temps nécessaire pour traiter une trame de données est supérieur à 16 ms.

Être en mesure de comprendre si une application est liée au processeur ou au GPU réduit la partie problématique du code.

Prise d’une trace de mesure du temps de performance

Procédez comme suit pour effectuer une trace :

1. Ouvrez une fenêtre de commande en tant qu’administrateur.
2. Fermez l’application si elle est déjà en cours d’exécution.
3. Remplacez les répertoires par le répertoire gpuview dans le dossier Windows Performance Toolkit.
4. Tapez « log.cmd » pour démarrer le suivi des événements. Cette option enregistre les événements les plus intéressants. D’autres options disponibles journalisent différentes étendues des événements. Par exemple, le mode journal détaillé ou « v » capture tous les événements dont le GPUView a connaissance.
5. Lancez l’exemple et utilisez-le de manière à couvrir le flux de performance que vous devez analyser.
6. Revenez aux fenêtres de commande et tapez à nouveau « log.cmd » pour arrêter la journalisation.
7. Cela génère un fichier appelé « merged.etl » dans le dossier gpuview . Vous pouvez enregistrer ce fichier à un autre emplacement et l’analyser sur le même ordinateur ou sur un autre ordinateur. Pour afficher les détails de la capture de pile, sauvegardez le fichier de symboles (.pdb) associé à l’application.

Mesures

Cette section montre comment mesurer le temps de démarrage, le temps CPU et le temps GPU par image. Vous pouvez capturer une trace de performances pour le même exemple sur votre ordinateur et voir les différences dans les différentes mesures.

Pour analyser la trace dans GPUView, ouvrez le fichier « merged.elt » en utilisant GPUView.exe.

Heure de démarrage

Le temps de démarrage est mesuré par le temps total passé à partir du démarrage de l’application jusqu’à ce que le contenu apparaisse d’abord sur l’écran.

La mesure au moment du démarrage est la meilleure prise en suivant les étapes répertoriées dans la section précédente avec ces variations :

• Si vous prenez les mesures de démarrage la première fois que vous lancez l’application, elle est appelée démarrage à froid. Cela peut varier en fonction des mesures prises après avoir lancé l'application plusieurs fois en peu de temps. C’est ce qu’on appelle le démarrage chaud. Selon le nombre de ressources créées par une application au lancement, il peut y avoir une grande différence entre les deux fois de démarrage. Selon les objectifs de l’application, mesurer l’un ou l’autre peut être souhaitable.
• Lorsque vous journalisez les informations de performances, arrêtez l’application dès que la première image s’affiche à l’écran.

Calcul du temps de démarrage à l’aide de GPUView

1. Dans GPUView, faites défiler jusqu’au processus approprié, dans ce cas GeometryRealization.exe.

   

2. La file d’attente du processeur de contexte représente la charge de travail graphique mise en file d’attente vers le matériel, mais pas nécessairement traitée par le matériel. Lorsque le fichier de trace est ouvert, il affiche tous les événements enregistrés entre le moment où la trace a été effectuée. Pour calculer l’heure de démarrage, sélectionnez la région d’intérêt, effectuez un zoom avant dans la partie initiale de la première file d’attente du processeur de contexte (il s’agit de celle qui affiche l’activité) à l’aide de Ctrl +Z. Pour plus d’informations sur les contrôles GPUView , consultez la section « Résumé des contrôles GPUView ». La figure ci-dessous montre uniquement le processus de GeometryRealization.exe zoomé sur la première partie de la file d’attente du processeur de contexte. La couleur de la file d’attente du processeur contextuel est indiquée par le rectangle situé en dessous de la file d’attente et les mêmes paquets de données de couleur dans la file d’attente affichent le travail GPU mis en file d’attente sur le matériel. Le paquet de motif de hachures dans la file d'attente contextuelle montre le paquet actuel, ce qui signifie que l'application souhaite que le matériel affiche le contenu à l'écran.

   

3. L'heure de démarrage est le moment où l'application démarre pour la première fois (dans ce cas, le module de point d’entrée du thread de l’interface utilisateur SHCORE.dll) jusqu’à ce que le contexte apparaisse pour la première fois (indiqué par un paquet de signalisation). La figure ici met en évidence le domaine d’intérêt.

   Remarque

   Les informations actuelles sont représentées dans la file d'attente de basculement, et donc le temps nécessaire est prolongé jusqu'à ce que le paquet actuel se termine réellement dans la file d'attente de basculement.

    

   La barre d’état complète n’est pas visible dans la figure ci-dessous, qui montre également le temps écoulé entre les parties en surbrillance. Il s’agit de l’heure de démarrage de l’application. Dans ce cas pour la machine mentionnée ci-dessus, cela s'est révélé être environ 240 ms.

   

Temps processeur et GPU par frame

Il existe quelques points à prendre en compte lors de la mesure du temps processeur. Recherchez les zones de la trace où vous avez exercé le scénario à analyser. Par exemple, dans le cas de la réalisation géométrique, l’un des scénarios analysés est la transition entre le rendu de 2048 à 8192 primitives, toutes inactives (c'est-à-dire que la géométrie n’est pas tesselée à chaque image). La trace montre clairement la différence dans l’activité processeur et GPU avant et après la transition dans le nombre de primitives.

Deux scénarios sont analysés pour calculer le temps processeur et GPU par frame. Ils sont les suivants.

• Passage de 2048 primitives non matérialisées à 8192 primitives non matérialisées.
• Transition du rendu de 8192 primitives réalisées à 8192 primitives non matérialisées.

Dans les deux cas, on a observé que la fréquence d’images a chuté considérablement. La mesure du temps processeur et GPU, la relation entre les deux ainsi que quelques autres modèles dans la trace peut fournir des informations utiles sur les zones problématiques de l’application.

Calcul du temps processeur et GPU lorsque les primitives 2048 sont rendues non réalisées

1. Ouvrez le fichier de trace à l’aide de GPUView.exe.

2. Faites défiler vers le bas jusqu'au processus GeometryRealization.exe.

3. Sélectionnez une zone pour calculer le temps processeur et effectuez un zoom sur celui-ci à l’aide de Ctrl + Z.

   

4. Affichez les informations de synchronisation verticale en basculant avec F8. Continue de zoomer jusqu'à ce qu'il soit facile de voir clairement une unité de données de vsync. Les lignes bleues indiquent les temps de synchronisation verticale. En règle générale, celles-ci se produisent une fois toutes les 16 ms (60 fps), mais si DWM rencontre un problème de performances, elle s’exécute plus lentement afin qu’elles se produisent une fois toutes les 32 ms (30 fps). Pour avoir un sens du temps, sélectionnez une barre bleue à la suivante, puis examinez le nombre de ms signalés dans le coin inférieur droit de la fenêtre GPUView .

   

5. Pour mesurer le temps processeur par frame, mesurez la durée nécessaire à tous les threads impliqués dans le rendu. Il peut être utile de limiter le thread qui devrait être le plus pertinent du point de vue des performances. Par exemple, dans l'exemple d'implémentation géométrique, le contenu est animé et doit être rendu sur l'écran à chaque frame, ce qui rend le thread de l'interface utilisateur crucial. Une fois que vous avez déterminé le thread à examiner, mesurez la longueur des barres sur ce thread. La moyenne de quelques-uns de ces résultats génère du temps processeur par frame. La figure ci-dessous montre le temps nécessaire au thread d’interface utilisateur. Il montre également que ce laps de temps s’adapte bien entre deux synchronisations verticales (v-sync) consécutives, ce qui signifie que le processus atteint 60FPS.

   

   Vous pouvez également vérifier en examinant la file d’attente de retournement (flip queue) pour la plage horaire pertinente, indiquant que DWM est capable de présenter chaque image.

   

6. Le temps GPU peut être mesuré de la même façon que le temps processeur. Effectuez un zoom sur la zone appropriée, comme dans le cas de mesurer le temps processeur. Mesurez la longueur des barres dans la file d’attente matérielle GPU avec la même couleur que la couleur de la file d’attente du processeur contextuel. Tant que les barres s'intègrent dans les synchronisations verticales consécutives, l'application fonctionne de manière fluide à 60 images par seconde.

   

Calcul du temps processeur et GPU lorsque les primitives 8192 sont rendues non réalisées

1. Si vous suivez à nouveau les mêmes étapes, la trace indique que tout le travail de l’UC pour une trame ne correspond pas entre une synchronisation v et la suivante. Cela signifie que l’application est liée au processeur. Le thread d’interface utilisateur sature le processeur.

   

   En examinant la file d'attente de rendu, il est également clair que DWM n'est pas en mesure de rendre chaque image.

   

2. Pour analyser où le temps est utilisé, ouvrez la trace dans XPerf. Pour analyser l’heure de démarrage dans XPerf, recherchez d’abord l’intervalle de temps dans GPUView. Souris sur la gauche de l’intervalle et à droite et notez l’heure absolue affichée en bas de la fenêtre GPUView . Ouvrez ensuite le même fichier .etl dans XPerf et faites défiler jusqu’au graphique « Échantillonnage du processeur par processeur », cliquez avec le bouton droit et sélectionnez « Sélectionner l’intervalle ... » Cela permet de taper dans l’intervalle d’intérêt qui a été découvert en examinant la trace GPU.

   

3. Accédez au menu Trace et vérifiez que l’option « Charger les symboles » est cochée. Accédez également à Trace -> Configurer les chemins d’accès aux symboles et tapez le chemin d’accès aux symboles de l’application. Un fichier de symboles contient des informations de débogage sur un exécutable compilé dans une base de données distincte (.pdb). Ce fichier est communément appelé PDB. Vous trouverez plus d’informations sur les fichiers de symboles ici : Fichiers de symboles. Ce fichier peut se trouver dans le dossier « Déboguer » du répertoire de l’application.

4. Pour obtenir la répartition de l’endroit où le temps est passé dans l’application, cliquez avec le bouton droit sur l’intervalle sélectionné à l’étape précédente, puis cliquez sur Tableau résumé. Pour obtenir une vue d’ensemble du temps passé dans chaque dll, décochez « Pile » dans le menu « Colonnes ». Notez que la colonne « Count » indique ici le nombre d’exemples dans la dll/fonction donnée. Étant donné qu’environ un échantillon est pris par ms, ce nombre peut être utilisé comme une meilleure estimation du temps passé dans chaque dll/fonction. Cocher « Pile » dans le menu Colonnes vous donnera le temps inclusif passé dans chaque fonction du graphe d'appels. Cela aidera à décomposer davantage les aspects problématiques.

5. Les informations de trace de pile pour les primitives non réalisées en 2048 révèlent que 30% de temps processeur sont passés dans le processus de réalisation géométrique. De cela autour de 36% du temps est passé dans le pavage géométrique et le caressement.

6. Les informations de trace de pile pour les primitives non réalisées 8192 révèlent qu’environ 60% du temps processeur (4 cœurs) sont dépensés dans la réalisation géométrique.

   

Calcul du temps de calcul du processeur lorsque 8192 primitives sont en cours de rendu

Il est clair dans les profils que l’application est liée au processeur. Pour réduire le temps passé par l’UC, les géométries peuvent être créées une fois et mises en cache. Le contenu mis en cache peut être rendu à chaque frame sans entraîner le coût de tessellation géométrique par frame. Lorsque vous examinez la trace dans GPUView pour la partie réalisée de l’application, il est clair que DWM est en mesure de présenter chaque frame et que le temps processeur a diminué considérablement.

La première partie du graphique montre les 8192 primitives réalisées. Le temps processeur correspondant par frame est en mesure de s’adapter à deux synchronisations v consécutives. Dans la partie ultérieure du graphique, cela n’est pas vrai.

En examinant XPerf, le CPU est inactif pendant la durée la plus longue avec seulement 25% du temps processeur utilisé par l'application de matérialisation géométrique.

Résumé

GPUView et XPerf et outils puissants pour analyser les performances des applications DirectX. Cet article est un point d’introduction à l’utilisation de ces outils et à la compréhension des mesures de performances de base et des caractéristiques de l’application. Outre la compréhension de l’utilisation des outils, il est tout d’abord important de comprendre l’application analysée. Commencez par trouver des réponses à des questions telles que : qu’essaie de réaliser l’application ? Quels threads du système sont les plus importants ? Quels compromis êtes-vous prêt à faire ? Lors de l’analyse des traces de performances, commencez par examiner des endroits problématiques évidents. L'application est-elle limitée par le processeur (CPU) ou la carte graphique (GPU) ? L’application est-elle en mesure de présenter chaque image ? Les outils avec une compréhension de l’application peuvent fournir des informations très utiles dans la compréhension, la recherche et enfin la résolution des problèmes de performances.