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 che vengono 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 dell'app DirectX. Anche se la maggior parte delle tecniche descritte qui sono rilevanti per tutte le app DirectX, è più rilevante per le app che usano catene di scambio e non per applicazioni DirectX basate su XAML che usano animazioni SIS/VSIS e XAML. Viene illustrata la misurazione del tempo delle prestazioni chiave, come acquisire e installare gli strumenti e acquisire le tracce di misurazione delle prestazioni e quindi analizzarle per comprendere i colli di bottiglia dell'app.

Informazioni sugli strumenti

XPerf

XPerf è un set di strumenti di analisi delle prestazioni basati su Traccia eventi per Windows (ETW) progettati per misurare e analizzare le prestazioni e l'utilizzo dettagliato delle app e delle risorse. A partire da Windows 8 questo strumento della riga di comando ha un'interfaccia utente grafica e viene chiamata Windows Performance Recorder (WPR) e Windows analizzatore prestazioni (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 di log di traccia eventi (ETL). Questi eventi kernel forniscono informazioni dettagliate su un'app e sulle caratteristiche del sistema durante l'esecuzione dell'app. I dati vengono raccolti abilitando l'acquisizione di traccia, 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 della riga di comando xperf.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 per quanto riguarda l'elaborazione del buffer DMA (Direct Memory Access) e tutte le altre elaborazioni video nell'hardware video.

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

Analogamente a XPerf, viene prima presa una traccia ETW 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 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). Scaricare 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à aperto il Finestra Proprietà di sistema. Fare clic su "Modifica le variabili di ambiente di sistema". Selezionare "Variabili di ambiente" nella finestra di dialogo "Proprietà sistema". La variabile "Path" viene trovata in "Variabili di sistema". Aggiungere la directory contenente xperf.exe e GPUView.exe al percorso. Questi eseguibili sono disponibili 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 di eseguire senza problemi e di essere reattiva all'input 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 PC tablet touch, l'aspetto più importante consiste nel visualizzare un singolo articolo alla volta e per scorrere/ingrandire/scorrere lo stesso o un altro articolo. In questo scenario la possibilità di eseguire il rendering di tutti i contenuti ogni frame non è necessaria. Tuttavia, la possibilità di scorrere l'articolo in modo uniforme su un gesto di tocco è estremamente importante.

In un'altra istanza, un gioco o un'app di rendering video che usa un sacco di animazioni glitch se i fotogrammi vengono eliminati. In questo caso, la possibilità di presentare il contenuto sullo schermo senza interuptione dall'input utente è estremamente importante.

Per comprendere quale parte dell'app è problematica, il primo passaggio consiste nel decidere gli scenari più importanti. Dopo aver compreso gli aspetti principali dell'app e come verranno esercitati, cercare problemi usando gli strumenti diventa più semplice.

Alcune delle metriche di tempo di prestazioni più comuni sono le seguenti:

Tempo di avvio

Tempo misurato dall'avvio del processo al primo presente sullo schermo. Questa misura è più utile quando il sistema è caldo, ovvero la misurazione viene eseguita dopo l'avvio dell'app qualche volta.

Tempo CPU per fotogramma

Tempo per cui la CPU elabora attivamente il carico di lavoro dell'app per un frame. Se l'app è in esecuzione senza problemi, tutte le operazioni necessarie per un frame vengono eseguite entro un intervallo di sincronizzazione v. Con la frequenza di aggiornamento del monitor di 60Hz, questa operazione arriva a 16ms per fotogramma. Se il time/frame della CPU è maggiore di 16ms, le ottimizzazioni della CPU potrebbero essere necessarie per produrre un'esperienza di app gratuita per glitch.

Tempo GPU per fotogramma

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

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

Rilevamento del tempo di prestazioni

Eseguire questa procedura per eseguire una traccia:

1. Aprire una finestra di comando come amministratore.
2. Chiudere l'app se è già in esecuzione.
3. Modificare le directory nella directory gpuview all'interno della cartella Windows Performance Toolkit.
4. Digitare "log.cmd" per avviare la traccia degli eventi. Questa opzione registra gli eventi più interessanti. Altre opzioni disponibili registrano un ambito diverso degli eventi. Ad esempio ,v' o modalità log dettagliata acquisisce tutti gli eventi a cui è a conoscenza GPUView .
5. Avviare l'esempio ed eseguire l'esempio in modo da coprire il percorso delle prestazioni che è necessario analizzare.
6. Indietro alle finestre del comando e digitare di nuovo "log.cmd" per arrestare la registrazione.
7. In questo modo viene restituito un file denominato "merge.etl" nella cartella gpuview . È possibile salvare questo file in un altro percorso e 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.

Misurazioni

Nota

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

 

In questa sezione viene illustrato come misurare il tempo di avvio, la CPU e la GPU per ogni intervallo di misurazione. È possibile acquisire una traccia delle prestazioni per lo stesso esempio nel computer e vedere le differenze nelle varie misurazioni.

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

Tempo di avvio

L'ora di avvio viene misurata dal tempo totale trascorso dall'inizio dell'app fino alla prima visualizzazione del contenuto sullo schermo.

La misura in fase di avvio è ottimale seguendo i passaggi elencati nella sezione precedente con queste varianti:

• Se si accettano le misurazioni di avvio la prima volta che si avvia l'app, si chiama avvio a freddo. Ciò può variare dalle misurazioni eseguite dopo aver avviato l'app qualche volta in un breve periodo di tempo. Viene chiamato avvio ad accesso frequente. A seconda del numero di risorse create da un'app all'avvio, può verificarsi una grande differenza tra i due tempi di avvio. A seconda degli obiettivi dell'app, misurare una o l'altra potrebbe essere auspicabile.
• Quando si registrano le informazioni sulle prestazioni, terminare l'app non appena viene visualizzata la prima cornice sullo schermo.

Calcolo dell'ora di avvio tramite GPUView

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

   

2. La coda della CPU di contesto rappresenta il carico di lavoro grafico accodato all'hardware, ma non necessariamente elaborato dall'hardware. Quando il file di traccia viene aperto, mostra tutti gli eventi registrati tra l'ora in cui è stata eseguita la traccia. Per calcolare il tempo di avvio, selezionare l'area di interesse, eseguire lo zoom sulla 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 File della Guida GPUView "Riepilogo dei controlli GPUView". La figura seguente mostra solo il processo di GeometryRealization.exe ingrandita fino alla prima parte della coda della CPU contesto. Il colore della coda cpu contesto viene denotato dal rettangolo sotto la coda e gli stessi pacchetti di dati di colore nella coda mostrano che il lavoro della GPU è in coda accodato sull'hardware. Il pacchetto del modello di tratteggio nella coda di contesto mostra il pacchetto presente che significa che l'app vuole che l'hardware presenti sul contenuto sullo schermo.

   

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

   Nota

   Le informazioni presenti effettive sono rappresentate nella coda di capovolgimento e quindi il tempo necessario viene esteso fino al completamento del pacchetto presente nella coda di capovolgimento.

    

   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 per essere circa 240ms.

   

Tempo CPU e GPU per fotogramma

Esistono alcune cose da considerare quando si misura il tempo della CPU. Cercare le aree nella traccia in cui è stato eseguito lo scenario da analizzare. Ad esempio, nell'esempio di realizzazione geometry uno degli scenari analizzati è la transizione tra il rendering 2048 e le primitive 8192, tutti non realizzati (come in, la geometria non è tessellata ogni cornice). La traccia mostra chiaramente la differenza nell'attività CPU e GPU prima e dopo la transizione nel numero di primitive.

Due scenari vengono analizzati per calcolare il tempo della CPU e della GPU per ogni intervallo. Sono i seguenti.

• Transizione dal rendering delle primitive non realizzate 2048 a 8192 primitive non realizzate.
• Passando dal rendering 8192 sono stati realizzati primitivi a 8192 primitive non realizzate.

In entrambi i casi, è stato 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 della CPU e della GPU quando vengono eseguite le primitive 2048

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

2. Scorrere verso il basso fino al processo di GeometryRealization.exe.

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

   

4. Visualizzare le informazioni di sincronizzazione v attivando tra F8. Mantenendo lo zoom avanti fino a quando è facile vedere una vsync vale chiaramente la pena dei dati. Le linee blu sono dove i tempi di sincronizzazione v.. In genere, questi si verificano una volta ogni 16 ms (60 fps), ma se DWM riscontra un problema di prestazioni, viene eseguito più lento in modo che si verifichino una volta ogni 32 ms (30 fps). Per ottenere un senso di tempo, selezionare da una barra blu alla successiva e quindi esaminare il numero di ms segnalato nell'angolo inferiore destro della finestra GPUView .

   

5. Per misurare il tempo della CPU per intervallo, misurare la durata di tempo impiegato da tutti i thread coinvolti nel rendering. Potrebbe essere utile limitare il thread che dovrebbe essere più rilevante da un punto di vista delle prestazioni. Ad esempio, nell'esempio di realizzazione geometry, il contenuto è animato e deve essere eseguito il rendering sullo schermo ogni cornice che rende l'interfaccia utente il thread importante. Dopo aver determinato quale thread esaminare, misurare la lunghezza delle barre su questo thread. La media di alcuni di questi restituisce il tempo della CPU per ogni fotogramma. La figura seguente mostra il tempo impiegato nel thread dell'interfaccia utente. Mostra anche che questa volta si adatta bene tra due sincronizzazioni v-consecutive che significa che sta raggiungendo 60FPS.

   

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

   

6. Il tempo della GPU può essere misurato nello stesso modo del tempo della CPU. Ingrandire l'area pertinente come nel caso della misurazione del tempo della CPU. Misurare la lunghezza delle barre nella coda hardware GPU con lo stesso colore del colore della coda della CPU contesto. Purché le barre si adattano alle sincronizzazioni v consecutive, l'app viene eseguita senza problemi a 60FPS.

   

Calcolo della CPU e della GPU quando vengono eseguite le primitive 8192

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

   

   Guardando la coda di capovolgimento, è anche chiaro che DWM non è in grado di presentare ogni cornice.

   

2. Per analizzare dove viene trascorso il tempo, aprire la traccia in XPerf. Per analizzare l'ora 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 . Aprire quindi lo stesso file con estensione etl in XPerf e scorrere verso il basso fino al grafico "Campionamento CPU per CPU", fare clic con il pulsante destro del mouse e selezionare "Seleziona intervallo..." Ciò consente di digitare nell'intervallo di interesse individuato esaminando la traccia della GPU.

   

3. Passare al menu Traccia e verificare che sia selezionato "Carica simboli". Passare anche a Traccia -> Configurare i percorsi dei simboli e digitare nel percorso del simbolo dell'app. Un file di simboli contiene informazioni di debug su un eseguibile compilato in un database separato (.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 della posizione in cui viene trascorso il tempo nell'app, fare clic con il pulsante destro del mouse sull'intervallo selezionato nel passaggio precedente e scegliere Riepilogo tabella. Per ottenere una panoramica della quantità di tempo trascorsa in ogni dll, deselezionare "Stack" dal menu "Colonne". Si noti che la colonna "Count" qui mostra il numero di esempi all'interno della dll/funzione specificata. Poiché circa un esempio viene eseguito per ms, questo numero può essere usato come un'ipotesi migliore per quanto tempo viene trascorso in ogni dll/funzione. Il controllo "Stack" dal menu Colonne darà il tempo inclusivo trascorso in ogni funzione nel grafico delle chiamate. Ciò aiuterà a suddividere ulteriormente i punti del problema.

5. Le informazioni sulla traccia dello stack per le primitive non realizzate del 2048 rivelano che il 30% del tempo di CPU viene speso nel processo di realizzazione geometry. Di questo circa il 36% del tempo viene speso in tessellatura geometria e strozzamento.

6. Le informazioni sulla traccia dello stack per le primitive non realizzate 8192 rivelano che circa il 60% del tempo della CPU (4 core) viene speso nella realizzazione della geometria.

   

Calcolo del tempo della CPU quando vengono rese rese le primitive 8192

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

La prima parte del grafico mostra le primitive realizzate 8192. Il tempo della CPU corrispondente per fotogramma è in grado di adattarsi all'interno di due sincronizzazioni v-sync consecutive. Nella parte successiva del grafico non è vero.

Guardando in XPerf, la CPU è inattiva per il tempo più lungo con solo il 25% del tempo di cpu trascorso sull'app di realizzazione geometry.

Riepilogo

Sia GPUView che XPerf e potenti strumenti per l'analisi delle prestazioni delle app DirectX . Questo articolo è un argomento di base per l'uso di questi strumenti e la comprensione delle caratteristiche delle prestazioni di base e delle app. Oltre a comprendere l'utilizzo degli strumenti, è prima importante comprendere l'app in fase di analisi. Iniziare a trovare risposte alle domande come qual è il tentativo di ottenere dall'app? Quali thread nel sistema sono più importanti? Quali compromessi sei disposto a fare? Quando si analizzano le tracce delle prestazioni, iniziare esaminando le posizioni problematiche ovvie. La CPU o la GPU dell'app è associata? L'app è in grado di presentare ogni cornice? Gli strumenti insieme a una comprensione dell'app possono fornire informazioni molto utili per comprendere, trovare e infine risolvere i problemi di prestazioni.