Interfacce WGF11

Questo test automatizzato verifica diverse parti dell'hardware e il driver per l'esecuzione valida dello shader quando vengono usate le interfacce.

Il test è incentrato sulla copertura delle informazioni del buffer nascoste fornite al driver tramite DDI, che include tipi di interfaccia e posizioni delle risorse. Alcune informazioni usate nelle interfacce sono incorporate nello shader stesso, ad esempio le tabelle delle funzioni e le tabelle dei tipi di classe. L'hardware è necessario solo per chiamare e indicizzare correttamente queste tabelle, perché il runtime esegue tutte le operazioni di gestione necessarie per mantenere le informazioni organizzate e mappate correttamente.

Il test esegue solo scenari validi e verifica che i risultati siano riusciti. Non è previsto alcun errore nell'hardware D3D11 certificabile.

I log di test in WTT come test di conformità precedenti hanno e contengono informazioni utili sull'errore per consentire agli IHV di eseguire il debug degli errori.

Questo argomento si applica ai processi di test seguenti:

• Interfacce WGF11

• Interfacce WGF11 (WoW64)

Dettagli del test

Documentazione aggiuntiva

I test in questa area di funzionalità potrebbero avere documentazione aggiuntiva, inclusi prerequisiti, configurazione e informazioni sulla risoluzione dei problemi, disponibili negli argomenti seguenti:

• Documentazione aggiuntiva di Device.Graphics

Esecuzione del test

Prima di eseguire il test, completare la configurazione di test come descritto nei requisiti di test: Adattatore grafico o Prerequisiti di test del chipset.

Risoluzione dei problemi relativi

Per la risoluzione dei problemi generici degli errori di test HLK, vedere Risoluzione dei problemi di test di Windows HLK.

Per informazioni sulla risoluzione dei problemi, vedere Risoluzione dei problemi relativi ai test di Device.Graphics.

Il test restituisce SKIP quando viene eseguito a livello < di funzionalità 11. Il test restituisce SKIP quando viene eseguito a livello < di funzionalità 11.

Altre informazioni

WGF11Interfaces - Esecuzione dello shader dell'interfaccia

I WGF11Interfaces coprono tutti gli aspetti del trasferimento dei dati al driver, insieme all'esecuzione corretta di shader IL.

Una descrizione di ogni gruppo di test e il parametro della riga di comando necessario è elencato più avanti in questa sezione. Gli shader interi non vengono forniti in questa documentazione. Tuttavia, una descrizione dell'obiettivo previsto dello shader e i tipi di input sono descritti per fornire informazioni su come testare in Windows Hardware Quality Labs (WHQL). Inoltre, ogni test viene eseguito in tutte le fasi shader per verificare un comportamento coerente per una funzionalità che rispetta gli obiettivi dell'architettura unificata.

I test usano ints e uint come input e durante il calcolo, in quanto la precisione e la verifica della matematica a virgola mobile è coperta in un test di conformità diverso.

I test che usano i campioni eseguono il campionamento del punto e usano il colore del bordo per verificare se viene usato il sampler corretto. Il filtro e altri aspetti della copertura di sampler sono trattati in un test di conformità diverso. I test dell'interfaccia sono interessati solo all'indicizzazione corretta degli esempi usati dalle istanze della classe durante l'esecuzione.

I test che usano le risorse riguardano i formati con canali a 8 bit e nessun livello MIP. Altri test verificano la correttezza delle risorse. Il test dell'interfaccia è interessato solo all'indicizzazione corretta delle trame usate dalle istanze della classe durante l'esecuzione. Vengono usati solo carichi di risorse. Poiché non possono essere indicizzati, le UAV non sono importanti per le interfacce.

I test vengono eseguiti in ogni fase dello shader, perché la funzionalità dovrebbe adattarsi all'interno dell'architettura unificata di Shader Model 5.0.

Ogni test ha un'attività Pri-1 e un'attività Pri-2, che, quando combinata, completa la copertura della funzionalità. Le attività Pri-1 richiedono che un test sia eseguito solo in una fase specifica dello shader. Le attività Pri-2 testano le fasi rimanenti dello shader.

Tutte le istanze vengono create dal runtime usando le chiamate API seguenti:

HRESULT CreateClassInstance(LPCWSTR pszClassTypeName,UINT ConstantBufferOffset,UINT ConstantVectorOffset,UINT TextureOffset,UINT SamplerOffset,ID3D11ClassInstance **ppInstance);

Le istanze vengono impostate quando lo shader viene impostato usando le chiamate XXSetShader().

interfacceWGF11Interfaces.exe\FunctionTables e fcall\[ PS]

Pri-1 16 ore

Il test della tabella delle funzioni di grandi dimensioni verifica se l'hardware è in grado di gestire l'output dei programmi shader dal compilatore. Questa verifica è specifica per gli shader che hanno molte chiamate di interfaccia a catena che hanno generato grandi generazioni di codice che hanno molti corpi di funzione. Questo test non verifica le prestazioni di tali shader, ma verifica se l'esecuzione è corretta rispetto al rasterizzatore di riferimento.

Vengono scritti diversi shader che raddoppieranno in sequenza il numero di corpi di funzione creati dal compilatore. Questi shader vengono quindi eseguiti con diverse varianti nelle istanze che riempiono gli slot, per verificare l'esecuzione corretta tramite un subset di percorsi di codice. In qualsiasi momento, il test può tentare di convalidare tutti i percorsi di codice e si prevede che l'hardware non avrà esito negativo in nessuno di essi. Se l'hardware restituisce memoria insufficiente durante il tempo di creazione dello shader, il test restituisce RESULT_SKIP, quando ragionevole. I requisiti delle risorse di questi shader non devono superare i limiti dell'hardware. Di conseguenza, lo shader deve associare ed eseguire solo fine. Se l'hardware ha esito negativo su tabelle di funzioni di piccole dimensioni, si verifica un avviso. L'hardware deve supportare un minimo di 4 KB.

Le funzioni a catena sono progettate usando diversi tipi di interfaccia, ognuno dei quali si basa su un oggetto di un'altra istanza per il relativo parametro. Queste chiamate sono progettate per essere più livelli profondi e possono facilmente causare la creazione di più corpi di funzione 1k.

Il test fornisce anche copertura dell'istruzione fcall chiamando ampiamente altre funzioni per ottenere una copertura appropriata dei corpi delle funzioni di 4 KB nello shader. Questa operazione può essere eseguita variando le istanze associate usando XXSetShader dal runtime. Il framework offre un modo semplice per ottenere una copertura adeguata tramite permutazioni di tipi associati.

Per assicurarsi che il test non richieda manutenzione a causa delle modifiche apportate al compilatore, ogni corpo della funzione deve essere univoco da tutti gli altri corpi di funzione. Questo perché il compilatore può in alcuni casi comprimere i corpi delle funzioni con codice identico per ridurre le dimensioni del codice e fornire una tabella di funzioni più ottimizzata. Assicurandosi che tutti i corpi delle funzioni siano diversi, si impedisce che il test venga modificato o diventi obsoleto quando questa ottimizzazione viene aggiunta al compilatore. È importante esaminare IL per assicurarsi che il codice previsto venga prodotto.

Esempio:

interface Type0{ float2 func( float x );};interface Type1{ float4 func( const Type0 param, inout float2 y );};interface Type2{ float func( Type0 param0, Type1 param1 );};interface Type3{ uint func( out float z, Type0 param0, Type1 param1, Type2 param2 );};class AT0 : Type0;class BT0 : Type0;class CT0 : Type0;class DT0 : Type0;class ET0 : Type0;class FT0 : Type0;class AT1 : Type1;class BT1 : Type1;class CT1 : Type1;class DT1 : Type1;class AT2 : Type2;class BT2 : Type2;class CT2 : Type2;class DT2 : Type2;class ET2 : Type2;class AT3 : Type3;class BT3 : Type3;class CT3 : Type3;class DT3 : Type3;class ET3 : Type3;class FT3 : Type3;

Se l'interfaccia per Type3 viene chiamata e ogni implementazione chiama il metodo di interfaccia di un parametro di input, i corpi delle funzioni 720 vengono creati da tutti i percorsi di codice possibili, ognuno ottimizzato per il relativo percorso di codice specifico. Poiché non esiste alcuna limitazione alle dimensioni del codice diverse dalla memoria, anche gli shader molto grandi devono essere eseguiti senza errori.

Il codice shader è ottimizzato nei siti di fcall, quindi è possibile che ogni chiamata sia univoca in base alle informazioni del chiamante e del chiamante. La moltiplicazione semplice per una costante non è sufficiente; invece, ogni corpo della funzione deve essere univoco eseguendo operazioni diverse e usando variabili membro. L'output risultante deve essere verificato, quindi la moltiplicazione in base ai numeri primi o a qualcosa di simile funzionerebbe. Per verificare che lo shader sia stato eseguito correttamente, è necessario eseguire la stessa matematica sulla CPU in base alle istanze della classe associata.

Questo test illustra anche la profondità dell'albero delle chiamate (32). È importante testare che più di 32 fcalls comportano operazioni senza operazioni (è possibile testare solo 33 in un determinato momento). Il compilatore non consente la scrittura del codice per testare semplicemente questo caso, quindi è necessario un approccio più sofisticato che può modificare dinamicamente la profondità della chiamata e verificare che ogni chiamata sia stata effettuata (o meno).

Una sequenza fibinachi o simile potrebbe essere utile per questo. Le chiamate ricorsive non sono consentite, quindi devono essere presenti 33 interfacce che possono essere chiamate una dopo l'altra. In locale, le istanze devono decidere se continuare la profondità della chiamata. Il runtime associa i dati per eseguire questi test.

Questo test viene scritto per il pixel shader come Pri-1.

Il completamento di questo test dimostra quanto segue:

• Il fcall funziona.

• Le tabelle delle funzioni sono corrette e vengono usate correttamente.

• Il limite di tabella delle funzioni 4 KB è supportato.

• La profondità della chiamata è 32.

I risultati per il test vengono acquisiti nella destinazione di rendering seguente:

interfacceWGF11Interfaces.exe\FunctionTables e fcall \[VS,GS, HS,DS,CS]

Pri-2

Il test copre tutte le fasi dello shader.

La verifica di questa funzionalità supporta un'ampia gamma di modelli di progettazione validi e tecniche di programmazione OO progettate per supportare Shader Model 5.0.

I risultati di questi test vengono acquisiti in un buffer di uscita di flusso per VS,HS, DS e GS. I risultati per PS e CS vengono acquisiti dalle destinazioni di rendering e dai buffer scrivibili.

interfacceWGF11Interfaces.exe\GroupExecutionPathDifferences\[ CS]

Pri-1 40 ore

L'uso del parallelismo è molto importante durante la progettazione dell'hardware. Tuttavia, la capitalizzazione di tali opportunità non deve interrompere l'esecuzione corretta di uno shader quando i percorsi di codice si differenziano. Questo test viene eseguito in ogni fase dello shader e fornisce copertura che esegue percorsi di codice diversi, nonostante il fatto che pixel, vertici e altre primitive della fase della pipeline potrebbero essere eseguite come gruppi di passaggi di blocco. Questo test non testa le prestazioni in questi casi. Verifica invece solo un risultato valido dopo l'esecuzione.

La fornitura di dati a ogni fase della pipeline è importante e deve essere eseguita in blocchi ridimensionabili per verificare la copertura di un'esecuzione varia tra i gruppi. Il metodo seguente fornisce i dati ai test per ogni fase shader:

• Compute Shader:

  I dati usati per selezionare le istanze basate sugli slot di matrice vengono fornite usando le risorse per lo shader di calcolo. Le SV_GroupID e le SV_GroupThreadID vengono usate per selezionare i dati corretti dalla risorsa per scegliere quali istanze di classe usare durante la chiamata di uno shader. I risultati dell'esecuzione vengono scritti in un buffer scrivibile da verificare che sia corretto. Viene usato un numero elevato di dimensioni dei thread in ogni dimensione. Ciò include grandi numeri primi di thread e più gruppi che verranno inviati per ottenere una copertura adeguata per questo test.

Ogni thread hardware deve eseguire una chiamata al metodo in un tipo diverso fornito dal runtime. Il runtime è in grado di calcolare il risultato per la verifica in base al tipo usato, ai dati forniti e all'algoritmo del tipo. Il codice per ogni metodo deve variare in lunghezza e complessità per dimostrare che l'hardware può gestire shader come questo. È necessario usare implementazioni di classi diverse da 12 a 18 e ogni valore SV_[Index] può essere pseudo modificato per selezionare l'indice della matrice e l'istanza della classe da eseguire.

WGF11Interfaces.exe interfacce\GroupExecutionPathDifferences\[VS,GS,PS,HS,DS]

Pri-2 40 ore

Il test viene esteso alle altre fasi dello shader.

• Vertex Shader:

  Un set di indici array slot dell'interfaccia vengono aggiunti ai dati del vertice e usati durante l'esecuzione del vertex shader per determinare quale istanza dell'interfaccia richiamare. I dati illustrano anche quali istanze vengono usate come parametri quando vengono richiamati i metodi. Un blocco di almeno 512 punti viene disegnato per verificare il comportamento hardware. I risultati vengono rilevati da un buffer di uscita del flusso.

• Hull Shader:

  Gli indici della matrice slot dell'interfaccia vengono aggiunti alla struttura di input del punto di controllo, consentendo a ogni punto di determinare quali istanze di classe vengono richiamate nel corso dello shader. Questi dati illustrano anche quali istanze vengono usate come parametri quando vengono richiamati i metodi. Una patch completa a 32 punti viene disegnata più volte per verificare il comportamento hardware. I risultati verranno rilevati da un buffer di uscita di flusso.

  Questo test inoltra anche i dati alla funzione Patch Constant, che verifica anche il comportamento corretto.

  Inoltre, l'SV_OutputControlPointID e il codice di fork specifico vengono attivati nel compilatore. Anche il codice di fork causa percorsi di esecuzione di codice divergenti usando interfacce in questa fase. È possibile accedere al fork usando un ciclo e chiamando un metodo di interfaccia dall'interno del ciclo.

• Domain Shader:

  I dati vengono passati attraverso lo shader Hull in ogni punto di controllo e quindi recuperati usando la SV_PrimitiveID disponibile in Domain Shader. Le posizioni di output del tessellatore vengono combinate con la SV_PrimitiveID per creare gli indici negli slot dell'istanza di classe disponibili durante l'esecuzione. La patch completa a 32 punti viene disegnata più volte per verificare il comportamento hardware. I risultati vengono rilevati da un buffer di uscita del flusso. Lo stato attivo non è quello di coprire tutti i tipi di dominio.

• Geometry Shader:

  Gli indici dello slot dell'interfaccia sono collegati alle primitive che vengono fornite al geometry shader. Gli indici vengono usati per scegliere le istanze della classe per richiamare i metodi e usarli come parametri durante l'esecuzione dello shader. Un blocco di almeno 512 punti viene disegnato per verificare il comportamento hardware. I risultati vengono acquisiti in un buffer di uscita di flusso per la verifica.

• Pixel Shader:

  Per i pixel shader, viene usata una trama per fornire gli indici dell'istanza della classe per ogni pixel. La trama corrisponde esattamente alle dimensioni della destinazione di rendering disegnando un quad di grandi dimensioni. Un'area di almeno 512x512 pixel viene disegnata, con le risorse di supporto, per verificare il comportamento hardware. I risultati vengono acquisiti in una destinazione di rendering per la convalida. SV_Position e SV_SampleIndex possono essere usati anche per determinare come un indice pixel negli slot dell'interfaccia. Il disegno di un triangolo è più interessante del disegno di un quad.

interfacceWGF11Interfaces.exe\IndexingResources e questo[]\[VS]

Pri-1 26 ore

Tutte le risorse usate da un'interfaccia sono state rese indicizzate dal servizio di integrazione per supportare l'associazione dinamica di runtime. I dati vengono forniti tramite DDI e includono le informazioni seguenti:

• ID tipo di classe

• Cbuffer

• Offset Cbuffer

• Slot trama

• Slot sampler

Questo test garantisce che tutte queste informazioni vengano usate correttamente dall'esecuzione del driver e dello shader. L'accesso a queste informazioni può essere eseguito solo tramite la parola chiave "this", che usa un buffer riservato nascosto. Le istanze di classe che sono 256 bytescan devono essere associate a uno shader, quindi questo test fornisce copertura per l'uso di tutti gli slot di istanza di 256. Ciò implica che questa operazione deve essere usata in combinazione con ognuna delle altre aree di questo test. Tuttavia, le altre aree non devono essere verificate tramite la permutazione tra loro.

Posizione dei cicli di test per tutti gli slot e gli offset diversi nelle risorse e usa tali risorse durante la produzione di risultati.

Per ottenere una copertura completa, ogni istanza di classe deve eseguire un metodo che usa i dati delle risorse per produrre un risultato. A tale scopo, garantisce che l'ID del tipo di istanza venga usato correttamente rispetto alle tabelle delle funzioni.

Ogni cbuffer deve essere testato per i dati della classe. I dati devono essere inseriti nel buffer usando il parametro offset. Questa operazione può essere eseguita associando 256 istanze ognuna con un percorso diverso impostato dal runtime. Lo shader può eseguire 256 vertici e usare il SV_PrimitiveID per determinare lo slot dell'istanza da usare.

Ogni slot tbuffer nella versione 128 disponibile deve essere usato nello stesso modo indicato in precedenza. È necessario usare solo un buffer semplice o trama2d e viene testata solo l'istruzione di caricamento. Il test è interessato solo all'indicizzazione corretta dei registri delle trame.

Ogni slot del campionatore nella fase 16 disponibile per uno shader deve essere usato nello stesso modo indicato in precedenza. I campionatori verranno campionati all'esterno del limite della trama in modo che venga restituito un colore del bordo. Ognuno dei 16 campionatori deve avere un colore di bordo univoco per consentire al test di verificare che sia stato usato il campionatore corretto.

La copertura combinata può essere testata separatamente non è necessaria.

F11Intefaces.exe Interfaces\IndexingResources e this[]\[GS,PS,HS,DS,CS]

Pri-2 26 ore

Il test precedente viene esteso per coprire tutte le fasi dello shader.

(Pri 1 18 ore) Il contesto posticipato deve essere usato anche in questi test.

I test case descritti verranno eseguiti anche in un contesto posticipato usando elenchi di comandi per impostare classi e istanze.

Gli elenchi di comandi non ereditano lo stato dal contesto immediato. Pertanto, le istanze impostate nel contesto immediato non devono essere accessibili quando si esegue un elenco di comandi.

La cancellazione dello stato nel contesto posticipato (tramite il parametro bool in ExecuteCommandList e FinishCommandList) deve essere testata con interfacce e classi.

Sintassi dei comandi

Elenco file

Parametri