Profilage d’applications DirectX

Cela vous montre comment mesurer certaines des mesures de temps de performances les plus importantes pour une application DirectX à l’aide des outils XPerf et GPUView fournis dans le cadre du Kit de ressources de performances Windows. Il ne s’agit pas d’un guide complet pour comprendre les outils, mais plutôt de 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, elles sont plus pertinentes pour les applications qui utilisent des chaînes d’échange et non pour les applications DirectX basées sur XAML qui utilisent SIS/VSIS et des animations XAML. Nous vous guiderons à travers les mesures de temps de performances clés, 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 d’é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é Enregistreur de performances Windows (WPR) et Windows Analyseur de performances (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 journal de trace d’événements (ETL). Ces événements de noyau fournissent des informations détaillées sur les caractéristiques d’une application et du système lors de l’exécution de l’application. Les données sont collectées en activant la capture des traces, en exécutant 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 sur un autre ordinateur à l’aide de l’outil en ligne de commandexperf.exe ou de l’outil d’analyse des traces visuellesxperfview.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 de la mémoire tampon d’accès direct à la mémoire (DMA) et tous les autres traitements vidéo sur le matériel vidéo.

Pour les applications DirectX qui dépendent fortement du 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.

Comme pour XPerf, une trace ETW est d’abord effectuée en lançant le service de suivi, en appliquant le scénario qui nécessite une analyse pour l’application à l’examen, 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 (SDK) Windows pour Windows. Téléchargez le Kit de développement logiciel (SDK) Windows.

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

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

Cliquez sur le bouton Démarrer et tapez « Variables système ». Le 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 » à l’intérieur des « 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 aux entrées utilisateur. Toutefois, selon le scénario souhaité, un aspect des performances peut être plus important qu’un autre. Pour instance, pour une application de lecteur d’actualités s’exécutant sur une tablette tactile, l’aspect le plus important est d’afficher un seul article à la fois et de parcourir le même article ou un autre article. Dans ce scénario, la possibilité de restituer tout le contenu de chaque image n’est pas nécessaire. Cependant, la possibilité de faire défiler l’article en douceur sur un geste tactile est extrêmement importante.

Dans un autre instance, un jeu ou une application de rendu vidéo qui utilise de nombreuses animations glisse si des images sont supprimées. Dans ce cas, la possibilité de présenter du contenu à l’écran sans interuption à partir d’une 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 des problèmes à l’aide des outils devient plus facile.

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

Au démarrage

Temps mesuré entre le lancement du processus et 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 à plusieurs reprises.

Temps processeur par frame

Heure pendant laquelle l’UC traite activement la charge de travail de l’application pour une image. Si l’application fonctionne correctement, tout le traitement requis pour une image se produit dans un intervalle de synchronisation v. Avec la fréquence d’actualisation de l’écran de 60 Hz, cela arrive à 16 ms par image. Si la durée/la durée du processeur est supérieure à 16 ms, des optimisations du processeur peuvent être nécessaires pour produire une expérience d’application sans problème.

Temps GPU par trame

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

Le fait de savoir si une application est liée au processeur ou au GPU réduit la partie problématique du code.

Suivi de la mesure du temps de performance

Effectuez les étapes suivantes 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 à l’intérieur du dossier Windows Performance Toolkit.
4. Tapez « log.cmd » pour démarrer le suivi des événements. Cette option journalise les événements les plus intéressants. D’autres options disponibles consignent l’étendue différente des événements. Par instance mode journal « v » ou détaillé capture tous les événements dont le GPUView a connaissance.
5. Lancez l’exemple et exercez l’exemple d’une manière qui couvre le chemin de performances que vous devez analyser.
6. Retour 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 dans 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, enregistrez le fichier de symboles (.pdb) associé à l’application.

Mesures

Notes

Les mesures de l’exemple de réalisation de géométrie sont prises sur une machine Quad Core avec un carte graphique DirectX11 intégré. Les mesures varient en fonction de la configuration de l’ordinateur.

 

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

Pour analyser la trace dans GPUView, ouvrez le fichier « merged.elt » à l’aide deGPUView.exe.

Au 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 s’affiche d’abord à l’écran.

La mesure au démarrage est préférable en suivant les étapes répertoriées dans la section précédente avec ces variantes :

• Si vous prenez les mesures de démarrage la première fois que vous lancez l’application, il s’agit d’un démarrage à froid. Cela peut varier des mesures effectuées après le lancement de l’application plusieurs fois sur une petite durée. 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 heures de démarrage. Selon les objectifs de l’application, la mesure de l’un ou de l’autre peut être souhaitable.
• Lorsque vous consignez des informations sur les performances, arrêtez l’application dès que la première image s’affiche à l’écran.

Calcul de la durée 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 en cours de traitement 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 le temps de démarrage, sélectionnez la région d’intérêt, puis effectuez un zoom sur la partie initiale de la première file d’attente de l’UC contextuelle (c’est celle qui montre 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 » du fichier d’aide GPUView. La figure ci-dessous montre uniquement le processus GeometryRealization.exe qui a zoomé sur la première partie de la file d’attente du processeur de contexte. La couleur de la file d’attente de l’UC de contexte est indiquée par le rectangle situé juste en dessous de la file d’attente et les paquets de données de même couleur dans la file d’attente affichent le travail GPU mis en file d’attente sur le matériel. Le paquet de modèle d’éclosion dans la file d’attente de contexte affiche le paquet présent, ce qui signifie que l’application souhaite que le matériel présente le contenu à l’écran.

   

3. Le moment de démarrage correspond à l’heure à laquelle l’application démarre pour la première fois (dans ce cas, le module point d’entrée du thread d’interface utilisateur SHCORE.dll) jusqu’à ce que le contexte s’affiche pour la première fois (marqué par un paquet d’éclosion). La figure ici met en évidence le domaine d’intérêt.

   Notes

   Les informations présentes réelles sont représentées dans la file d’attente de basculement et le temps nécessaire est donc étendu jusqu’à ce que le paquet présent se termine réellement dans la file d’attente de basculement.

    

   La barre de status 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 du moment de démarrage de l’application. Dans ce cas, pour la machine mentionnée ci-dessus, il s’agit d’environ 240 ms.

   

Temps processeur et GPU par image

Il y a 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 instance, dans l’exemple de réalisation de géométrie, l’un des scénarios analysés est la transition entre le rendu des primitives 2048 et 8192, toutes non réalisées (comme dans, la géométrie n’est pas tessellée chaque image). La trace montre clairement la différence d’activité du processeur et du GPU avant et après la transition du nombre de primitives.

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

• Transition du rendu des primitives non réalisées 2048 à 8192 primitives non réalisées.
• Transition du rendu 8192 primitives réalisées à 8192 primitives non réalisées.

Dans les deux cas, il a été 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 peuvent fournir des informations utiles sur les zones problématiques dans 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 deGPUView.exe.

2. Faites défiler jusqu’au processus GeometryRealization.exe.

3. Sélectionnez une zone pour le calcul du temps processeur et zoomez dessus à l’aide de CTRL + Z.

   

4. Affichez les informations de synchronisation v en basculant entre F8. Effectuez un zoom avant jusqu’à ce qu’il soit facile de voir clairement une valeur vsync des données. Les lignes bleues correspondent à l’emplacement où la synchronisation v-sync s’exécute. 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, de sorte qu’elles se produisent une fois toutes les 32 ms (30 fps). Pour avoir une idée du temps, sélectionnez d’une barre bleue à l’autre, puis examinez le nombre de ms signalées dans le coin inférieur droit de la fenêtre GPUView .

   

5. Pour mesurer le temps processeur par trame, mesurez le temps nécessaire à tous les threads impliqués dans le rendu. Il peut être utile d’affiner le thread qui est censé être le plus pertinent du point de vue des performances. Par instance dans l’exemple de réalisation de géométrie, le contenu est en cours d’animation et doit être affiché à l’écran chaque image, ce qui rend le thread d’interface utilisateur important. Une fois que vous avez déterminé le thread à examiner, mesurez la longueur des barres de ce thread. La moyenne de quelques-unes d’entre elles génère du temps processeur par trame. La figure ci-dessous montre le temps pris sur le thread d’interface utilisateur. Il montre également que cette fois-ci s’adapte bien entre deux v-syncs consécutifs, ce qui signifie qu’il atteint 60FPS.

   

   Vous pouvez également vérifier en examinant la file d’attente inversée pour la période correspondante qui indique que DWM est en mesure de présenter chaque image.

   

6. Le temps du GPU peut être mesuré de la même manière que le temps processeur. Zoomez sur la zone appropriée, comme dans le cas de la mesure du 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 des synchronisations v consécutives, l’application fonctionne correctement à 60 FPS.

   

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 montre que tout le travail du processeur pour une image ne s’adapte pas entre une synchronisation virtuelle 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 inversée, il est également clair que DWM n’est pas en mesure de présenter chaque image.

   

2. Pour analyser où le temps est passé, ouvrez la trace dans XPerf. Pour analyser le temps de démarrage dans XPerf, recherchez d’abord l’intervalle de temps dans GPUView. Souris sur la gauche de l’intervalle et la droite et notez l’heure absolue affichée en bas de la fenêtre GPUView . Ouvrez ensuite le même fichier .etl dans XPerf , puis faites défiler jusqu’au graphique « Uc Sampling by CPU », cliquez avec le bouton droit et sélectionnez « Select Interval... » 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, puis tapez le chemin d’accès au symbole 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 se trouve dans le dossier « Déboguer » du répertoire de l’application.

4. Pour obtenir la répartition du temps passé dans l’application, cliquez avec le bouton droit sur l’intervalle sélectionné à l’étape précédente, puis cliquez sur Table récapitulative. Pour obtenir une vue d’ensemble du temps passé dans chaque dll, décochez « Pile » dans le menu « Colonnes ». Notez que la colonne « Nombre » indique ici le nombre d’exemples dans la dll/fonction donnée. Étant donné qu’environ un échantillon est prélevé par ms, ce nombre peut être utilisé comme une estimation optimale du temps passé dans chaque dll/fonction. La vérification de la pile à partir du menu Colonnes donne le temps inclusif passé dans chaque fonction dans le graphique d’appel. Cela vous aidera à décomposer davantage les points de problème.

5. Les informations de trace de pile pour les primitives non réalisées 2048 révèlent que 30 % du temps processeur est passé dans le processus de réalisation de géométrie. Environ 36 % du temps est consacré à la géométrie de pavage et à la caresse.

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) est consacré à la réalisation de la géométrie.

   

Calcul du temps processeur lorsque 8192 primitives sont rendues en cours de réalisation

Les profils indiquent clairement que l’application est liée au processeur. Afin de réduire le temps passé par le processeur, les géométries peuvent être créées une seule fois et mises en cache. Le contenu mis en cache peut être rendu chaque image sans encourir le coût de mise en forme géométrique par image. 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 image et que le temps processeur a considérablement réduit.

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

Dans XPerf, le processeur reste inactif le plus longtemps, avec seulement environ 25 % du temps passé sur l’application de réalisation de géométrie.

Récapitulatif

GPUView et XPerf et des outils puissants pour analyser les performances des applications DirectX. Cet article est un guide d’introduction à l’utilisation de ces outils et à la compréhension des mesures de performances de base et des caractéristiques des applications. Outre la compréhension de l’utilisation des outils, il est important de comprendre l’application analysée. Commencez par trouver des réponses à des questions telles que ce que l’application tente d’atteindre ? Quels threads dans le système sont les plus importants ? Quels compromis êtes-vous prêt à faire ? Lors de l’analyse des traces de performances, commencez par examiner les endroits problématiques évidents. L’UC ou le GPU de l’application est-il lié ? L’application est-elle en mesure de présenter chaque image ? Les outils associés à une compréhension de l’application peuvent fournir des informations très utiles pour comprendre, trouver et enfin résoudre les problèmes de performances.