Condividi tramite


Profilatura di app DirectX

In questo modo viene illustrato come misurare alcune delle misurazioni del tempo di prestazioni più importanti per un'app DirectX usando gli strumenti XPerf e GPUView forniti come parte di Windows Performance Toolkit. Questa non è una guida completa per comprendere gli strumenti, piuttosto la loro applicabilità specifica per l'analisi delle prestazioni delle app DirectX. Anche se la maggior parte delle tecniche descritte qui è rilevante per tutte le app DirectX, è più rilevante per le app che usano catene di scambio e non per le applicazioni DirectX basate su XAML che usano animazioni SIS/VSIS e XAML. Ti guidiamo attraverso le misurazioni chiave del tempo delle prestazioni, come acquisire e installare gli strumenti, prendere tracce di misurazione delle prestazioni e quindi analizzarle per identificare i colli di bottiglia dell'applicazione.

Informazioni sugli strumenti

XPerf

XPerf è un set di strumenti di analisi delle prestazioni basati su Event Tracing for Windows (ETW) progettati per misurare e analizzare informazioni dettagliate sulle prestazioni di sistema e sulle risorse e sull'utilizzo delle risorse. A partire da Windows 8 questo strumento da riga di comando ha un'interfaccia utente grafica ed è denominato Windows Performance Recorder (WPR) e Windows Performance Analyzer (WPA). Altre informazioni su questi strumenti sono disponibili nella pagina Web di Windows Performance Toolkit (WPT): Windows Performance Toolkit.

Un ETW raccoglie gli eventi del kernel richiesti e li salva in un file denominato file ETL (Event Trace Log). Questi eventi del kernel forniscono informazioni complete su un'app e sulle caratteristiche di sistema durante l'esecuzione dell'app. I dati vengono raccolti abilitando l'acquisizione di tracce, eseguendo lo scenario di app desiderato che richiede l'analisi, arrestando l'acquisizione che salva i dati in un file ETL. È quindi possibile analizzare il file nello stesso computer o in un computer diverso usando lo strumento da riga di comandoxperf.exe o lo strumento di analisi della traccia visiva xperfview.exe.

GPUView

GPUView è uno strumento di sviluppo per determinare le prestazioni dell'unità di elaborazione grafica (GPU) e della CPU. Esamina le prestazioni relative all'elaborazione diretta del buffer DMA (Memory Access) e a tutte le altre elaborazioni video nell'hardware video.

Per le app DirectX che si basano principalmente sulla GPU, GPUView è uno strumento potente per comprendere la relazione tra il lavoro svolto sulla CPU e la GPU. Per altre informazioni su GPUView, vedi Uso di GPUView.

Analogamente a XPerf, una traccia ETW viene prima acquisita avviando il servizio di traccia, esercitando lo scenario che richiede l'analisi per l'app in considerazione, arrestando il servizio e salvando le informazioni in un file ETL. GPUView presenta i dati presenti nel file ETL in un formato grafico.

Dopo aver installato lo strumento GPUView , è consigliabile leggere l'argomento "Visualizzazione principale di GPUView" nel menu "Guida di GPUView ". Contiene informazioni utili su come interpretare l'interfaccia utente di GPUView .

Installazione degli strumenti

Sia XPerf che GPUView sono inclusi in Windows Performance Toolkit (WPT).

XPerf viene fornito come parte di Windows Software Development Kit (SDK) per Windows. Scaricare Windows SDK.

GPUView è disponibile in Windows Assessment and Deployment Kit (Windows ADK). Scarica Windows ADK.

Dopo l'installazione, è necessario aggiungere le directory che contengono XPerf e GPUView alla variabile "Path" di sistema.

Fare clic sul pulsante Start e digitare "Variabili di sistema". Verrà visualizzata la finestra Proprietà di sistema. Fare clic su "Modifica le variabili di ambiente di sistema". Selezionare "Variabili di ambiente" nella finestra di dialogo "Proprietà di sistema". La variabile "Path" si trova in "Variabili di sistema". Aggiungere la directory contenente xperf.exe e GPUView.exe al percorso. Questi eseguibili si trovano nella directory "Windows Performance Toolkit" all'interno di "Windows Kits". Il percorso predefinito è C:\Programmi (x86)\Windows Kits\10\Windows Performance Toolkit.

Misurazioni del tempo di prestazioni

La maggior parte delle app prevede l'esecuzione senza problemi e risponde all'input dell'utente. Tuttavia, a seconda dello scenario desiderato, un aspetto delle prestazioni potrebbe essere più importante di un altro. Ad esempio, per un'app lettore di notizie in esecuzione su un TABLET touch, l'aspetto più importante consiste nel visualizzare un singolo articolo alla volta e per eseguire lo scorrimento/zoom/scorrimento nello stesso articolo o in un altro articolo. In questo scenario non è necessaria la possibilità di eseguire il rendering di tutto il contenuto di ogni fotogramma. Tuttavia, la possibilità di scorrere l'articolo senza problemi su un gesto di tocco è estremamente importante.

In un altro caso, un gioco o un'app per il rendering video che utilizza molte animazioni presenta problemi se i fotogrammi vengono eliminati. In questo caso, la possibilità di presentare contenuto sullo schermo senza interruzioni dall'input dell'utente è estremamente importante.

Per comprendere quale parte dell'app è problematica, il primo passaggio consiste nel decidere gli scenari più importanti. Una volta compresi gli aspetti principali dell'app e come verranno esercitati, la ricerca di problemi con gli strumenti diventa più semplice.

Di seguito sono riportate alcune delle metriche del tempo di prestazioni più comuni:

Tempo di avvio

Tempo misurato dall'avvio del processo alla prima presentazione sullo schermo. Questa misurazione è più utile quando il sistema è caldo, vale a dire che la misurazione viene eseguita dopo l'avvio dell'app alcune volte.

Tempo CPU per fotogramma

Il tempo durante il quale la CPU elabora attivamente il carico di lavoro dell'applicativo per un fotogramma. Se l'app viene eseguita senza problemi, tutte le elaborazioni necessarie per un fotogramma si verificano entro un intervallo di sincronizzazione v. Con la frequenza di aggiornamento del monitor di 60Hz, si tratta di 16 ms per fotogramma. Se l'intervallo di tempo della CPU è maggiore di 16 ms, potrebbero essere necessarie ottimizzazioni della CPU per produrre un'esperienza di app senza problemi.

Tempo GPU per fotogramma

Tempo per il quale la GPU elabora attivamente il carico di lavoro dell'app per un fotogramma. Un'app è associata a GPU quando il tempo impiegato per elaborare un frame di dati è superiore a 16 ms.

Essere in grado di capire se un'app è associata a CPU o GPU restringerà la parte problematica del codice.

Registrazione del tempo di misurazione delle prestazioni

Eseguire questi passaggi per ottenere una traccia:

  1. Aprire una finestra di comando come amministratore.
  2. Chiudere l'app se è già in esecuzione.
  3. Cambiare directory a gpuview all'interno della cartella Windows Performance Toolkit.
  4. Digitare "log.cmd" per avviare la traccia eventi. Questa opzione registra gli eventi più interessanti. Altre opzioni disponibili registrano un ambito diverso degli eventi. Ad esempio, la modalità di log dettagliata indicata con "v" acquisisce tutti gli eventi che GPUView conosce.
  5. Avviare l'esempio ed eseguire l'esercizio dell'esempio in modo da coprire il percorso delle prestazioni che è necessario analizzare.
  6. Tornare alle finestre dei comandi e digitare di nuovo "log.cmd" per arrestare la registrazione.
  7. In questo modo viene restituito un file denominato "merged.etl" nella cartella gpuview . È possibile salvare il file in un altro percorso ed analizzarlo nello stesso computer o in un computer diverso. Per visualizzare i dettagli dell'acquisizione dello stack, salvare il file di simboli (con estensione pdb) associato all'app.

Misure

Annotazioni

Le misurazioni per il campione di realizzazione della geometria vengono eseguite su un computer Quad Core con una scheda grafica DirectX11 integrata. Le misurazioni variano a seconda della configurazione del computer.

 

Questa sezione illustra come misurare il tempo di avvio, il tempo della CPU e della GPU per ogni fotogramma. È possibile acquisire una traccia delle prestazioni per lo stesso campione nel computer e visualizzare le differenze nelle varie misurazioni.

Per analizzare la traccia in GPUView, aprire il file "merged.elt" usando GPUView.exe.

Tempo di avvio

Il tempo di avvio viene misurato in base al tempo totale impiegato dall'avvio dell'app fino alla prima visualizzazione del contenuto sullo schermo.

La misurazione del tempo di avvio è ottimale seguendo i passaggi elencati nella sezione precedente con queste varianti:

  • Se si prendono le misure di avvio la prima volta che si avvia l'app, si chiama avvio a freddo. Questo può variare dalle misurazioni effettuate dopo l'avvio dell'app alcune volte in un breve periodo di tempo. Questa operazione è denominata avvio a caldo. A seconda del numero di risorse create da un'app al momento dell'avvio, può esserci una grande differenza tra i due tempi di avvio. A seconda degli obiettivi dell'app, la misurazione di una o l'altra potrebbe essere auspicabile.
  • Quando registrate informazioni sulle prestazioni, chiudete l'app non appena appare il primo fotogramma sullo schermo.

Calcolo del tempo di avvio tramite GPUView

  1. In GPUView scorrere verso il basso fino al processo pertinente, in questo caso GeometryRealization.exe.

    Screenshot che mostra un esempio di processi in GPUView.

  2. La coda di contesto della CPU rappresenta il carico di lavoro grafico accodato all'hardware, ma che non necessariamente viene elaborato dall'hardware. Quando il file di traccia viene aperto, vengono visualizzati tutti gli eventi registrati tra il momento in cui è stata eseguita la traccia. Per calcolare il tempo di avvio, selezionare l'area di interesse, eseguire lo zoom nella parte iniziale della prima coda della CPU di contesto (ovvero quella che mostra l'attività) usando CTRL+Z. Altre informazioni sui controlli GPUView sono disponibili nella sezione del file della Guida di GPUView "Riepilogo dei controlli GPUView ". La figura seguente mostra solo il processo GeometryRealization.exe ingrandito fino alla prima parte della coda CPU di contesto. Il colore della Coda CPU di contesto è indicato dal rettangolo immediatamente sotto la coda e i pacchetti di dati dello stesso colore nella coda mostrano il lavoro della GPU in attesa sull'hardware. Il pacchetto di pattern di tratteggio nella coda di contesto mostra il pacchetto attuale, il che significa che l'app desidera che l'hardware visualizzi il contenuto sullo schermo.

    Screenshot che mostra gli esempi della coda 'Context C P U Queue'.

  3. L'ora di avvio è l'ora in cui l'app viene avviata per la prima volta (in questo caso il modulo del punto di ingresso del thread dell'interfaccia utente SHCORE.dll) fino al momento in cui il contesto viene visualizzato per la prima volta (contrassegnato da un pacchetto di tratteggio). La figura qui evidenzia l'area di interesse.

    Annotazioni

    Le informazioni realmente attuali sono rappresentate nella coda di visualizzazione e quindi il tempo necessario viene esteso fino a quando il pacchetto presente si completa effettivamente nella coda di visualizzazione.

     

    La barra di stato completa non è visibile nella figura seguente, che mostra anche il tempo trascorso tra le parti evidenziate. Questo è il tempo di avvio dell'app. In questo caso per la macchina menzionata in precedenza, è venuto fuori circa 240 ms.

    Screenshot che mostra i punti di interesse riguardanti il tempo di avvio nella coda

TEMPO CPU e GPU per fotogramma

Quando si misura il tempo della CPU, è necessario considerare alcuni aspetti. Cercare le aree nella traccia in cui è stato eseguito lo scenario da analizzare. Ad esempio, nell'esemplificazione della geometria uno degli scenari analizzati è la transizione tra il rendering di 2048 e 8192 primitive, tutte non realizzate (cioè, la geometria non viene tassellata ad ogni fotogramma). La traccia mostra chiaramente la differenza nell'attività CPU e GPU prima e dopo la transizione nel numero di primitive.

Vengono analizzati due scenari per calcolare il tempo della CPU e della GPU per ogni fotogramma. Sono i seguenti.

  • Transizione dal rendering di 2048 primitive non realizzate a 8192 primitive non realizzate.
  • Transizione dal rendering di 8192 primitive realizzate a 8192 primitive non realizzate.

In entrambi i casi, si è osservato che la frequenza dei fotogrammi è diminuita drasticamente. Misurare il tempo della CPU e della GPU, la relazione tra i due e alcuni altri modelli nella traccia può fornire informazioni utili sulle aree problematiche nell'app.

Calcolo del tempo di CPU e GPU in cui viene eseguito il rendering di primitive 2048

  1. Aprire il file di traccia usando GPUView.exe.

  2. Scorri verso il basso fino al processo GeometryRealization.exe.

  3. Selezionare un'area per calcolare il tempo cpu e ingrandirla usando CTRL+Z.

    Screenshot che mostra un'area selezionata per il calcolo del tempo C P U nella

  4. Mostrare le informazioni di sincronizzazione verticale premendo ripetutamente F8. Continua a ingrandire fino a quando non è facile vedere chiaramente un quantitativo di dati pari a un vsync. Le linee blu indicano i punti di sincronizzazione per il v-sync. In genere, questi si verificano una volta ogni 16 ms (60 fps), ma se DWM riscontra un problema di prestazioni, viene eseguito più lentamente in modo che si verifichino una volta ogni 32 ms (30 fps). Per ottenere un'idea del tempo, selezionare una barra blu alla successiva e quindi esaminare il numero di ms segnalato nell'angolo inferiore destro della finestra GPUView .

    Screenshot che mostra un esempio di tempi di v-sync.

  5. Per misurare il tempo della CPU per fotogramma, misurare il periodo di tempo impiegato da tutti i thread coinvolti nel rendering. Potrebbe essere utile restringere il thread che dovrebbe essere più rilevante dal punto di vista delle prestazioni. Ad esempio, nell'esempio di realizzazione della geometria, il contenuto è animato e deve essere eseguito il rendering sullo schermo a ogni fotogramma, rendendo il thread dell'interfaccia utente il più importante. Dopo aver determinato il thread da esaminare, misurare la lunghezza delle barre in questo thread. Calcolare la media di alcuni di questi produce il tempo CPU per fotogramma. La figura seguente mostra il tempo utilizzato sul thread dell'interfaccia utente. Mostra anche che questo intervallo si adatta bene tra due sincronizzazioni verticali consecutive, il che significa che sta raggiungendo 60 FPS.

    Screenshot che mostra il tempo impiegato nel thread U I.

    È anche possibile verificare esaminando la coda di scorrimento per l'intervallo di tempo corrispondente, che mostra che DWM è in grado di presentare ogni fotogramma.

    Screenshot che mostra un esempio di 'Flip Queue'.

  6. Il tempo gpu può essere misurato nello stesso modo del tempo cpu. Eseguire lo zoom nell'area pertinente come nel caso di misurazione del tempo della CPU. Misurare la lunghezza delle barre nella coda hardware GPU con lo stesso colore del colore della coda cpu di contesto. Purché le barre rientrino in sincronizzazioni verticali consecutive, l'app viene eseguita senza problemi a 60 fotogrammi al secondo (FPS).

    Screenshot che mostra un esempio di

Calcolo del tempo di CPU e GPU quando vengono eseguite operazioni di rendering di 8192 primitive non completamente renderizzate

  1. Se si seguono di nuovo gli stessi passaggi, la traccia mostra che tutto il lavoro della CPU per un fotogramma non rientra tra una sincronizzazione v e quella successiva. Ciò significa che l'app è associata alla CPU. Il thread dell'interfaccia utente sta saturando la CPU.

    Screenshot che mostra un esempio del thread dell'interfaccia utente che satura la CPU.

    Esaminando la coda di scorrimento, è anche chiaro che DWM non è in grado di presentare ogni fotogramma.

    Screenshot che mostra un esempio di DWM (Desktop Window Manager) incapace di presentare ogni singolo fotogramma.

  2. Per analizzare dove viene speso il tempo, aprire la traccia in XPerf. Per analizzare il tempo di avvio in XPerf, trovare prima l'intervallo di tempo in GPUView. Passare il mouse a sinistra dell'intervallo e a destra e prendere nota del tempo assoluto visualizzato nella parte inferiore della finestra GPUView . Apri quindi lo stesso file con estensione .etl in XPerf e scorri verso il basso fino al grafico "Campionamento della CPU per CPU", fai clic destro e seleziona "Seleziona intervallo...". Questo permette di inserire l'intervallo di interesse individuato esaminando la traccia GPU.

    Screenshot che mostra 'Campionamento CPU per CPU' in 'Analisi delle prestazioni di Windows'.

  3. Passare al menu Traccia e verificare che sia selezionato "Carica simboli". Passa anche a Traccia -> Configura percorsi di simboli e inserisci il percorso del simbolo dell'app. Un file di simboli contiene informazioni di debug su un eseguibile compilato in un database separato (con estensione pdb). Questo file viene comunemente definito PDB. Altre informazioni sui file di simboli sono disponibili qui: File di simboli. Questo file può trovarsi nella cartella "Debug" della directory dell'app.

  4. Per ottenere la suddivisione del tempo trascorso nell'app, fare clic con il pulsante destro del mouse sull'intervallo selezionato nel passaggio precedente e scegliere Tabella riepilogo. Per ottenere una panoramica della quantità di tempo impiegato in ogni DLL, deselezionare "Stack" dal menu "Colonne". Si noti che la colonna "Conteggio" mostra quanti campioni sono contenuti nella dll/funzione indicata. Poiché viene eseguito circa un campione per ms, questo numero può essere usato come migliore ipotesi per quanto tempo viene impiegato in ogni dll/funzione. Se si seleziona "Stack" dal menu Colonne, si ottiene il tempo totale trascorso in ogni funzione all'interno del grafico delle chiamate. Ciò consentirà di suddividere ulteriormente i punti del problema.

  5. Le informazioni sull'analisi dello stack per le primitive non realizzate 2048 rivelano che 30% di tempo della CPU viene impiegato nel processo di realizzazione della geometria. Di questo circa 36% del tempo viene speso in tassellatura geometrica e strozzante.

  6. Le informazioni sull'analisi dello stack per le primitive non realizzate 8192 rivelano che circa 60% del tempo cpu (4 core) viene impiegato nella realizzazione della geometria.

    Screenshot che mostra le informazioni sul traceback dello stack per il tempo della CPU.

Calcolo del tempo di CPU in cui viene eseguito il rendering delle primitive 8192

È chiaro dai profili che l'app è associata alla CPU. Per ridurre il tempo impiegato dalla CPU, le geometrie possono essere create una volta e memorizzate nella cache. Il rendering del contenuto memorizzato nella cache può essere eseguito ogni fotogramma senza incorrere nel costo della tassellatura geometrica per fotogramma. Quando si esamina la traccia in GPUView per la parte realizzata dell'app, è chiaro che DWM è in grado di presentare ogni fotogramma e il tempo della CPU è ridotto drasticamente.

Screenshot che mostra un esempio di traccia in GPUView in cui D W M è in grado di presentare ogni fotogramma.

La prima parte del grafico mostra 8192 primitive realizzate. Il tempo di CPU corrispondente per ogni fotogramma riesce a rientrare all'interno di due sincronizzazioni verticali consecutive. Nella parte successiva del grafico questo non è vero.

Guardando in XPerf, la CPU è inattiva per il tempo prolungato e solo circa 25% del tempo della CPU è utilizzato dall'app di realizzazione geometrica.

screenshot gpuview.

Riassunto

Sia GPUView che XPerf e potenti strumenti per l'analisi delle prestazioni delle app DirectX . Questo articolo è un articolo di base per l'uso di questi strumenti e la comprensione delle misurazioni delle prestazioni di base e delle caratteristiche dell'app. Oltre a comprendere l'uso degli strumenti, è prima importante comprendere l'app da analizzare. Inizia cercando risposte a domande come cosa sta cercando di ottenere l'app? Quali thread nel sistema sono più importanti? Quali compromessi sei disposto a fare? Quando si analizzano le tracce delle prestazioni, iniziare esaminando posizioni problematiche ovvie. L'app è limitata dalla CPU o dalla GPU? L'app è in grado di presentare ogni fotogramma? Gli strumenti insieme a una comprensione dell'app possono fornire informazioni molto utili per comprendere, trovare e infine risolvere i problemi di prestazioni.