Profilering av DirectX-appar

Detta visar hur du mäter några av de viktigaste prestandatidsmåtten för en DirectX--app med hjälp av XPerf- och GPUView- verktyg som levereras som en del av Windows Performance Toolkit. Detta är inte en omfattande guide för att förstå verktygen, snarare deras specifika tillämplighet för att analysera DirectX-appprestanda. De flesta av de tekniker som beskrivs här är relevanta för alla DirectX-appar, men det är mest relevant för appar som använder växlingskedjor och inte för DirectX-program som bygger på XAML som använder SIS/VSIS- och XAML-animeringar. Vi vägleder dig genom viktiga prestandatidsmätningar, hur du hämtar och installerar verktygen och tar spårningar av prestandamätningar och analyserar dem för att förstå flaskhalsar i appen.

Om verktygen

XPerf

XPerf är en uppsättning verktyg för prestandaanalys som bygger på händelsespårning för Windows (ETW) som är utformade för att mäta och analysera detaljerad system- och appprestanda och resursanvändning. Från och med Windows 8 har det här kommandoradsverktyget ett grafiskt användargränssnitt och kallas WINDOWS Performance Recorder (WPR) och Windows Performance Analyzer (WPA). Mer information om dessa verktyg finns på webbsidan för Windows Performance Toolkit (WPT): Windows Performance Toolkit.

En ETW samlar in begärda kernelhändelser och sparar dem i en fil som kallas en ETL-fil (Event Trace Log). Dessa kernelhändelser ger omfattande information om en app och systemegenskaper när du kör appen. Data samlas in genom att aktivera spårningsinsamlingen, utföra det önskade appscenariot som behöver analyseras och stoppa inspelningen, vilket sparar data i en ETL-fil. Du kan sedan analysera filen på samma eller en annan dator med hjälp av kommandoradsverktyget xperf.exe eller verktyget för visuell spårningsanalys xperfview.exe.

GPUView

GPUView är ett utvecklingsverktyg för att fastställa prestanda för grafikprocessorn (GPU) och CPU. Den tittar på prestanda när det gäller direkt minnesåtkomst (DMA) buffertbearbetning och all annan videobearbetning på videomaskinvaran.

För DirectX- appar som är starkt beroende av GPU:n är GPUView- ett kraftfullt verktyg för att förstå relationen mellan arbete som utförs på PROCESSOR jämfört med GPU. Mer information om GPUViewfinns i Using GPUView.

På samma sätt som XPerftas först en ETW-spårning genom att starta spårningstjänsten, använda scenariot som behöver analyseras för den aktuella appen, stoppa tjänsten och spara informationen i en ETL-fil. GPUView visar data som finns i ETL-filen i ett grafiskt format.

När du har installerat verktyget GPUView rekommenderar vi att du läser avsnittet "GPUView's Main Display" under menyn "GPUView Help". Den innehåller användbar information om hur du tolkar användargränssnittet för GPUView.

Installera verktygen

Både XPerf och GPUView ingår i Windows Performance Toolkit (WPT).

XPerf levereras som en del av Windows Software Development Kit (SDK) för Windows. Ladda ned Windows SDK-.

GPUView finns i Windows Assessment and Deployment Kit (Windows ADK). Ladda ned Windows ADK-.

Efter installationen måste du lägga till de kataloger som innehåller XPerf- och GPUView- i systemets sökvägsvariabel.

Klicka på startknappen och skriv "Systemvariabler". Fönstret Systemegenskaper öppnas. Klicka på "Redigera systemmiljövariablerna". Välj "Miljövariabler" i dialogrutan Systemegenskaper. Variabeln "Sökväg" finns under "Systemvariabler". Lägg till katalogen som innehåller xperf.exe och GPUView.exe till sökvägen. Dessa körbara filer finns i katalogen "Windows Performance Toolkit" i "Windows Kits". Standardplatsen är: C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit.

Mått för prestandatid

De flesta appar förväntar sig att köras smidigt och svara på användarindata. Men beroende på vilket scenario du vill ha kan en aspekt av prestanda vara viktigare än en annan. För en nyhetsläsarapp som körs på en surfplatta med pekplatta är till exempel den viktigaste aspekten att visa en enskild artikel i taget och att panorera/zooma/bläddra igenom samma eller en annan artikel. I det här scenariot är det inte nödvändigt att återge allt innehåll varje bildruta. Det är dock mycket viktigt att kunna bläddra igenom artikeln smidigt vid en touchgest.

I ett annat fall kan ett spel eller en videorenderingsapp som använder många animationer få problem om bildrutor tappas bort. I det här fallet är det mycket viktigt att kunna presentera innehåll på skärmen utan interuption från användarindata.

För att förstå vilken del av appen som är problematisk är det första steget att besluta om de viktigaste scenarierna. När de viktigaste aspekterna av appen har förståtts och hur de kommer att utövas blir det enklare att söka efter problem med hjälp av verktygen.

Några av de vanligaste måtten för prestandatid är följande:

Starttid

Tid som mäts från processstart till att först visas på skärmen. Den här mätningen är mer användbar när systemet är varmt, vilket innebär att mätningen görs efter att appen har startats några gånger.

CPU-tid per bildruta

Den tid då processorn aktivt bearbetar apparbetsbelastningen för en bildruta. Om appen körs smidigt sker all bearbetning som krävs för en bildruta inom ett v-synkintervall. Med skärmens uppdateringsfrekvens på 60 Hz motsvarar detta 16 ms per bildruta. Om CPU-tid/ramtid är större än 16 ms kan CPU-optimeringar behövas för att skapa en felfri appupplevelse.

GPU-tid per bildruta

Den tid för vilken GPU aktivt bearbetar apparbetsbelastningen för en bildruta. En app är GPU-bunden när den tid det tar att bearbeta en bildruta med data är mer än 16 ms.

Om du kan förstå om en app är CPU- eller GPU-bunden begränsas den problematiska delen av koden.

Ta en spårning av prestandamätningstid

Utför följande steg för att utföra en spårning:

1. Öppna ett kommandofönster som administratör.
2. Stäng appen om den redan körs.
3. Ändra kataloger till katalogen gpuview i mappen Windows Performance Toolkit.
4. Skriv "log.cmd" för att starta händelsespårning. Det här alternativet loggar de mest intressanta händelserna. Andra tillgängliga alternativ loggar händelser med olika omfattning. Till exempel "v" eller utförligt loggläge registrerar alla händelser som GPUView är medveten om.
5. Starta exemplet och testa det på ett sätt som täcker den prestandabanan som du behöver analysera.
6. Gå tillbaka till kommandofönstren och skriv "log.cmd" igen för att stoppa loggningen.
7. Detta matar ut en fil med namnet "merged.etl" i mappen gpuview. Du kan spara filen på en annan plats och analysera den på samma eller en annan dator. Om du vill visa information om stackinsamling sparar du symbolfilen (.pdb) som är associerad med appen.

Mätningar

Notera

Mätningarna för geometrimätningsexempel görs på en Quad Core-dator med ett integrerat DirectX11-grafikkort. Måtten varierar beroende på datorkonfigurationen.

 

Det här avsnittet visar hur du mäter måtten starttid, CPU och GPU per bildruta. Du kan samla in en prestandaspårning för samma exempel på datorn och se skillnaderna i de olika måtten.

Om du vill analysera spårningen i GPUView-öppnar du filen "merged.elt" med hjälp av GPUView.exe.

Starttid

Starttiden mäts med den totala tid som spenderas från appens start tills innehållet först visas på skärmen.

Mätningen av uppstartstid görs bäst genom att följa stegen i föregående avsnitt med dessa variationer:

• Om du gör startmätningarna första gången du startar appen kallas det kall start. Detta kan variera från mätningar som gjorts efter att du har lanserat appen några gånger om på kort tid. Detta kallas varm start. Beroende på hur många resurser en app skapar vid start kan det vara stor skillnad mellan de två starttiderna. Beroende på appmål kan det vara önskvärt att mäta det ena eller det andra.
• När du loggar prestandainformation, avsluta appen så snart den första bildrutan visas på skärmen.

Beräkna starttid med hjälp av GPUView-

1. I GPUViewrullar du ned till relevant process, i det här fallet GeometryRealization.exe.

   

2. CPU-kontextkö representerar grafikbelastningen som är i kö till maskinvaran, men behöver inte nödvändigtvis bearbetas av maskinvaran. När spårningsfilen öppnas visas alla händelser som loggats mellan den tid då spårningen togs. För att beräkna starttiden väljer du den intressanta regionen och zoomar in i den första delen av den första kontext-CPU-kön (det här är den som visar aktivitet) med Ctrl +Z. Mer information om GPUView Controls finns i avsnittet "Sammanfattning av GPUView Controls" i GPUView Hjälpfilen. Bilden nedan visar bara den zoomade GeometryRealization.exe-processen som fokuserar på den första delen av Context CPU-kön. Färgen på kontext-CPU-kön indikeras av en rektangel precis under kön, och datapaket av samma färg i kön visar GPU-arbete som har köats på maskinvaran. Paketet med schackmönster i kontextkön visar det nuvarande paketet, vilket betyder att appen begär att hårdvaran ska presentera innehållet på skärmen.

   

3. Starttiden är den tid då appen först startar (i det här fallet startpunkten för UI-trådens modul SHCORE.dll) tills kontexten först visas (markerad med ett "hatch-paket"). Bilden här visar intresseområdet.

   Not

   Den faktiska nuvarande informationen representeras i flip-kön och därför tar det längre tid tills det nuvarande paketet faktiskt slutförs i flip-kön.

    

   Det fullständiga statusfältet visas inte i bilden nedan som även visar den förflutna tiden mellan de markerade delarna. Det här är appens starttid. I det här fallet för den dator som nämns ovan kom det ut att vara cirka 240 ms.

   

Cpu- och GPU-tid per bildruta

Det finns några saker att tänka på när du mäter CPU-tid. Leta efter de områden i spårningen där du har tränat scenariot som ska analyseras. I exemplet för geometri är ett av de scenarier som har analyserats övergången mellan att rendera 2048 och 8192 primitiver, alla orealiserade (det vill säga geometri är inte mångkantsupplöst varje bildruta). Spårningen visar tydligt skillnaden i CPU- och GPU-aktivitet före och efter övergången i antalet primitiver.

Två scenarier analyseras för att beräkna cpu- och GPU-tid per bildruta. De är följande.

• Att gå från att återge 2048 orealiserade primitiver till att återge 8192 orealiserade primitiver.
• Att övergå från att återge 8192 realiserade primitiver till 8192 orealiserade primitiver.

I båda fallen observerades att bildfrekvensen sjönk drastiskt. Genom att mäta CPU- och GPU-tid kan relationen mellan de två samt några andra mönster i spårningen ge användbar information om problematiska områden i appen.

Beräkna cpu- och GPU-tid när 2048-primitiver återges orealiserade

1. Öppna spårningsfilen med hjälp av GPUView.exe.

2. Rulla ned till processen GeometryRealization.exe.

3. Välj ett område för beräkning av CPU-tid och zooma in det med CTRL + Z.

   

4. Visa v-sync-information genom att växla mellan F8. Fortsätt att zooma in tills det är lätt att tydligt se en vsync-mängd data. De blå linjerna markerar tidpunkterna för v-synkronisering. Dessa inträffar vanligtvis en gång var 16:e ms (60 fps), men om DWM stöter på ett prestandaproblem går det långsammare så att de inträffar en gång var 32:e ms (30 fps). Om du vill få en känsla av tid väljer du från ett blått fält till nästa och tittar sedan på antalet ms som rapporteras i det nedre högra hörnet i GPUView--fönstret.

   

5. Mät cpu-tiden per bildruta genom att mäta hur lång tid det tar för alla trådar som ingår i återgivningen. Det kan vara värt att begränsa tråden som förväntas vara mest relevant ur prestandasynpunkt. I exempelexemplet för geometriframförande animeras innehållet och måste återges på skärmen varje bildruta, vilket gör användargränssnittstråden till den viktiga. När du har fastställt vilken tråd du ska titta på mäter du längden på staplarna i den här tråden. Genom att ta genomsnittet av några av dessa får man CPU-tid per bildruta. Bilden nedan visar hur mycket tid som upptas på UI-tråden. Det visar också att denna tid passar bra mellan två på varandra följande v-sync, vilket innebär att det når 60FPS.

   

   Du kan också kontrollera genom att titta på flip-kön för motsvarande tidsram som visar att DWM kan presentera varje bildruta.

   

6. GPU-tiden kan mätas på samma sätt som cpu-tiden. Zooma in i relevant område som vid mätning av CPU-tid. Mät längden på staplarna i GPU-maskinvarukön med samma färg som färgen på kontext-CPU-kön. Så länge staplarna passar inom efterföljande v-syncar körs appen smidigt i 60 FPS.

   

Beräkna cpu- och GPU-tid när 8192-primitiver återges orealiserade

1. Om du följer samma steg igen visar spåret att allt CPU-arbete för en bildruta inte ryms mellan två på varandra följande v-synkroniseringar. Det innebär att appen är CPU-bunden. Användargränssnittstråden mättar processorn.

   

   Om du tittar på flip-kön är det också tydligt att DWM inte kan presentera varje bildruta.

   

2. För att analysera var tiden spenderas, öppna spårningen i XPerf. Om du vill analysera starttiden i XPerf-letar du först reda på tidsintervallet i GPUView-. Hovra med musen över vänster och höger om intervallet och anteckna den absoluta tiden som visas längst ned i GPUView-fönstret. Öppna sedan samma .etl-fil i XPerf- och rulla ned till diagrammet "CPU Sampling by CPU", högerklicka och välj "Välj intervall..." Detta gör det möjligt att skriva in det intresseintervall som upptäcktes genom att titta på GPU-spårningen.

   

3. Gå till menyn Felsökning och se till att "Läs in symboler" är markerat. Gå också till Trace –> Konfigurera symbolsökvägar, och skriv in appsymbolsvägen. En symbolfil innehåller felsökningsinformation om en kompilerad körbar fil i en separat databas (.pdb). Den här filen kallas ofta för ett PDB. Mer information om symbolfiler finns här: Symbolfiler. Den här filen kan finnas i mappen "Felsöka" i appkatalogen.

4. För att få en uppdelning av var tiden spenderas i appen högerklickar du på det intervall som valdes i föregående steg och klickar på Sammanfattningstabell. Om du vill få en översikt över hur mycket tid som spenderas i varje dll avmarkerar du "Stack" från menyn "Kolumner". Observera att kolumnen "Antal" här visar hur många exempel som finns inom den angivna dll/funktionen. Eftersom ungefär ett exempel tas per ms kan det här talet användas som en bästa gissning för hur mycket tid som spenderas i varje dll/funktion. Genom att markera "Stack" i kolumnmenyn får du total tid som spenderas i varje funktion i anropsdiagrammet. Detta hjälper till att bryta ned problempunkterna ytterligare.

5. Stackspårningsinformation för 2048 orealiserade primitiver visar att 30% cpu-tid spenderas i geometriförverkligandeprocessen. Av det spenderas cirka 36% av tiden i geometri tessellation och smekning.

6. Stackspårningsinformation för 8192 orealiserade primitiver visar att cirka 60% av CPU-tiden (4 kärnor) spenderas i geometriförverkligande.

   

Beräkning av CPU-tid när 8 192 primitiver återges

Det framgår tydligt av profilerna att appen är CPU-bunden. För att minska cpu-tiden kan geometrier skapas en gång och cachelagras. Det cachelagrade innehållet kan renderas varje bildruta utan att medföra kostnaden för geometri-tesselering per bildruta. När du tittar på spårningen i GPUView- för den realiserade delen av appen är det tydligt att DWM kan presentera varje bildruta och processortiden har minskat drastiskt.

Den första delen av diagrammet visar realiserade 8192 primitiver. Motsvarande CPU-tid per bildruta kan passa inom två på varandra följande v-synkroniseringar. I den senare delen av diagrammet är detta inte sant.

Om du tittar i XPerfsitter PROCESSORn inaktiv under den längsta tiden med bara cirka 25% av cpu-tiden som spenderas på geometrii-realiseringsappen.

Sammanfattning

Både GPUView och XPerf och kraftfulla verktyg för att analysera prestanda för DirectX-appar. Den här artikeln är en primer för att använda dessa verktyg och förstå grundläggande prestandamätningar och appegenskaper. Förutom att förstå användningen av verktyg är det först viktigt att förstå appen som analyseras. Börja med att hitta svar på frågor som vad appen försöker uppnå? Vilka trådar i systemet är viktigast? Vilka kompromisser är du villig att göra? När du analyserar prestandaspårningar börjar du med att titta på uppenbara problematiska platser. Är appens CPU eller GPU bunden? Kan appen presentera varje bildruta? Verktyg tillsammans med en förståelse för appen kan ge mycket användbar information för att förstå, hitta och slutligen lösa prestandaproblem.