Panoramica della diagnostica grafica
La diagnostica grafica consente di eseguire il debug degli errori di rendering nei giochi e nelle app DirectX.
Requisiti di Visual Studio 2013
Per usare la diagnostica grafica in Visual Studio 2013, è necessario disporre di una di queste edizioni:
Visual Studio 2013 Ultimate
Visual Studio 2013 Premium
Visual Studio 2013 Professional
Visual Studio 2013 Express per Windows
Nota
Visual Studio 2013 Express per desktop Windows non supporta le funzionalità di diagnostica grafica.
Sistema operativo e requisiti SDK
Windows Software Development Kit (SDK) per Windows 8.1 installa i componenti di runtime richiesti dalla diagnostica grafica e supporta lo sviluppo per Windows 8.1 e Windows 8. Per usare la diagnostica grafica in Windows 7 e Windows Vista, è necessario installare uno degli SDK seguenti:
Windows SDK (versione 7.1)
DirectX SDK (giugno 2010)
Compatibilità tra versioni DirectX
La diagnostica grafica supporta le app che usano Direct3D 10, Direct3D 10.1, Direct3D 11, Direct3D 11.1 e Direct3D 11.2 e fornisce supporto limitato per le app che usano Direct2D. Non supporta le app che usano versioni precedenti di Direct3D, DirectDraw o altre API grafiche.
Windows 8.1 e Direct3D 11.2
In Windows 8.1, DirectX 11.2 introduce nuove funzionalità che includono supporto per l'acquisizione di informazioni grafiche tramite il relativo runtime. Windows 8.1 usa la nuova acquisizione basata su runtime, nota come acquisizione affidabile,esclusivamente per le versioni di DirectX supportate da Windows 8.1. L'acquisizione affidabile supporta anche nuove funzionalità di Direct3D 11.2.
Supporto per Windows 8 e Windows 7
A causa del fatto che le versioni precedenti di Windows non supportano DirectX 11.2, la funzionalità di acquisizione affidabile non è disponibile su tali piattaforme. Le applicazioni eseguite in Windows 8 o Windows 7 usano il metodo di acquisizione precedente basato su deviazione, noto come acquisizione legacy. Dato che non vi è necessità di supportarla in Windows 8.1, l'acquisizione legacy è deprecata, ma resta tuttavia disponibile per il supporto di app eseguite in Windows 8 o Windows 7.
Supporto Direct2D limitato
Poiché Direct2D è un'API modalità utente basata su Direct3D, è possibile usare la diagnostica grafica per agevolare il debug dei problemi di rendering nelle app che usano Direct2D. Tuttavia, poiché vengono registrati solo gli eventi Direct3D, anziché gli eventi Direct2D di livello superiore, gli eventi Direct2D non verranno visualizzati nell'elenco eventi grafici. Inoltre, poiché la relazione tra gli eventi Direct2D e gli eventi Direct3D risultanti non è sempre chiara, usare la diagnostica grafica per eseguire il debug dei problemi di rendering nelle app che usano Direct2D non è semplice. È comunque possibile usare la diagnostica grafica per ottenere informazioni sui problemi di rendering di livello inferiore nelle app che usano Direct2D.
Modifiche all'interfaccia utente in Visual Studio 2013 Update 3
A partire da Visual Studio 2013 Update 3, le finestre degli strumenti di diagnostica grafica sono ospitate in una copia indipendente della shell di Visual Studio per ridurre il numero di finestre degli strumenti che si contendono lo spazio limitato nell'IDE principale di Visual Studio. La shell personalizzata che ora ospita gli strumenti di diagnostica grafica, denominata Analisi grafica di Visual Studio, elimina le opzioni e i menu non necessari per la diagnostica grafica, ma a parte ciò gli strumenti di diagnostica grafica e i flussi di lavoro sono simili alla diagnostica grafica delle versioni precedenti di Visual Studio.
Ci sono due differenze significative:
Quando si esegue l'app nella diagnostica grafica, Visual Studio non visualizza più una versione live del documento del log di grafica. Visual Studio fornisce invece una nuova interfaccia di acquisizione. Ecco l'aspetto della nuova interfaccia di acquisizione:
Da questa interfaccia è possibile acquisire uno o più frame nel log di grafica e visualizzare in tempo reale i grafici che mostrano la frequenza dei fotogrammi di un'app, nonché il tempo in millisecondi impiegato per il rendering di ciascun frame.
Non è possibile modificare il codice nella shell Analisi grafica. Se si apre il codice per la modifica in Analisi grafica, quest'ultimo verrà aperto nell'IDE principale di Visual Studio dove riceverà lo stato attivo.
Questa interfaccia è quella visualizzata in Visual Studio. Per avviare Analisi grafica di Visual Studio, scegliere uno dei frame mediante il collegamento Frame sotto l'anteprima dell'immagine oppure fare doppio clic sull'anteprima stessa.
Uso della diagnostica grafica per eseguire il debug dei problemi di rendering
Eseguire il debug dei problemi di rendering in un'applicazione con contenuti grafici avanzati non è semplice come avviare un debugger ed eseguire codice istruzione per istruzione. In ogni frame vengono prodotte centinaia di migliaia di pixel univoci, ciascuno in base a un set complesso di stati, dati, parametri e codice. Di questi, probabilmente solo pochi presenteranno il problema che si tenta di diagnosticare. Come se non bastasse, il codice che genera ciascun pixel viene eseguito in hardware specializzato che elabora centinaia di pixel in parallelo. Gli strumenti e le tecniche tradizionali di debug, difficili da sfruttare anche in codice con pochi thread, sono inefficaci di fronte a una quantità eccessiva di dati.
Gli strumenti di diagnostica grafica in Visual Studio sono progettati per individuare i problemi di rendering a partire dagli elementi visivi che indicano il problema e quindi risalendo all'origine concentrandosi solo sul codice di shader pertinente, le fasi della pipeline, le chiamate di disegno, le risorse e lo stato del dispositivo nel codice sorgente dell'app.
Di seguito sono riportati alcuni tipi di problemi di rendering per cui Visual Studio può fornire supporto.
Stato del dispositivo
La configurazione corretta del dispositivo di grafica è importante, poiché determina il modo in cui la pipeline grafica interpreta i dati associati a ogni chiamata di disegno e il modo in cui viene eseguito il merge degli output delle chiamate di disegno. Ad esempio, se lo stato del dispositivo specifica l'ordine dei vertici in senso orario, non verrà eseguito il rendering di eventuali modelli con vertici specificati in senso antiorario. I problemi relativi allo stato del dispositivo possono essere difficili da diagnosticare, poiché la radice del problema nel codice sorgente è spesso distante dagli oggetti interessati. Tramite diagnostica grafica è possibile visualizzare lo stato corrente del dispositivo in qualsiasi momento durante il rendering.Buffer di costanti e parametri non inizializzati o errati
Le app grafiche usano buffer di costanti e parametri per passare dati aggiuntivi a una chiamata o un set di chiamate di disegno. Ad esempio, i dati potrebbero specificare percorsi o aspetti specifici per oggetti diversi. Se i dati non vengono inizializzati o contengono valori errati, il rendering dell'oggetto corrispondente risulterà errato o non verrà eseguito. Questo tipo di problema può risultare difficile da diagnosticare, poiché non è sempre chiaro se risieda nei dati o nel codice dello shader che lo usa. Può risultare difficile determinare quali shader, buffer di costanti e parametri corrispondano all'errore. È possibile usare la diagnostica grafica per determinare quali shader, buffer di costanti e parametri si applichino a ciascuna chiamata di disegno e visualizzarne i contenuti.Bug di shader
È praticamente inevitabile commettere un errore nel codice dell'app, che si tratti di C++ o High Level Shader Language (HLSL). Tuttavia, il debug del codice HLSL era in passato più difficile, poiché non disponeva del supporto di debug avanzato di cui usufruiscono C++ e altri linguaggi. La diagnostica grafica introduce gli strumenti tradizionali di debug del codice in HLSL, per consentire di eseguire il codice istruzione per istruzione, impostare punti di interruzione ed esaminare il contenuto delle variabili, dei parametri e dei buffer di costanti.
Funzionamento della diagnostica grafica
Per usare la diagnostica grafica, è innanzitutto necessario registrare le informazioni sul modo in cui un'app usa l'API Direct3D mentre è in esecuzione, quindi esaminare il comportamento registrato. Per i frame specificati, le informazioni registrate includono le chiamate API, ad esempio quelle che cancellano lo schermo, disegnano la geometria, inviano compute shader o modificano lo stato del dispositivo di grafica, insieme ai relativi argomenti e alle copie di buffer e oggetti a cui si fa indirettamente riferimento. Inoltre, le chiamate API correlate all'installazione e all'inizializzazione vengono registrate prima dell'esecuzione del rendering di qualsiasi frame. Le informazioni registrate vengono scritte in un file di log di grafica (.vsglog).
Per ricreare il comportamento di rendering registrato nel log di grafica, riprodurre gli eventi di grafica nel computer di sviluppo oppure in un computer o un dispositivo remoto. Il computer di riproduzione può essere lo stesso computer o dispositivo in cui è stato originariamente acquisito il log di grafica, ma non necessariamente. Per la maggior parte delle funzionalità di riproduzione, l'hardware grafico del computer di riproduzione viene usato per riprodurre gli eventi di grafica, ma se si usa il debugger HLSL il codice dello shader verrà sempre riprodotto tramite una GPU emulata nella CPU. L'uso di una GPU emulata consente di eseguire il codice di shader istruzione per istruzione, controllare le variabili e usare altre funzionalità di debug comuni, indipendentemente dal fatto che l'hardware grafico nel computer di riproduzione supporti il debug dell'hardware.
Nota
Sebbene il log di grafica acquisisca la maggior parte delle informazioni pertinenti a livello interno, sono necessarie altre informazioni per usare appieno alcune funzionalità di diagnostica grafica.Ad esempio, per sfruttare la funzionalità di stack delle chiamate di grafica, è necessario disporre anche del file di database di programma (.pdb) e del codice sorgente dell'app.Per eseguire il debug del codice sorgente dello shader HLSL, è necessario disporre anche del codice sorgente dello shader.Se lo shader viene compilato mediante il compilatore D3D11.1 e le informazioni di debug sono abilitate, il codice sorgente dello shader è incorporato nel log di grafica durante l'acquisizione.
Nota
Dato che certe API potrebbero non essere disponibili in versioni precedenti di Windows o di DirectX, non è possibile riprodurre log di grafica che hanno acquisito tali chiamate API in un computer di riproduzione che non le supporti.
Log di grafica
Un log di grafica contiene uno o più frame acquisiti da un'applicazione grafica DirectX in esecuzione. Poiché un log di grafica è indipendente, questi frame potranno essere ricreati in un secondo momento, senza informazioni o riferimenti esterni. Ciò significa che è possibile condividere i log di grafica con altri sviluppatori, esaminare i problemi in computer diversi e analizzare i log di grafica precedenti anche se i modelli e le trame sono stati modificati in fase di sviluppo. È inoltre possibile caricare più file di log di grafica (.vsglog) contemporaneamente per confrontare i dati e i risultati di rendering.
Per aprire un file di log di grafica (vsglog)
Nella barra dei menu di Visual Studio scegliere File, Apri, File. Verrà visualizzata la finestra di dialogo Apri file.
Specificare un file di log di grafica (.vsglog) da aprire, quindi scegliere il pulsante Apri.
Nota
È possibile estrarre, modificare e salvare copie di mesh e trame da un log di grafica usando gli strumenti di grafica inclusi in Visual Studio.Tuttavia, il contenuto del log di grafica non è interessato da tali modifiche.Per altre informazioni su tali strumenti di grafica, vedere Utilizzo di risorse tridimensionali per giochi e app.
Barra degli strumenti di grafica
La barra degli strumenti di grafica consente di accedere rapidamente ai controlli e alle finestre degli strumenti di diagnostica grafica.
Il pulsante Avvia diagnostica permette di eseguire l'applicazione nella diagnostica grafica. Se un'app è in esecuzione nella diagnostica grafica, il pulsante Acquisisci il frame successivo di cui è stato eseguito il rendering è abilitato ed è possibile usare gli altri pulsanti per visualizzare le varie finestre degli strumenti. Per altre informazioni su come eseguire un'app nella diagnostica grafica e acquisire informazioni grafiche, vedere Cattura informazioni grafica.
Finestre degli strumenti di diagnostica grafica
Di seguito viene illustrato un layout tipico delle finestre degli strumenti usate per analizzare i frame acquisiti ed eseguirne il debug. Ogni finestra espone una categoria diversa di informazioni sul frame acquisito che viene esaminato, nonché sui singoli pixel nel frame.
Usare la finestra Documento log grafica per identificare i problemi di rendering pertinenti.
Usare Elenco eventi grafici per identificare gli eventi correlati a un problema di rendering.
Usare la finestra Fasi pipeline grafica per identificare la fase della pipeline in cui viene visualizzato per la prima volta un problema di rendering.
Usare Stack di chiamate eventi grafici per individuare il codice dell'app relativo a un problema di rendering.
Usare Cronologia pixel grafica per esaminare i dettagli degli eventi che incidono sul colore finale di un pixel.
Usare Tabella oggetti grafici per visualizzare i dettagli degli oggetti correlati a un problema di rendering.
Pannello di controllo DirectX
Il pannello di controllo DirectX è un componente che consente di modificare il comportamento di DirectX. È ad esempio possibile abilitare la versione di debug dei componenti di runtime di DirectX, selezionare il tipo di messaggi di debug segnalati e impedire l'uso di determinate funzionalità dell'hardware grafico per emulare hardware meno potente. Questo livello di controllo su DirectX può facilitare il debug e il test dell'app DirectX. È possibile accedere al pannello di controllo DirectX da Visual Studio.
Per aprire il pannello di controllo DirectX
- Nella barra dei menu scegliere Debug, Grafica, Pannello di controllo DirectX.