Interfacce WGF11 (WoW64)
Questo test automatizzato verifica parti diverse dell'hardware e del 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 IHD di eseguire il debug degli errori.The test logs to WTT as previous conformance tests have, and contain useful information about the failure to help IHVs to debug their failure.
Questo argomento si applica ai processi di test seguenti:
Interfacce WGF11
Interfacce WGF11 (WoW64)
Dettagli del test
Specifiche |
|
Piattaforme |
|
Versioni supportate |
|
Tempo di esecuzione previsto (in minuti) | 2 |
Categoria | Compatibilità |
Timeout (in minuti) | 120 |
Richiede il riavvio | false |
Richiede una configurazione speciale | false |
Tipo | automatic |
Documentazione aggiuntiva
I test in questa area di funzionalità potrebbero avere documentazione aggiuntiva, inclusi i prerequisiti, la configurazione e le informazioni sulla risoluzione dei problemi, disponibili negli argomenti seguenti:
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 generica 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 a Device.Graphics Testing.
Il test restituisce SKIP quando viene eseguito al livello < di funzionalità 11. Il test restituisce SKIP quando viene eseguito al 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 IL dello shader.
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 sono disponibili in questa documentazione. Tuttavia, viene descritta una descrizione dell'obiettivo previsto dello shader e i tipi di input per fornire informazioni su come eseguire il test in Windows Hardware Quality Labs (WHQL). Inoltre, ogni test viene eseguito in tutte le fasi dello shader per verificare un comportamento coerente per una funzionalità conforme agli obiettivi dell'architettura unificata.
I test usano ints e uint come input e durante il calcolo laddove possibile, perché la precisione e la verifica della matematica a virgola mobile sono trattate in un test di conformità diverso.
I test che usano campionatori eseguono il campionamento dei punti e usano il colore del bordo per verificare se viene usato il campionatore corretto. I filtri e altri aspetti della copertura del campionatore sono trattati in un test di conformità diverso. Il test dell'interfaccia riguarda solo l'indicizzazione corretta dei campionatori usati dalle istanze di classe durante l'esecuzione.
Test che usano risorse incentrate sui formati con canali a 8 bit e senza livelli MIP. Altri test verificano la correttezza delle risorse. Il test dell'interfaccia riguarda solo l'indicizzazione corretta delle trame usate dalle istanze di classe durante l'esecuzione. Vengono usati solo i carichi di risorse. Poiché non possono essere indicizzati, gli UAV non sono importanti per le interfacce.
I test vengono eseguiti in ogni fase dello shader, perché la funzionalità deve rientrare nell'architettura unificata del modello shader 5.0.
Ogni test ha un'attività Pri-1 e un'attività Pri-2, che, se combinata, completa la copertura della funzionalità. Le attività Pri-1 richiedono l'esecuzione di un test 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
La tabella delle funzioni di grandi dimensioni verifica se l'hardware è in grado di gestire i programmi shader restituiti dal compilatore. Questa verifica è specifica per gli shader che hanno molte chiamate di interfaccia a catena che hanno generato grandi generazioni di codice con molti corpi di funzione. Questo test non testa 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 ed è previsto 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 essere associato ed eseguito correttamente. Se l'hardware ha esito negativo anche in tabelle di funzioni di piccole dimensioni, si verifica un avviso. L'hardware deve supportare almeno 4 KB corpi di funzione.
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 comportare la creazione di più di 1k corpi di funzione.
Il test fornisce anche la copertura dell'istruzione fcall chiamando ampiamente altre funzioni per ottenere la copertura appropriata dei corpi delle funzioni di 4 KB nello shader. A tale scopo, è possibile variare le istanze associate usando XXSetShader dal runtime. Il framework offre un modo semplice per ottenere una copertura adeguata tramite permutazioni di tipi associati.
Per garantire 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. Ciò è dovuto al fatto che il compilatore può a un certo punto comprimere i corpi di funzione con codice identico per ridurre le dimensioni del codice e fornire una tabella di funzioni più ottimizzata. Assicurandosi che tutti i corpi di funzione siano diversi, si impedisce che il test venga modificato o diventi obsoleto quando questa ottimizzazione viene aggiunta al compilatore. È importante esaminare il servizio di bilanciamento del carico interno per assicurarsi che venga prodotto il codice previsto.
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 viene chiamata l'interfaccia per Type3 e ogni implementazione chiama il metodo di interfaccia di un parametro di input, vengono creati 720 corpi di funzione 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 di grandi dimensioni devono essere eseguiti senza errori.
Il codice shader è ottimizzato nei siti fcall, quindi è possibile che ogni chiamata sia univoca in base alle informazioni del chiamante e del chiamato. La moltiplicazione semplice per una costante non è sufficiente; Al contrario, ogni corpo della funzione deve essere univoco eseguendo operazioni diverse e usando variabili membro. L'output risultante deve essere verificato, quindi la moltiplicazione per numeri primi o un risultato 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 verificare che più di 32 fcalls comportino operazioni senza operazioni (è possibile testare solo 33 in un determinato momento). Il compilatore non consente la scrittura del codice per testare semplicemente questo case, 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 o meno 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:
La chiamata fcall funziona.
Le tabelle delle funzioni sono corrette e vengono usate correttamente.
È supportato il limite di tabella delle funzioni di 4 KB.
La profondità della chiamata è 32.
I risultati del 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 il modello shader 5.0.
I risultati di questi test vengono acquisiti in un buffer di uscita del 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 quando si progetta l'hardware. Tuttavia, la capitalizzazione di tali opportunità non deve interrompere l'esecuzione corretta di uno shader quando i percorsi del codice divergono. Questo test viene eseguito in ogni fase dello shader e fornisce una copertura che esegue percorsi di codice diversi, nonostante i pixel, i vertici e altre primitive della fase della pipeline vengano eseguite come gruppi di passaggi di blocco. Questo test non testa le prestazioni in questi casi. Viene invece verificato solo un risultato valido dopo l'esecuzione.
Fornire dati a ogni fase della pipeline è importante e deve essere eseguito in blocchi ridimensionabili per verificare la copertura dell'esecuzione varia tra i gruppi. Il metodo seguente fornisce i dati ai test per ogni fase dello shader:
Compute Shader:
I dati usati per selezionare le istanze basate sugli slot di matrice vengono forniti 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 le istanze di classe da usare durante la chiamata di uno shader. I risultati dell'esecuzione vengono scritti in un buffer scrivibile per verificare che sia corretto. Viene utilizzato un numero elevato di dimensioni dei thread in ogni dimensione. Sono inclusi un numero elevato 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. È consigliabile 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 di matrice slot di interfaccia vengono aggiunti ai dati dei vertici e usati durante l'esecuzione del vertex shader per determinare l'istanza dell'interfaccia da 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 dello slot di 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. Tali dati illustrano anche le istanze usate come parametri quando vengono richiamati i metodi. Una patch completa a 32 punti viene disegnata più volte per verificare il comportamento dell'hardware. I risultati verranno rilevati da un buffer di uscita del flusso.
Questo test inoltra anche i dati alla funzione Patch Constant, che verifica anche il comportamento corretto.
Inoltre, le SV_OutputControlPointID e il codice di fork specifico vengono attivati nel compilatore. Il codice di fork causa percorsi di esecuzione di codice divergenti usando anche le interfacce in questa fase. È possibile accedere alla copia tramite un ciclo e chiamando un metodo di interfaccia dall'interno del ciclo .
Domain Shader:
I dati vengono passati attraverso lo hull shader in ogni punto di controllo e quindi recuperati usando il SV_PrimitiveID disponibile in Domain Shader. Le posizioni di output del tassellatore vengono combinate con il SV_PrimitiveID per creare gli indici negli slot di istanza della 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 riguarda tutti i tipi di dominio.
Geometry Shader:
Gli indici dello slot di interfaccia sono collegati a primitive di punta che vengono fornite al geometry shader. Gli indici vengono usati per scegliere le istanze di 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 del 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 alla dimensione della destinazione di rendering disegnando un quad grande. Viene disegnata un'area di almeno 512x512 pixel, 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 il modo in cui un indice pixel viene inserito negli slot di interfaccia. Il disegno di un triangolo è più interessante del disegno di un quad.
interfacceWGF11Interfaces.exe\IndexingResources e this[]\[VS]
Pri-1 26 ore
Tutte le risorse usate da un'interfaccia sono state rese indicizzabili dal servizio di bilanciamento del carico interno per supportare l'associazione di runtime dinamica. 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 a 256 bytescan devono essere associate a uno shader, quindi questo test fornisce copertura per l'uso di tutti i 256 slot di istanza. In questo modo, ciò implica che questo deve essere usato in combinazione con ognuna delle altre aree di questo test. Tuttavia, le altre aree non devono essere verificate tramite permutazione tra loro.
Posizione dei cicli di test per tutti i diversi slot e offset nelle risorse e usa tali risorse quando si producono risultati.
Per ottenere la copertura completa, ogni istanza di classe deve eseguire un metodo che usa i dati delle risorse per produrre un risultato. In questo modo, 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 in tutto il buffer usando il parametro offset. Questa operazione può essere eseguita associando 256 istanze ognuna con una posizione diversa impostata dal runtime. Lo shader può eseguire 256 vertici e usare il SV_PrimitiveID per determinare lo slot di istanza da usare.
Ogni slot tbuffer nella versione 128 disponibile deve essere usato nello stesso modo indicato in precedenza. È necessario usare solo un semplice buffer o trama2d e viene testata solo l'istruzione di caricamento. Il test è interessato solo all'indicizzazione corretta dei registri di trama.
Ogni slot di sampler nella fase 16 disponibile per una fase shader deve essere usato nello stesso modo indicato in precedenza. Gli esempi verranno campionati all'esterno del limite di trama in modo che venga restituito un colore del bordo. Ognuno dei 16 campioni deve avere un colore di bordo univoco per verificare che sia stato usato il sampler corretto.
Questi possono essere testati separatamente la copertura combinata non è necessaria.
interfacceF11Intefaces.exe\IndexingResources e questo[]\[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 durante l'esecuzione di 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
Opzione comando | Descrizione |
---|---|
Wgf11interfaces |
Esegue i processi di test. Senza opzioni, il test enumera i dispositivi. |
-FeatureLevel:XX.X |
Imposta la funzionalità lewlve, dove XX.X è il livello di funzionalità che verrà eseguito a: 10.0, 10.1 o 11.0. |
Nota
Per la Guida della riga di comando per questo file binario di test, digitare /?.
Elenco file
File | Posizione |
---|---|
Configdisplay.exe |
<[testbinroot]>\nttest\windowstest\tools\ |
D3d11_1sdklayers.dll |
<[testbinroot]>\nttest\windowstest\graphics\d3d\support\ |
D3d11ref.dll |
<[testbinroot]>\nttest\windowstest\graphics\d3d\support\ |
D3d11sdklayers.dll |
<[testbinroot]>\nttest\windowstest\graphics\d3d\support\ |
D3dcompiler_test.dll |
<[testbinroot]>\nttest\windowstest\graphics\d3d\support |
D3dx10_test.dll |
<[testbinroot]>\nttest\windowstest\graphics\d3d\support\ |
d3dx11_test.dll |
<[testbinroot]>\nttest\windowstest\graphics\d3d\support\ |
TDRWatch.exe |
<[testbinroot]>\nttest\windowstest\graphics\ |
Wgf11interfaces.exe |
<[testbinroot]>\nttest\windowstest\graphics\d3d\conf |
Parametri
Nome parametro | Descrizione dei parametri |
---|---|
MODIFIEDCMDLINE | Argomenti aggiuntivi della riga di comando per il file eseguibile di test |
LLU_NetAccessOnly | Nome LLU dell'utente net |
ConfigDisplayCommandLine | Riga di comando personalizzata per ConfigDisplay. Impostazione predefinita: logo |
TDRArgs | /get o /set |