Delen via


DirectX-apps profileren

Hier ziet u hoe u enkele van de belangrijkste prestatietijdmetingen voor een DirectX--app kunt meten met behulp van de XPerf- en GPUView--hulpprogramma's die als onderdeel van de Windows Performance Toolkit worden verzonden. Dit is geen uitgebreide handleiding voor het begrijpen van de hulpprogramma's, in plaats van hun specifieke toepasbaarheid voor het analyseren van de prestaties van DirectX-apps. Hoewel de meeste technieken die hier worden besproken relevant zijn voor alle DirectX-apps, is het het meest relevant voor apps die wisselketens gebruiken en niet voor DirectX-toepassingen die gebruikmaken van SIS/VSIS- en XAML-animaties. We begeleiden u bij belangrijke prestatietijdmetingen, het verkrijgen en installeren van de hulpprogramma's, en het uitvoeren van traceringen voor prestatiemetingen om ze te analyseren om inzicht te krijgen in app-knelpunten.

Over de hulpprogramma's

XPerf

XPerf- is een set hulpprogramma's voor prestatieanalyse die zijn gebouwd op basis van Event Tracing for Windows (ETW) die is ontworpen voor het meten en analyseren van gedetailleerde systeem- en app-prestaties en resourcegebruik. Vanaf Windows 8 heeft dit opdrachtregelprogramma een grafische gebruikersinterface en wordt de Windows Performance Recorder (WPR) en Windows Performance Analyzer (WPA) genoemd. Meer informatie over deze hulpprogramma's vindt u op de webpagina voor Windows Performance Toolkit (WPT): Windows Performance Toolkit.

Een ETW verzamelt aangevraagde kernelgebeurtenissen en slaat deze op in een bestand met de naam een ETL-bestand (Event Trace Log). Deze kernel-gebeurtenissen bieden uitgebreide informatie over een app en systeemkenmerken bij het uitvoeren van de app. Gegevens worden verzameld door traceringsopname in te schakelen, het gewenste app-scenario uit te voeren dat analyse nodig heeft, waardoor de opname wordt gestopt waarmee de gegevens in een ETL-bestand worden opgeslagen. Vervolgens kunt u het bestand op dezelfde of een andere computer analyseren met behulp van het opdrachtregelprogramma xperf.exe of het hulpprogramma voor visuele traceringsanalyse xperfview.exe.

GPUView

GPUView- is een ontwikkelhulpprogramma voor het bepalen van de prestaties van de grafische verwerkingseenheid (GPU) en CPU. Er wordt gekeken naar prestaties met betrekking tot DMA-bufferverwerking (Direct Memory Access) en alle andere videoverwerking op de videohardware.

Voor DirectX--apps die sterk afhankelijk zijn van de GPU, is GPUView- een krachtig hulpmiddel voor het begrijpen van de relatie tussen werk dat wordt uitgevoerd op de CPU versus GPU. Zie voor meer informatie over GPUViewGPUView gebruiken.

Net als XPerf-wordt eerst een ETW-trace gemaakt door de tracedienst te starten, het scenario dat analyse vereist voor de betreffende app uit te voeren, de dienst te stoppen en de informatie op te slaan in een ETL-bestand. GPUView- geeft de gegevens weer die aanwezig zijn in het ETL-bestand in een grafische indeling.

Na de installatie van het hulpprogramma GPUView, wordt u aangeraden het onderwerp 'GPUView'Main Display' te lezen onder het menu 'GPUView Help'. Het bevat nuttige informatie over het interpreteren van de GPUView UI.

De hulpprogramma's installeren

Zowel XPerf- als GPUView- zijn opgenomen in de Windows Performance Toolkit (WPT).

XPerf- wordt geleverd als onderdeel van de Windows Software Development Kit (SDK) voor Windows. Download de Windows SDK.

GPUView- is beschikbaar in de Windows Assessment and Deployment Kit (Windows ADK). Download de Windows ADK.

Na de installatie moet u de mappen met XPerf- en GPUView- toevoegen aan de variabele Pad van het systeem.

Klik op de knop Start en typ 'Systeemvariabelen'. Het venster Systeemeigenschappen wordt geopend. Klik op 'Bewerk de omgevingsvariabelen van het systeem'. Selecteer 'Omgevingsvariabelen' in het dialoogvenster Systeemeigenschappen. De variabele Pad vindt u onder Systeemvariabelen. Voeg de map met xperf.exe en GPUView.exe toe aan het pad. Deze uitvoerbare bestanden vindt u in de map 'Windows Performance Toolkit' in de 'Windows Kits'. De standaardlocatie is: C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit.

Prestatietijdmetingen

De meeste apps verwachten soepel te werken en reageren op gebruikersinvoer. Afhankelijk van het gewenste scenario kan het ene aspect van de prestaties echter belangrijker zijn dan een ander aspect. Voor een nieuwslezer-app die wordt uitgevoerd op een tablet-pc met aanraakbediening, is het belangrijkste aspect bijvoorbeeld om één artikel tegelijk te bekijken en om hetzelfde of een ander artikel te pannen/zoomen/bladeren. In dit scenario is de mogelijkheid om alle inhoud elk frame weer te geven niet nodig. De mogelijkheid om door het artikel te schuiven tijdens een aanraakbeweging is echter uiterst belangrijk.

In een ander geval zorgen een game of een videorenderings-app die gebruikmaken van veel animaties voor haperingen als frames worden overgeslagen. In dit geval is de mogelijkheid om inhoud op het scherm te presenteren zonder onderbreking van gebruikersinvoer uiterst belangrijk.

Om te begrijpen welk deel van de app problematisch is, is de eerste stap het bepalen van de belangrijkste scenario's. Zodra de belangrijkste aspecten van de app worden begrepen en hoe ze worden uitgevoerd, wordt het zoeken naar problemen met het gebruik van de hulpprogramma's eenvoudiger.

Enkele van de meest voorkomende metrische prestatietijdgegevens zijn als volgt:

Opstarttijd

De tijd gemeten vanaf het starten van het proces tot het moment dat de eerste weergave op het scherm verschijnt. Deze meting is handiger wanneer het systeem warm is, wat betekent dat de meting wordt uitgevoerd nadat de app een paar keer is gestart.

CPU-tijd per frame

De tijd waarvoor cpu de app-workload actief verwerkt voor één frame. Als de app soepel draait, vindt alle verwerking die nodig is voor één frame plaats binnen één v-sync interval. Met de monitorvernieuwingsfrequentie van 60Hz komt dit tot 16 ms per frame. Als de CPU-tijd per frame groter is dan 16 ms, kunnen CPU-optimalisaties nodig zijn om een vloeiende app-ervaring te bieden.

GPU-tijd per frame

De tijd waarvoor GPU de app-workload actief verwerkt voor één frame. Een app is GPU gebonden wanneer de tijd die nodig is om een frame aan gegevens te verwerken meer dan 16 ms is.

Als u weet of een app CPU- of GPU-gebonden is, wordt het problematische deel van de code beperkt.

Opnemen van prestatietijdmetingenspoor

Voer deze stappen uit om een tracering uit te voeren:

  1. Open een opdrachtvenster als beheerder.
  2. Sluit de app als deze al draait.
  3. Wijzig mappen in de map gpuview map in de map Windows Performance Toolkit.
  4. Typ 'log.cmd' om gebeurtenistracering te starten. Met deze optie worden de meest interessante gebeurtenissen geregistreerd. Andere beschikbare opties registreren een ander bereik van de gebeurtenissen. Met de modus 'v' ofwel de uitgebreide logmodus worden bijvoorbeeld alle gebeurtenissen geregistreerd waarvan GPUView op de hoogte is.
  5. Start het voorbeeld en oefen het voorbeeld uit op een manier die betrekking heeft op het prestatiepad dat u moet analyseren.
  6. Ga terug naar de opdrachtvensters en typ opnieuw 'log.cmd' om de logboekregistratie te stoppen.
  7. Hiermee wordt een bestand met de naam 'merged.etl' uitgevoerd in de map gpuview. U kunt dit bestand opslaan op een andere locatie en u kunt het op dezelfde of een andere computer analyseren. Sla het symboolbestand (.pdb) dat aan de app is gekoppeld, op om de details van stack capture weer te geven.

Metingen

Notitie

De metingen voor geometrierealisatievoorbeelden worden uitgevoerd op een Quad Core-machine met een geïntegreerde DirectX11-grafische kaart. De metingen variëren, afhankelijk van de configuratie van de machine.

 

In deze sectie wordt gedemonstreerd hoe u de opstarttijd, CPU- en GPU-tijd per frame meet. U kunt een prestatietracering vastleggen voor hetzelfde voorbeeld op uw computer en de verschillen in de verschillende metingen bekijken.

Als u de tracering in GPUView-wilt analyseren, opent u het bestand 'merged.elt' met behulp van GPUView.exe.

Opstarttijd

De opstarttijd wordt gemeten door de totale tijd die vanaf de app is besteed totdat de inhoud eerst op het scherm wordt weergegeven.

De opstarttijdmeting wordt het beste uitgevoerd door de stappen uit de vorige sectie te volgen met deze variaties:

  • Als u de opstartmetingen neemt de eerste keer dat u de app start, wordt dit een 'cold startup' genoemd. Dit kan variëren van metingen die zijn genomen nadat u de app een paar keer hebt gestart in een korte tijdsduur. Dit wordt warm opstarten genoemd. Afhankelijk van het aantal resources dat een app bij het starten maakt, kan er een groot verschil zijn tussen de twee opstarttijden. Afhankelijk van app-doelen kan het meten van een of de andere wenselijk zijn.
  • Wanneer u prestatiegegevens registreert, beëindigt u de app zodra het eerste frame op het scherm wordt weergegeven.

Opstarttijd berekenen met behulp van GPUView-

  1. Schuif in GPUView-omlaag naar het relevante proces, in dit geval GeometryRealization.exe.

    Schermopname met een voorbeeld van processen in GPUView.

  2. De context-CPU-wachtrij vertegenwoordigt de grafische workload die in de wachtrij staat voor de hardware, maar niet noodzakelijkerwijs door de hardware wordt verwerkt. Wanneer het traceringsbestand wordt geopend, worden alle gebeurtenissen weergegeven die zijn geregistreerd tussen de tijd dat de tracering is uitgevoerd. Als u de opstarttijd wilt berekenen, selecteert u het interessegebied, zoomt u in op het eerste gedeelte van de eerste context-CPU-wachtrij (dit is de wachtrij die activiteit weergeeft) met Ctrl +Z. Meer informatie over GPUView-besturingselementen vindt u in de sectie GPUView Help-bestand 'Samenvatting van GPUView Besturingselementen'. In de onderstaande afbeelding ziet u alleen het GeometryRealization.exe-proces dat is ingezoomd op het eerste deel van de Context-CPU-wachtrij. De kleur van de CPU-wachtrij wordt aangeduid door de rechthoek direct onder de wachtrij en gegevenspakketten van dezelfde kleur in de wachtrij tonen dat GPU-werk in de wachtrij op de hardware staat. Het hatch-patroonpakket in de contextwachtrij toont het huidige pakket, wat inhoudt dat de app wil dat de hardware de inhoud op het scherm weergeeft.

    Schermopname met voorbeelden van de context-C P U-wachtrij.

  3. De opstarttijd is het tijdstip waarop de app voor het eerst wordt gestart (in dit geval ui thread entry point module SHCORE.dll) tot de tijd dat de context voor het eerst wordt weergegeven (gemarkeerd door een hatch-pakket). De afbeelding hier markeert het interessegebied.

    Notitie

    De actuele informatie wordt weergegeven in de flipwachtrij en de tijd die nodig is, wordt dus verlengd totdat het huidige pakket daadwerkelijk is voltooid in de flipwachtrij.

     

    De volledige statusbalk is niet zichtbaar in de onderstaande afbeelding, waarin ook de verstreken tijd tussen de gemarkeerde gedeelten wordt weergegeven. Dit is de opstarttijd van de app. Bij de eerdergenoemde machine bleek dit ongeveer 240 ms te zijn.

    Schermopname van interessegebieden met betrekking tot opstarttijd in de context-C P U-wachtrij.

CPU- en GPU-tijd per frame

Er zijn enkele dingen die u moet bedenken bij het meten van DE CPU-tijd. Zoek naar de gebieden in de trace waar u het scenario hebt uitgevoerd om te worden geanalyseerd. In het voorbeeld van de geometrierealisatie is een van de scenario's die zijn geanalyseerd bijvoorbeeld de overgang tussen het weergeven van 2048 en 8192 primitieve vormen, die allemaal niet zijn gerealiseerd (dat wil zeggen, de geometrie wordt niet elke frame opgedeeld). De tracering toont duidelijk het verschil in CPU- en GPU-activiteit vóór en na de overgang in het aantal primitieven.

Er worden twee scenario's geanalyseerd om de CPU- en GPU-tijd per frame te berekenen. Ze zijn als volgt.

  • Overstappen van het weergeven van 2048 niet-gerealiseerde primitieven naar 8192 niet-gerealiseerde primitieven.
  • Overgang van weergave van 8192 gerealiseerde primitieven naar 8192 niet-gerealiseerde primitieven.

In beide gevallen werd vastgesteld dat de framesnelheid drastisch daalde. Het meten van de CPU- en GPU-tijd, de relatie tussen de twee en enkele andere patronen in de trace kan nuttige informatie geven over problematische gebieden in de app.

De tijd voor de CPU en GPU berekenen wanneer 2048 primitieve elementen onverwezenlijkt worden gerenderd.

  1. Open het traceringsbestand met behulp van GPUView.exe.

  2. Schuif omlaag naar het GeometryRealization.exe proces.

  3. Selecteer een gebied voor het berekenen van de CPU-tijd en zoom erop in met Ctrl+Z.

    Schermopname van een gebied dat is geselecteerd voor het berekenen van de C P U-tijd in de context-CPU-wachtrij.

  4. V-synchronisatiegegevens weergeven door tussen F8 te schakelen. Blijf inzoomen totdat het gemakkelijk is om één vsync aan gegevens duidelijk te zien. De blauwe lijnen geven de plaats aan waar de v-synchronisatiemomenten zijn. Deze treden meestal één keer per 16 ms (60 fps) op, maar als DWM een prestatieprobleem ondervindt, wordt deze langzamer uitgevoerd, zodat ze eenmaal per 32 ms (30 fps) optreden. Als u een idee van tijd wilt krijgen, selecteert u een blauwe balk naar de volgende en kijkt u vervolgens naar het aantal ms dat in de rechterbenedenhoek van het GPUView-venster wordt gerapporteerd.

    Schermopname van een voorbeeld van v-synchronisatietijden.

  5. Als u de CPU-tijd per frame wilt meten, meet u de tijdsduur die nodig is voor alle threads die betrokken zijn bij het weergeven. Het kan de moeite waard zijn om de thread te beperken die naar verwachting het meest relevant is vanuit het oogpunt van prestaties. In het voorbeeld van de geometrierealisatie is de inhoud een animatie en moet elke frame op het scherm worden weergegeven, waardoor de UI-thread de belangrijkste is. Zodra u hebt bepaald welke thread u wilt bekijken, meet u de lengte van de balken op deze thread. Het gemiddelde van een aantal hiervan levert CPU-tijd per frame op. In de onderstaande afbeelding ziet u de tijd die nodig is voor de gebruikersinterface-thread. Het laat ook zien dat deze tijd goed past tussen twee opeenvolgende v-synchronisaties, wat betekent dat het 60FPS bereikt.

    Schermopname die de tijd laat zien die in beslag wordt genomen door de UI-thread.

    U kunt ook controleren door naar de flipwachtrij te kijken voor het bijbehorende tijdsbestek, waarin wordt aangegeven dat DWM elk frame kan presenteren.

    Schermopname waarin een voorbeeld van de 'Flip Queue' wordt getoond.

  6. De GPU-tijd kan op dezelfde manier worden gemeten als de CPU-tijd. Zoom in op het relevante gebied, zoals bij het meten van de CPU-tijd. Meet de lengte van de balken in de GPU-hardwarewachtrij met dezelfde kleur als de kleur van de context-CPU-wachtrij. Zolang de grafieken binnen opeenvolgende v-synchronisaties passen, draait de app soepel met 60 frames per seconde.

    Schermopname die een voorbeeld toont van de 'GPU-hardwarewachtrij' die informatie weergeeft dat een app draait op 60 F P S.

Cpu- en GPU-tijd berekenen wanneer 8192 ongerealiseerde primitieven worden gerenderd

  1. Als u dezelfde stappen opnieuw uitvoert, ziet u dat al het CPU-werk voor één frame niet past tussen één v-sync en de volgende. Dit betekent dat de app cpu-afhankelijk is. De UI-thread zorgt voor verzadiging van de CPU.

    Schermopname die een voorbeeld toont van de UI-thread die de C P U verzadigt.

    Bij het kijken naar de flipwachtrij is het ook duidelijk dat DWM niet in staat is om elk frame weer te geven.

    Schermopname die een voorbeeld laat zien van het D W M dat niet elk frame kan presenteren.

  2. Als u wilt analyseren waar de tijd wordt besteed, opent u de trace in XPerf. Als u opstarttijd in XPerf-wilt analyseren, zoekt u eerst het tijdsinterval in GPUView-. Beweeg de muis over de linkerkant van het interval en de rechterkant en noteer de absolute tijd die wordt weergegeven onder aan het GPUView-venster. Open vervolgens hetzelfde .etl-bestand in XPerf- en scroll naar de grafiek 'CPU-steekproeven per CPU', klik met de rechtermuisknop en selecteer "Selecteer interval…". Hierdoor kunt u het gewenste interval invoeren dat is gevonden door de GPU-tracering te bekijken.

    Schermopname die 'C P U sampling by C P U' laat zien in 'Windows Performance Analysis'.

  3. Ga naar het menu Traceren en controleer of 'Symbolen laden' is ingeschakeld. Ga ook naar Trace ->, configureer symboolpaden en typ het appsymboolpad in. Een symboolbestand bevat foutopsporingsinformatie van een gecompileerd uitvoerbaar bestand in een afzonderlijke database (.pdb). Dit bestand wordt meestal een PDB genoemd. Meer informatie over symboolbestanden vindt u hier: Symboolbestanden. Dit bestand kan zich in de map Foutopsporing van de app-map bevinden.

  4. Als u wilt uitsplitsen waar de tijd in de app wordt besteed, klikt u met de rechtermuisknop op het interval dat u in de vorige stap hebt geselecteerd en klikt u op Samenvattingstabel. Als u een overzicht wilt krijgen van de hoeveelheid tijd die in elke dll wordt besteed, schakelt u 'Stack' uit in het menu Kolommen. In de kolom Aantal ziet u hoeveel voorbeelden zich in de opgegeven dll/functie bevinden. Omdat er ongeveer één steekproef per ms wordt genomen, kan dit getal worden gebruikt als een schatting van de hoeveelheid tijd die in elke dll/functie wordt besteed. Door de optie 'Stack' in het menu Kolommen te selecteren, krijgt u de totale tijd die in elke functie in de aanroepgrafiek is besteed. Dit helpt bij het verder opsplitsen van de probleempunten.

  5. Stack trace-informatie voor 2048 niet-gerealiseerde primitieve elementen onthult dat 30% van de CPU-tijd wordt besteed aan het proces van geometrie-realisatie. Van dat wordt ongeveer 36% van de tijd besteed aan geometrie-tessellatie en het trekken van lijnen.

  6. Stack traceerinformatie voor 8192 onverwezenlijkte primitieven onthult dat ongeveer 60% van de CPU-tijd (4 kernen) wordt besteed aan de geometrieberekening.

    Schermafbeelding die stacktraceringsinformatie voor C P U-tijd toont.

Cpu-tijd berekenen wanneer 8192 primitieven worden gegenereerd

Het is duidelijk uit de profielen dat de app CPU-afhankelijk is. Om de tijd die door de CPU wordt besteed, te verminderen, kunnen geometrieën eenmaal worden gemaakt en in de cache worden opgeslagen. De inhoud in de cache kan elk frame worden weergegeven zonder dat de kosten voor geometrische tessellatie per frame in rekening worden gebracht. Bij het bekijken van de tracering in GPUView voor het gerealiseerde deel van de app, is het duidelijk dat DWM elk frame kan presenteren en dat de CPU-tijd drastisch is verminderd.

Schermopname van een voorbeeld van een tracering in GPUView waarin D W M elk frame kan presenteren.

Het eerste deel van de grafiek toont gerealiseerde 8192 primitieven. De bijbehorende CPU-tijd per frame kan binnen twee opeenvolgende v-synchronisaties passen. In het latere deel van de grafiek is dit niet waar.

Als je in XPerfkijkt, is de CPU de meeste tijd inactief, met slechts ongeveer 25% van de CPU-tijd besteed aan de app voor geometriëweergave.

gpuview-schermopname.

Samenvatting

Zowel GPUView- als XPerf- en krachtige hulpprogramma's voor het analyseren van de prestaties van DirectX--apps. Dit artikel is een inleiding tot het gebruik van deze hulpprogramma's en het begrijpen van basisprestatiemetingen en app-kenmerken. Afgezien van het begrijpen van het gebruik van hulpprogramma's, is het eerst belangrijk om inzicht te krijgen in de app die wordt geanalyseerd. Begin met het vinden van antwoorden op vragen zoals wat de app probeert te bereiken? Welke threads in het systeem zijn het belangrijkst? Welke compromissen ben je bereid om te doen? Bij het analyseren van prestatietraceringen begint u met het bekijken van duidelijke problematische plaatsen. Is de CPU of GPU van de app gebonden? Kan de app elk frame presenteren? Hulpprogramma's samen met een goed begrip van de app kunnen zeer nuttige informatie geven bij het begrijpen, vinden en oplossen van prestatieproblemen.