Interfaces WGF11 (WoW64)
Esse teste automatizado verifica diferentes partes do hardware e do driver para execução válida do sombreador quando as interfaces são usadas.
O teste se concentra em cobrir informações ocultas de buffer fornecidas ao driver por meio da DDI, que inclui tipos de interface e locais de recursos. Algumas informações usadas em interfaces são inseridas no próprio sombreador, como tabelas de funções e tabelas de tipo de classe. O hardware só é necessário para chamar e indexar corretamente essas tabelas, pois o runtime faz todo o gerenciamento necessário para manter as informações organizadas e mapeadas corretamente.
O teste executa apenas cenários válidos e verifica se os resultados foram bem-sucedidos. Não se espera que ocorram falhas no hardware D3D11 certificado.
Os logs de teste no WTT como os testes de conformidade anteriores têm e contêm informações úteis sobre a falha em ajudar os IHVs a depurar suas falhas.
Este tópico se aplica aos seguintes trabalhos de teste:
WGF11 Interfaces
Interfaces WGF11 (WoW64)
Detalhes do teste
| Especificações |
|
| Plataformas |
|
| Versões com suporte |
|
| Tempo de execução esperado (em minutos) | 2 |
| Categoria | Compatibilidade |
| Tempo limite (em minutos) | 120 |
| Requer reinicialização | false |
| Requer configuração especial | false |
| Tipo | automático |
Documentação adicional
Os testes nessa área de recursos podem ter documentação adicional, incluindo pré-requisitos, configuração e informações de solução de problemas, que podem ser encontrados nos tópicos a seguir:
Executando o teste
Antes de executar o teste, conclua a configuração de teste conforme descrito nos requisitos de teste: Pré-requisitos do Adaptador Gráfico ou do Teste de Chipset.
Solucionando problemas
Para solucionar problemas genéricos de falhas de teste do HLK, consulte Solução de problemas de falhas de teste do Windows HLK.
Para obter informações de solução de problemas, consulte Solução de problemas de teste de device.graphics.
O teste retorna SKIP quando executado no nível < de recurso 11. O teste retorna SKIP quando executado no nível < de recurso 11.
Mais informações
WGF11Interfaces – Execução do sombreador de interface
Os WGF11Interfaces abrangem todos os aspectos da transferência de dados para o driver, juntamente com a execução correta do sombreador IL.
Uma descrição de cada grupo de teste e do parâmetro de linha de comando necessário é listada posteriormente nesta seção. Sombreadores inteiros não são fornecidos nesta documentação. No entanto, uma descrição da meta pretendida do sombreador e os tipos de entradas são descritos para fornecer informações sobre como testar no WHQL (Windows Hardware Quality Labs). Além disso, cada teste é executado em todos os estágios do sombreador para verificar o comportamento consistente de um recurso que segue as metas de arquitetura unificada.
Os testes usam ints e uints como entradas e durante o cálculo sempre que possível, pois a precisão e a verificação da matemática de ponto flutuante são abordadas em um teste de conformidade diferente.
Os testes que usam exemplos executam amostragem de ponto e usam a cor da borda para verificar se o sampler correto é usado. A filtragem e outros aspectos da cobertura do sampler são abordados em um teste de conformidade diferente. O teste de interface só se preocupa com a indexação correta de exemplos que são usados por instâncias de classe durante a execução.
Os testes que usam recursos se concentram em formatos com canais de 8 bits e sem níveis de MIP. Outros testes verificam a correção do recurso. O teste de interface só se preocupa com a indexação correta de texturas que são usadas por instâncias de classe durante a execução. Somente cargas de recursos são usadas. Como eles não podem ser indexados, os UAVs não são importantes para interfaces.
Os testes são executados em cada estágio de sombreador, pois o recurso deve se ajustar à arquitetura unificada do Modelo de Sombreador 5.0.
Cada teste tem uma tarefa Pri-1 e uma tarefa Pri-2, que, quando combinada, completam a cobertura do recurso. As tarefas pri-1 exigem que um teste seja executado somente em um estágio de sombreador específico. As tarefas pri-2 testam os estágios restantes do sombreador.
Todas as instâncias são criadas pelo runtime usando as seguintes chamadas à API:
HRESULT CreateClassInstance(LPCWSTR pszClassTypeName,UINT ConstantBufferOffset,UINT ConstantVectorOffset,UINT TextureOffset,UINT SamplerOffset,ID3D11ClassInstance **ppInstance);
As instâncias são definidas quando o sombreador é definido usando chamadas XXSetShader().
WGF11Interfaces.exe Interfaces\FunctionTables e fcall\[ PS]
Pri-1 1 16 horas
O teste de tabela de funções grandes verifica se o hardware é capaz de gerenciar a saída de programas de sombreador pelo compilador. Essa verificação é específica para sombreadores que têm muitas chamadas de interface em cascata que resultaram em grandes gerações de código que têm muitos corpos de função. Esse teste não testa o desempenho desses sombreadores, mas testa se a execução está correta quando comparada com o rasterizador de referência.
Vários sombreadores são gravados que sequencialmente dobrarão o número de corpos de função criados pelo compilador. Esses sombreadores são então executados com várias variações nas instâncias que preenchem os slots, a fim de verificar a execução correta por meio de um subconjunto de caminhos de código. A qualquer momento, o teste pode tentar validar todos os caminhos de código e espera-se que o hardware não falhe em nenhum deles. Se o hardware retornar memória insuficiente durante o tempo de criação do sombreador, o teste retornará RESULT_SKIP, quando razoável. Os requisitos de recursos desses sombreadores não devem efetuar push dos limites de hardware. Dessa forma, o sombreador deve associar e executar muito bem. Se o hardware falhar em tabelas de funções pequenas, ocorrerá um aviso. O hardware deve dar suporte a um mínimo de 4 KB corpos de função.
As funções em cascata são projetadas usando vários tipos de interface, cada um dependendo de um objeto de outra instância para seu parâmetro. Essas chamadas foram projetadas para serem várias camadas profundas e podem facilmente resultar na criação de mais de 1 mil corpos de função.
O teste também fornece cobertura da instrução fcall chamando extensivamente outras funções para obter a cobertura apropriada dos corpos da função de 4 KB no sombreador. Isso pode ser feito variando as instâncias associadas usando XXSetShader pelo runtime. A estrutura fornece uma maneira simples de obter cobertura adequada por meio de permutações de tipos associados.
Para garantir que o teste não precise de manutenção devido a alterações no compilador, cada corpo da função deve ser exclusivo de todos os outros corpos de função. Isso ocorre porque o compilador pode, em algum momento, recolher corpos de função com código idêntico para reduzir o tamanho do código e fornecer uma tabela de funções mais otimizada. Ao garantir que todos os corpos de função sejam diferentes, você impede que o teste seja alterado ou se torne obsoleto quando essa otimização for adicionada ao compilador. É importante examinar a IL para garantir que o código esperado seja produzido.
Exemplo:
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 a interface do Type3 for chamada e cada implementação chamar o método de interface de um parâmetro de entrada, 720 corpos de função serão criados por todos os caminhos de código possíveis, cada um otimizado para seu caminho de código específico. Como não há limitação para o tamanho do código além da memória, mesmo sombreadores muito grandes devem ser executados sem erro.
O código do sombreador é otimizado em sites fcall, portanto, é possível que cada chamada seja exclusiva com base nas informações do chamador e do receptor. A multiplicação simples por uma constante não é suficiente; Em vez disso, cada corpo da função deve ser exclusivo fazendo operações diferentes e usando variáveis de membro. A saída resultante deve ser verificada, portanto, a multiplicação por números primos ou algo semelhante funcionaria. Para verificar se o sombreador foi executado corretamente, a mesma matemática deve ser feita na CPU com base nas instâncias de classe associadas.
Este teste também aborda a profundidade da árvore de chamadas (32). É importante testar se mais de 32 fcalls resultam em no-ops (você só pode testar 33 em um determinado momento). O compilador não permite que o código seja gravado para simplesmente testar esse caso, portanto, você precisa de uma abordagem mais sofisticada que possa alterar dinamicamente a profundidade da chamada e verificar se cada chamada foi feita (ou não feita).
Uma sequência fibinachi ou semelhante pode ser útil para isso. Chamadas recursivas não são permitidas, portanto, deve haver 33 interfaces que podem ser chamadas uma após a outra. Localmente, as instâncias devem decidir se devem ou não continuar a profundidade de fcall. O runtime associa os dados para conduzir esses testes.
Este teste é gravado para o sombreador de pixel como Pri-1.
A conclusão deste teste prova o seguinte:
O fcall funciona.
As tabelas de função estão corretas e estão sendo usadas corretamente.
Há suporte para o limite da tabela de 4 KB.
A profundidade da chamada é 32.
Os resultados do teste são capturados no seguinte destino de renderização:
WGF11Interfaces.exe Interfaces\FunctionTables e fcall \[VS,GS, HS,DS,CS]
Pri-2
O teste abrange todos os estágios do sombreador.
A verificação desse recurso dá suporte a uma ampla gama de padrões de design válidos e técnicas de programação de OO que o Shader Model 5.0 foi projetado para dar suporte.
Os resultados desses testes são capturados em um buffer de fluxo para VS, HS, DS e GS. Os resultados de PS e CS são capturados por destinos de renderização e buffers graváveis.
WGF11Interfaces.exe Interfaces\GroupExecutionPathDifferences\[ CS]
Pri-1 40 horas
Explorar o paralelismo é muito importante ao projetar hardware. No entanto, a capitalização dessas oportunidades não deve interromper a execução correta de um sombreador quando os caminhos de código divergem. Esse teste é executado em cada estágio de sombreador e fornece cobertura que executa caminhos de código diferentes, apesar do fato de que pixels, vértices e outros primitivos do estágio de pipeline podem estar sendo executados como grupos de etapas de bloqueio. Esse teste não testa o desempenho nesses casos. Em vez disso, ele só verifica um resultado válido após a execução.
Fornecer dados para cada estágio de pipeline é importante e deve ser feito em partes dimensionáveis para verificar a cobertura de execução variada entre grupos. O método a seguir fornece os dados para os testes para cada estágio de sombreador:
Sombreador de Computação:
Os dados usados para selecionar instâncias baseadas em slots de matriz são fornecidos usando recursos para o sombreador de computação. Os SV_GroupID e SV_GroupThreadID são usados para selecionar os dados corretos do recurso para escolher quais instâncias de classe usar durante a invocação de um sombreador. Os resultados da execução são gravados em um buffer gravável a ser verificado que ele está correto. Uma grande contagem de dimensões de threads em cada dimensão é usada. Isso inclui grandes números primos de threads e vários grupos que serão enviados para obter cobertura adequada para este teste.
Cada thread de hardware deve executar uma chamada de método em um tipo diferente fornecido pelo runtime. O runtime é capaz de calcular o resultado da verificação com base no tipo usado, nos dados fornecidos e no algoritmo do tipo. O código para cada método deve variar em comprimento e complexidade para provar que o hardware pode lidar com sombreadores como este. 12-18 implementações de classe diferentes devem ser usadas e cada valor SV_[Índice] pode ser pseudo-modded para escolher qual índice de matriz e qual instância de classe executar.
WGF11Interfaces.exe Interfaces\GroupExecutionPathDifferences\[VS,GS,PS,HS,DS]
Pri-2 40 horas
O teste é estendido para os outros estágios do sombreador.
Sombreador de vértice:
Um conjunto de índices de matriz de slots de interface são adicionados aos dados de vértice e usados durante a execução do sombreador de vértice para determinar qual instância de interface invocar. Os dados também abrangem quais instâncias são usadas como parâmetros quando os métodos são invocados. Um bloco de pelo menos 512 pontos é desenhado para verificar o comportamento do hardware. Os resultados são capturados por um buffer de saída de fluxo.
Sombreador de casco:
Os índices de matriz de slots de interface são adicionados à estrutura de entrada do ponto de controle, permitindo que cada ponto determine quais instâncias de classe são invocadas ao longo do sombreador. Esses dados também abrangem quais instâncias são usadas como parâmetros quando os métodos são invocados. Um patch completo de 32 pontos é desenhado várias vezes para verificar o comportamento do hardware. Os resultados serão capturados por um buffer de fluxo.
Esse teste também encaminha os dados para a função Constante de Patch, que também verifica o comportamento correto.
Além disso, o SV_OutputControlPointID e o código de bifurcação específico são ativados no compilador. O código de bifurcação também causa caminhos de execução de código divergentes usando interfaces nesse estágio. A bifurcação pode ser acessada usando um loop e chamando um método de interface de dentro do loop.
Sombreador de Domínio:
Os dados são passados pelo sombreador Hull em cada ponto de controle e recuperados usando o SV_PrimitiveID disponível no Sombreador de Domínio. As posições de saída do mosaico são combinadas com o SV_PrimitiveID para criar os índices nos slots de instância de classe disponíveis durante a execução. O patch completo de 32 pontos é desenhado várias vezes para verificar o comportamento do hardware. Os resultados são capturados por um buffer de saída de fluxo. O foco não é abranger todos os tipos de domínio.
Sombreador geometry:
Os índices de slot de interface são anexados aos primitivos de ponto fornecidos ao sombreador de geometria. Os índices são usados para escolher instâncias de classe para invocar métodos e usar como parâmetros durante a execução do sombreador. Um bloco de pelo menos 512 pontos é desenhado para verificar o comportamento do hardware. Os resultados são capturados em um buffer de fluxo para verificação.
Sombreador de Pixel:
Para sombreadores de pixel, uma textura é usada para fornecer os índices de instância de classe para cada pixel. A textura corresponde exatamente ao tamanho do destino de renderização desenhando um quad grande. Uma área de pelo menos 512 x 512 pixels é desenhada, com os recursos de suporte, para verificar o comportamento do hardware. Os resultados são capturados em um destino de renderização para validação. SV_Position e SV_SampleIndex também podem ser usados para determinar como um pixel indexa nos slots de interface. Desenhar um triângulo é mais interessante do que desenhar um quadriciclo.
WGF11Interfaces.exe Interfaces\IndexingResources e este[]\[VS]
Pri-1 26 horas
Todos os recursos usados por uma interface foram indexáveis pela IL para dar suporte à associação dinâmica de runtime. Os dados são fornecidos por meio da DDI e incluem as seguintes informações:
ID do tipo de classe
Cbuffer
Deslocamento cbuffer
Slot de textura
Slot de amostra
Esse teste garante que todas essas informações sejam usadas corretamente pelo driver e pela execução do sombreador. O acesso a essas informações só pode ser feito por meio do palavra-chave "this", que usa um buffer reservado oculto. As instâncias de classe com 256 bytes podem ser associadas a um sombreador, portanto, esse teste fornece cobertura para usar todos os slots de 256 instâncias. Isso implica que isso precisa ser usado em combinação com cada uma das outras áreas neste teste. No entanto, as outras áreas não precisam ser verificadas por meio de permutação entre si.
O teste percorre o local para todos os diferentes slots e deslocamentos nos recursos e usa esses recursos ao produzir resultados.
Para obter cobertura completa, cada instância de classe deve executar um método que usa os dados de recurso para produzir um resultado. Ao fazer isso, ele garante que a ID do tipo de instância esteja sendo usada corretamente em relação às tabelas de função.
Cada cbuffer deve ser testado para dados de classe. Os dados precisam ser colocados em todo o buffer usando o parâmetro offset. Isso pode ser feito associando 256 instâncias cada uma com um local diferente definido pelo runtime. O sombreador pode executar 256 vértices e usar o SV_PrimitiveID para determinar o slot de instância a ser usado.
Cada slot de tbuffer nos 128 disponíveis deve ser usado da mesma maneira que mencionado anteriormente. Somente um buffer simples ou texture2d precisa ser usado e somente a instrução de carga é testada. O teste só está interessado na indexação correta dos registros de textura.
Cada slot de amostra no 16 disponível para um estágio de sombreador deve ser usado da mesma maneira que mencionado anteriormente. Os samplers serão amostrados fora do limite de textura para que uma cor da borda seja retornada. Cada um dos 16 samplers deve ter uma cor de borda exclusiva para que o teste verifique se o sampler correto foi usado.
Eles podem ser testados separadamente– a cobertura combinada é desnecessária.
F11Intefaces.exe Interfaces\IndexingResources e este[]\[GS,PS,HS,DS,CS]
Pri-2 26 horas
O teste anterior é estendido para abranger todos os estágios do sombreador.
(Pri 1 18 horas) O contexto adiado também deve ser usado nesses testes.
Os casos de teste descritos também serão executados em um contexto adiado usando listas de comandos para definir classes e instâncias.
As listas de comandos não herdam o estado do contexto imediato. Portanto, as instâncias definidas no contexto imediato não devem ser acessíveis ao executar uma lista de comandos.
A limpeza de estado no contexto adiado (por meio do parâmetro bool em ExecuteCommandList e FinishCommandList) deve ser testada com interfaces e classes.
Sintaxe de comando
| Opção de comando | Descrição |
|---|---|
Wgf11interfaces |
Executa os trabalhos de teste. Sem nenhuma opção, o teste enumera os dispositivos. |
-FeatureLevel:XX.X |
Define o recurso lewlve, em que XX.X é o Nível de Recurso em que o teste será executado em: 10.0, 10.1 ou 11.0. |
Observação
Para obter ajuda de linha de comando para esse binário de teste, digite /?.
Lista de arquivos
| Arquivo | Location |
|---|---|
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 |
Parâmetros
| Nome do parâmetro | Descrição do parâmetro |
|---|---|
| MODIFIEDCMDLINE | Argumentos de linha de comando adicionais para executável de teste |
| LLU_NetAccessOnly | Nome da LLU do usuário líquido |
| ConfigDisplayCommandLine | Linha de comando personalizada para ConfigDisplay. Padrão: logotipo |
| TDRArgs | /get ou /sets |