Profilerstellung für DirectX-Apps

Dies zeigt, wie Sie einige der wichtigsten Leistungszeitmessungen für eine DirectX-App mithilfe der XPerf- und GPUView-Tools messen, die als Teil des Windows Performance Toolkit ausgeliefert werden. Dies ist kein umfassender Leitfaden für das Verständnis der Tools, sondern ihre spezifische Anwendbarkeit für die Analyse der DirectX-App-Leistung. Während die meisten der hier beschriebenen Techniken für alle DirectX-Apps relevant sind, ist es für Apps relevant, die Swapchains verwenden und nicht für DirectX-Anwendungen, die AUF XAML basieren, SIS/VSIS- und XAML-Animationen verwenden. Wir führen Sie durch wichtige Leistungszeitmessungen, wie Sie die Tools erwerben und installieren und Leistungsmessungsablaufverfolgungen durchführen und diese dann analysieren, um App-Engpässe zu verstehen.

Informationen zu den Tools

Xperf

XPerf ist eine Reihe von Leistungsanalysetools, die auf der Ereignisablaufverfolgung für Windows (ETW) basieren, die für die Messung und Analyse detaillierter System- und App-Leistung und Ressourcennutzung entwickelt wurden. Ab Windows 8 dieses Befehlszeilentool verfügt über eine grafische Benutzeroberfläche und wird als Windows Performance Recorder (WPR) und Windows Leistungsanalyse (WPA) bezeichnet. Weitere Informationen zu diesen Tools finden Sie auf der Webseite für Windows Performance Toolkit (WPT): Windows Performance Toolkit.

Ein ETW sammelt angeforderte Kernelereignisse und speichert sie in einer Datei, die als ETL-Datei (Event Trace Log) bezeichnet wird. Diese Kernelereignisse bieten umfangreiche Informationen zu einer App und systemeigenschaften beim Ausführen der App. Daten werden gesammelt, indem die Ablaufverfolgungserfassung aktiviert wird und das gewünschte App-Szenario ausgeführt wird, das analyse benötigt, die Erfassung beenden, die die Daten in einer ETL-Datei speichert. Anschließend können Sie die Datei auf demselben oder einem anderen Computer mit dem Befehlszeilentool xperf.exe oder dem visuellen Ablaufverfolgungsanalysetool xperfview.exeanalysieren.

GPUView

GPUView ist ein Entwicklungstool zum Ermitteln der Leistung der Grafikverarbeitungseinheit (GPU) und der CPU. Es untersucht die Leistung im Hinblick auf die DMA-Pufferverarbeitung (Direct Memory Access) und alle anderen Videoverarbeitungen auf der Videohardware.

Bei DirectX-Apps , die stark auf der GPU basieren, ist GPUView ein leistungsstarkes Tool zum Verständnis der Beziehung zwischen der Arbeit, die auf der CPU und gpu ausgeführt wird. Weitere Informationen zu GPUViewsee mit GPUView.

Ähnlich wie bei XPerf wird zunächst eine ETW-Ablaufverfolgung durchgeführt, indem der Ablaufverfolgungsdienst gestartet wird, indem das Szenario ausgeführt wird, in dem die Analyse für die App berücksichtigt wird, der Dienst beendet und die Informationen in einer ETL-Datei gespeichert werden. GPUView stellt die Daten in der ETL-Datei in einem grafischen Format dar.

Nach der Installation des GPUView-Tools wird empfohlen, das Thema "GPUView-Hauptanzeige" im Menü "GPUView-Hilfe " zu lesen. Es enthält nützliche Informationen zum Interpretieren der GPUView-Benutzeroberfläche .

Installieren der Tools

Sowohl XPerf als auch GPUView sind im Windows Performance Toolkit (WPT) enthalten.

XPerf wird als Teil des Windows Software Development Kit (SDK) für Windows ausgeliefert. Laden Sie das Windows SDK herunter.

GPUView ist im Windows Assessment and Deployment Kit (Windows ADK) verfügbar. Laden Sie die Windows ADK herunter.

Nach der Installation müssen Sie die Verzeichnisse hinzufügen, die XPerf und GPUView enthalten, der Systemvariable "Path".

Klicken Sie auf die Startschaltfläche, und geben Sie "Systemvariablen" ein. Das System Eigenschaftenfenster wird geöffnet. Klicken Sie auf "Systemumgebungsvariablen bearbeiten". Wählen Sie im Dialogfeld "Systemeigenschaften" "Umgebungsvariablen" aus. Die Variable "Pfad" wird unter "Systemvariablen" gefunden. Fügen Sie das Verzeichnis mit xperf.exe und GPUView.exe an den Pfad an. Diese ausführbaren Dateien befinden sich im Verzeichnis "Windows Performance Toolkit" im Verzeichnis "Windows Kits". Der Standardspeicherort lautet: C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit.

Leistungszeitmessungen

Die meisten Apps erwarten, dass die Benutzereingabe reibungslos ausgeführt wird und reaktionsfähig ist. Je nach gewünschtem Szenario ist jedoch ein Aspekt der Leistung möglicherweise wichtiger als ein anderer. Beispielsweise ist für eine Newsreader-App, die auf einer Toucheingabe Tablet PC ausgeführt wird, der wichtigste Aspekt das Anzeigen eines einzelnen Artikels gleichzeitig und das Verschieben/Zoomen/Scrollen durch dasselbe oder einen anderen Artikel. In diesem Szenario ist die Möglichkeit zum Rendern aller Inhalte für jeden Frame nicht erforderlich. Die Möglichkeit, den Artikel reibungslos durch eine Touchbewegung zu scrollen, ist jedoch äußerst wichtig.

In einer anderen Instanz wird eine Spiel- oder eine Videorendering-App verwendet, die viele Animationen verwendet, wenn Frames abgelegt werden. In diesem Fall ist die Möglichkeit, Inhalte auf dem Bildschirm ohne Interuption von Benutzereingaben darzustellen, äußerst wichtig.

Um zu verstehen, welcher Teil der App problematisch ist, besteht der erste Schritt darin, die wichtigsten Szenarien zu entscheiden. Sobald die wichtigsten Aspekte der App verstanden und wie sie ausgeübt werden, wird die Suche nach Problemen mit den Tools einfacher.

Einige der häufigsten Leistungszeitmetriken sind wie folgt:

Startzeit

Vom Start des Prozesses gemessene Zeit, um zuerst auf den Bildschirm zu treffen. Diese Messung ist nützlicher, wenn das System warm ist, was bedeutet, dass die Messung nach dem Starten der App ein paar Mal durchgeführt wird.

CPU-Zeit pro Frame

Die Zeit, zu der CPU die App-Workload für einen Frame aktiv verarbeitet. Wenn die App reibungslos ausgeführt wird, erfolgt die gesamte für einen Frame erforderliche Verarbeitung innerhalb eines V-Synchronisierungsintervalls. Mit der Monitoraktualisierungsrate von 60Hz kommt dies auf 16 MS pro Frame. Wenn CPU-Zeit/Frame größer als 16 MS ist, müssen CPU-Optimierungen möglicherweise eine kostenlose App-Erfahrung erzeugen.

GPU-Zeit pro Frame

Die Zeit, zu der GPU die App-Workload für einen Frame aktiv verarbeitet. Eine App ist GPU gebunden, wenn die Zeit zum Verarbeiten eines Framewerts von Daten mehr als 16 MS beträgt.

Wenn Sie verstehen können, ob eine App CPU oder GPU ist, wird der problematische Teil des Codes eingeschränkt.

Durchführen der Leistungszeitmessungsablaufverfolgung

Führen Sie die folgenden Schritte aus, um eine Ablaufverfolgung auszuführen:

1. Öffnen Sie ein Befehlsfenster als Administrator.
2. Schließen Sie die App, wenn sie bereits ausgeführt wird.
3. Ändern Sie Verzeichnisse in das gpuview-Verzeichnis im Ordner Windows Performance Toolkit.
4. Geben Sie "log.cmd" ein, um die Ereignisablaufverfolgung zu starten. Diese Option protokolliert die interessantesten Ereignisse. Andere verfügbare Optionen protokollieren einen anderen Bereich der Ereignisse. Zum Beispiel "v" oder ausführlicher Protokollmodus erfasst alle Ereignisse, die die GPUView kennen.
5. Starten Sie das Beispiel, und üben Sie das Beispiel auf eine Weise aus, die den Leistungspfad behandelt, den Sie analysieren müssen.
6. Zurück an die Befehlsfenster und geben Sie "log.cmd" erneut ein, um die Protokollierung zu beenden.
7. Dadurch wird eine Datei namens "merged.etl" im gpuview-Ordner ausgegeben. Sie können diese Datei an einem anderen Speicherort speichern und sie auf demselben oder einem anderen Computer analysieren. Um Stapelerfassungsdetails anzuzeigen, speichern Sie die Symboldatei (PDB), die der App zugeordnet ist.

Messungen

Hinweis

Die Messungen für die Geometrie-Realisierung werden auf einem Quad Core-Computer mit einer integrierten DirectX11-Grafikkarte aufgenommen. Die Messungen variieren je nach Computerkonfiguration.

 

In diesem Abschnitt wird veranschaulicht, wie die Startzeit, die CPU- und GPU-Zeit pro Framemessungen gemessen werden. Sie können eine Leistungsablaufverfolgung für dasselbe Beispiel auf Ihrem Computer erfassen und die Unterschiede in den verschiedenen Messungen sehen.

Um die Ablaufverfolgung in GPUView zu analysieren, öffnen Sie die Datei "merged.elt" mithilfe vonGPUView.exe.

Startzeit

Die Startzeit wird durch die Gesamtzeit gemessen, die von der App gestartet wird, bis der Inhalt zuerst auf dem Bildschirm angezeigt wird.

Die Startzeitmessung wird am besten durchgeführt, indem Sie die im vorherigen Abschnitt aufgeführten Schritte mit diesen Variationen ausführen:

• Wenn Sie die Startmessungen zum ersten Mal durchführen, wenn Sie die App starten, wird sie als kalter Start bezeichnet. Dies kann von Messungen variieren, die nach dem Starten der App einige Male in einer kleinen Zeitdauer durchgeführt wurden. Dies wird als warmer Start bezeichnet. Je nachdem, wie viele Ressourcen eine App beim Start erstellt, kann es einen großen Unterschied zwischen den beiden Startzeiten geben. Je nach App-Zielen kann es wünschenswert sein, eine oder andere zu messen.
• Wenn Sie Leistungsinformationen protokollieren, beenden Sie die App, sobald der erste Frame auf dem Bildschirm angezeigt wird.

Berechnen der Startzeit mithilfe von GPUView

1. Scrollen Sie in GPUView nach unten zum relevanten Prozess, in diesem Fall GeometryRealization.exe.

   

2. Die Kontext-CPU-Warteschlange stellt die Grafikauslastung dar, die auf der Hardware in die Warteschlange gestellt wird, aber nicht unbedingt von der Hardware verarbeitet wird. Wenn die Ablaufverfolgungsdatei geöffnet wird, werden alle Ereignisse angezeigt, die zwischen dem Zeitpunkt der Ablaufverfolgung protokolliert wurden. Um die Startzeit zu berechnen, wählen Sie den interessanten Bereich aus, zoomen Sie in den ersten Teil der ersten Kontext-CPU-Warteschlange (dies ist dies die Aktivität) mit STRG+Z. Weitere Informationen zu GPUView-Steuerelementen finden Sie im Abschnitt "Zusammenfassung der GPUView-Steuerelemente". Die folgende Abbildung zeigt nur den GeometryRealization.exe Prozess, der in den ersten Teil der Kontext-CPU-Warteschlange vergrößert wurde. Die Farbe der Kontext-CPU-Warteschlange wird durch das Rechteck direkt unterhalb der Warteschlange und dieselben Farbdatenpakete in der Warteschlange angezeigt, dass GPU-Arbeit auf der Hardware in die Warteschlange eingereiht wird. Das Schlupfmusterpaket in der Kontextwarteschlange zeigt das aktuelle Paket an, was bedeutet, dass die App den Inhalt auf dem Bildschirm präsentieren möchte.

   

3. Die Startzeit ist die Zeit, zu der die App zum ersten Mal startet (in diesem Fall benutzeroberflächenthread-Einstiegspunktmodul SHCORE.dll), bis der Kontext zum ersten Mal angezeigt wird (gekennzeichnet durch ein Schlupfpaket). Die Abbildung hier zeigt den Bereich des Interesses.

   Hinweis

   Die tatsächlichen aktuellen Informationen werden in der Flip-Warteschlange dargestellt und damit der Zeitaufwand verlängert, bis das aktuelle Paket tatsächlich in der Flip-Warteschlange abgeschlossen ist.

    

   Die vollständige Statusleiste ist in der Abbildung unten nicht sichtbar, in der auch die verstrichene Zeit zwischen den hervorgehobenen Teilen angezeigt wird. Dies ist die Startzeit der App. In diesem Fall für die oben erwähnte Maschine kam es zu ca. 240ms.

   

CPU- und GPU-Zeit pro Frame

Es gibt ein paar Dinge, die beim Messen der CPU-Zeit zu berücksichtigen sind. Suchen Sie nach den Bereichen in der Ablaufverfolgung, in denen Sie das zu analysierende Szenario ausgeübt haben. Im Beispiel für die Geometrie-Realisierung ist beispielsweise eines der Szenarien, die analysiert wurden, der Übergang zwischen Rendern von 2048- 8192-Grundtypen, alle nicht realisiert (wie in, Geometrie wird nicht jeden Frame getesselliert). Die Ablaufverfolgung zeigt deutlich den Unterschied in der CPU- und GPU-Aktivität vor und nach dem Übergang in der Anzahl der Grundtypen.

Zwei Szenarien werden analysiert, um CPU- und GPU-Zeit pro Frame zu berechnen. Sie sind wie folgt.

• Übergang von rendering 2048 nicht realisierten Grundtypen zu 8192 nicht realisierten Grundtypen.
• Der Übergang von Rendering 8192 realisierte Grundtypen auf 8192 nicht realisierte Grundtypen.

In beiden Fällen wurde festgestellt, dass die Framerate drastisch gesunken ist. Die Messung der CPU- und GPU-Zeit, die Beziehung zwischen den beiden und ein paar anderen Mustern in der Ablaufverfolgung kann nützliche Informationen zu problematischen Bereichen in der App geben.

Berechnen der CPU- und GPU-Zeit, wenn 2048 Grundtypen nicht realisiert werden

1. Öffnen Sie die Ablaufverfolgungsdatei mit GPUView.exe.

2. Scrollen Sie nach unten zum GeometryRealization.exe Prozess.

3. Wählen Sie einen Bereich zum Berechnen der CPU-Zeit aus, und zoomen Sie ihn mithilfe von STRG+Z.

   

4. Anzeigen von V-Synchronisierungsinformationen durch Umschalten zwischen F8. Halten Sie das Zoomen, bis es einfach ist, einen vsync-Wert von Daten klar zu sehen. Die blauen Linien sind die v-Synchronisierungszeiten. In der Regel treten diese einmal alle 16 ms (60 fps) auf, aber wenn DWM ein Leistungsproblem auftritt, wird es langsamer ausgeführt, sodass sie einmal alle 32 ms (30 fps) auftreten. Um ein Zeitgefühl zu erhalten, wählen Sie aus einer blauen Leiste zum nächsten aus, und sehen Sie sich dann die Anzahl von ms an, die in der unteren rechten Ecke des GPUView-Fensters gemeldet wurde.

   

5. Um die CPU-Zeit pro Frame zu messen, messen Sie die Zeitdauer aller Threads, die beim Rendern beteiligt sind. Es kann sich lohnen, den Thread einzugrenzen, der voraussichtlich von einer Leistungssicht aus am relevantesten ist. Beispielsweise im Beispiel zur Geometrie-Realisierung wird der Inhalt animiert und muss auf dem Bildschirm jeden Frame gerendert werden, der den UI-Thread zum wichtigen Thread macht. Sobald Sie bestimmen, welcher Thread betrachtet werden soll, messen Sie die Länge der Balken auf diesem Thread. Ein paar dieser Ergibt CPU-Zeit pro Frame. Die folgende Abbildung zeigt zeitaufwendigend im UI-Thread. Es zeigt auch, dass diese Zeit gut zwischen zwei aufeinander folgenden v-Synchronisierungen passt, was bedeutet, dass es auf 60FPS trifft.

   

   Sie können auch überprüfen, indem Sie die Flip-Warteschlange für den entsprechenden Zeitrahmen betrachten, der zeigt, dass DWM jeden Frame präsentieren kann.

   

6. Die GPU-Zeit kann auf die gleiche Weise wie die CPU-Zeit gemessen werden. Zoomen Sie in den relevanten Bereich, wie bei der Messung der CPU-Zeit. Messen Sie die Länge der Balken in der GPU-Hardwarewarteschlange mit derselben Farbe wie die Farbe der Kontext-CPU-Warteschlange. Solange die Balken in aufeinander folgende v-Synchronisierungen passen, wird die App bei 60FPS reibungslos ausgeführt.

   

Berechnen der CPU- und GPU-Zeit, wenn 8192 Grundtypen nicht realisiert werden

1. Wenn Sie die gleichen Schritte erneut ausführen, zeigt die Ablaufverfolgung, dass alle CPU-Arbeiten für einen Frame nicht zwischen einer v-Synchronisierung und der nächsten passen. Dies bedeutet, dass die App CPU-gebunden ist. Der UI-Thread sättigungt die CPU.

   

   Wenn Sie die Flip-Warteschlange betrachten, ist auch klar, dass DWM nicht in der Lage ist, jeden Frame darzustellen.

   

2. Um zu analysieren, wo die Zeit ausgegeben wird, öffnen Sie die Ablaufverfolgung in XPerf. Um die Startzeit in XPerf zu analysieren, suchen Sie zuerst das Zeitintervall in GPUView. Maus über die linke Seite des Intervalls und der rechten Seite und notieren Sie sich die absolute Zeit, die unten im GPUView-Fenster angezeigt wird. Öffnen Sie dann die gleiche ETL-Datei in XPerf , und scrollen Sie nach unten zum Diagramm "CPU Sampling by CPU", klicken Sie mit der rechten Maustaste, und wählen Sie "Intervall auswählen..." aus. Dies ermöglicht die Eingabe im Intervall des Interesses, das durch die Suche nach der GPU-Ablaufverfolgung ermittelt wurde.

   

3. Wechseln Sie zum Menü "Ablaufverfolgung", und stellen Sie sicher, dass "Symbole laden" aktiviert ist. Wechseln Sie auch zur Ablaufverfolgung –> Konfigurieren von Symbolpfaden, und geben Sie den App-Symbolpfad ein. Eine Symboldatei enthält Debuginformationen zu einer kompilierten ausführbaren Datei in einer separaten Datenbank (PDB). Diese Datei wird häufig als PDB bezeichnet. Weitere Informationen zu Symboldateien finden Sie hier: Symboldateien. Diese Datei kann sich im Ordner "Debug" des App-Verzeichnisses befinden.

4. Um die Aufschlüsselung der Zeit, die in der App verbracht wird, abzurufen, klicken Sie mit der rechten Maustaste auf das im vorherigen Schritt ausgewählte Intervall, und klicken Sie auf "Zusammenfassungstabelle". Um einen Überblick darüber zu erhalten, wie viel Zeit in jeder DLL ausgegeben wird, deaktivieren Sie "Stapel" im Menü "Spalten". Beachten Sie, dass die Spalte "Anzahl" hier zeigt, wie viele Beispiele in der angegebenen DLL/Funktion enthalten sind. Da ungefähr ein Beispiel pro Ms genommen wird, kann diese Zahl als beste Schätzung verwendet werden, um zu ermitteln, wie viel Zeit in jeder DLL/Funktion aufgewendet wird. Das Überprüfen des Menüs "Stapel" aus dem Menü "Spalten" gibt den inklusiven Zeitaufwand für jede Funktion im Aufrufdiagramm. Dies wird dazu beitragen, die Problempunkte weiter aufzuschlüsseln.

5. Stapelablaufverfolgungsinformationen für unrealisierte Grundtypen von 2048 zeigen, dass 30 % der CPU-Zeit im Geometrie-Realisierungsprozess aufgewendet werden. Davon werden rund 36 % der Zeit in Geometrie tessellation und Streichen verbracht.

6. Stapelablaufverfolgungsinformationen für unrealisierte Grundtypen von 8192 zeigen, dass rund 60 % der CPU-Zeit (4 Kerne) in der Geometrie-Realisierung ausgegeben werden.

   

Berechnen der CPU-Zeit beim Rendern von 8192-Grundtypen

Es ist aus den Profilen klar, dass die App CPU-gebunden ist. Um die von der CPU aufgewendete Zeit zu verringern, können Geometrien einmal erstellt und zwischengespeichert werden. Der zwischengespeicherte Inhalt kann jeden Frame gerendert werden, ohne dass die Kosten für die Geometrie-Tessellation pro Frame entstehen. Wenn Sie die Ablaufverfolgung in GPUView für den realisierten Teil der App betrachten, ist klar, dass DWM jeden Frame präsentieren kann und die CPU-Zeit drastisch reduziert wurde.

Der erste Teil des Diagramms zeigt realisierte 8192-Grundtypen. Die entsprechende CPU-Zeit pro Frame kann in zwei aufeinander folgende v-Synchronisierungen passen. Im späteren Teil des Diagramms ist dies nicht wahr.

Wenn Sie in XPerf suchen, sitzt DIE CPU für die längste Zeit, wobei nur etwa 25 % der CPU-Zeit für die Geometrie-Realisierungs-App aufgewendet wird.

Zusammenfassung

Sowohl GPUView als auch XPerf und leistungsstarke Tools zur Analyse der Leistung von DirectX-Apps. Dieser Artikel ist ein Primer für die Verwendung dieser Tools und grundlegende Leistungsmessungen und App-Merkmale. Neben dem Verständnis der Verwendung von Tools ist es zunächst wichtig, die analysierte App zu verstehen. Beginnen Sie mit der Suche nach Antworten auf Fragen wie dem, was die App zu erreichen versucht? Welche Threads im System sind am wichtigsten? Welche Trade-Offs sind Sie bereit, zu machen? Beginnen Sie bei der Analyse von Leistungsablaufverfolgungen mit dem Blick auf offensichtlich problematische Orte. Ist die App CPU oder GPU gebunden? Kann die App jeden Frame präsentieren? Tools zusammen mit einem Verständnis der App können sehr nützliche Informationen zum Verständnis, zum Suchen und Schließlich zur Lösung von Leistungsproblemen geben.