Compartir a través de


Interfaces WGF11 (WoW64)

Esta prueba automatizada comprueba diferentes partes del hardware y el controlador para la ejecución válida del sombreador cuando se usan interfaces.

La prueba se centra en cubrir la información oculta del búfer que se proporciona al controlador a través de DDI, que incluye tipos de interfaz y ubicaciones de recursos. Parte de la información que se usa en las interfaces se inserta en el propio sombreador, como las tablas de funciones y las tablas de tipo de clase. El hardware solo es necesario para llamar e indexar correctamente estas tablas, ya que el tiempo de ejecución realiza toda la administración necesaria para mantener la información organizada y asignada correctamente.

La prueba solo ejecuta escenarios válidos y comprueba que los resultados son correctos. No se espera que se produzcan errores en el hardware D3D11 certificable.

Los registros de prueba en WTT como las pruebas de conformidad anteriores tienen y contienen información útil sobre el error para ayudar a los IHD a depurar sus errores.

Este tema se aplica a los siguientes trabajos de prueba:

  • WGF11 Interfaces

  • Interfaces WGF11 (WoW64)

Detalles de las pruebas

   
Especificaciones
  • Device.Graphics.AdapterRender.D3D111Core.D3D111CorePrimary
  • Device.Graphics.AdapterRender.D3D11Core.D3D11CorePrimary
Plataformas
  • Windows 10, ediciones de cliente (x64)
  • Windows Server 2016 (x64)
  • Windows 10, ediciones de cliente (Arm64)
Versiones admitidas
  • Windows 10
  • Windows 10, versión 1511
  • Windows 10, versión 1607
  • Windows 10, versión 1703
  • Windows 10, versión 1709
  • Windows 10, versión 1803
  • Windows 10, versión 1809
  • Windows 10, versión 1903
  • Siguiente actualización a Windows 10
Tiempo de ejecución esperado (en minutos) 2
Categoría Compatibilidad
Tiempo de espera (en minutos) 120
Requiere reinicio false
Requiere una configuración especial false
Tipo automatic

 

Documentación adicional

Las pruebas de esta área de características pueden tener documentación adicional, incluidos los requisitos previos, la configuración y la información de solución de problemas, que se pueden encontrar en los temas siguientes:

Ejecución de la prueba

Antes de ejecutar la prueba, complete la configuración de prueba como se describe en los requisitos de prueba: Requisitos previos de adaptador gráfico o pruebas de conjuntos de chips.

Solución de problemas

Para solucionar problemas genéricos de errores de prueba de HLK, consulte Solución de problemas de errores de prueba de HLK de Windows.

Para obtener información sobre la solución de problemas, consulte Solución de problemas de Device.Graphics Testing.

La prueba devuelve SKIP cuando se ejecuta en el nivel < de característica 11. La prueba devuelve SKIP cuando se ejecuta en el nivel < de característica 11.

Más información

WGF11Interfaces: ejecución del sombreador de interfaz

WGF11Interfaces cubre todos los aspectos de la transferencia de datos al controlador, junto con la ejecución correcta de IL del sombreador.

Una descripción de cada grupo de pruebas y el parámetro de línea de comandos necesario se muestra más adelante en esta sección. No se proporcionan sombreadores completos en esta documentación. Sin embargo, se describe una descripción del objetivo previsto del sombreador y los tipos de entradas para proporcionar información sobre cómo probar en Windows Hardware Quality Labs (WHQL). Además, cada prueba se ejecuta en todas las fases del sombreador para comprobar el comportamiento coherente de una característica que cumple los objetivos de la arquitectura unificada.

Las pruebas usan ints y uints como entradas y durante el cálculo siempre que sea posible, ya que la precisión y la comprobación de las matemáticas de punto flotante se tratan en una prueba de conformidad diferente.

Las pruebas que usan muestradores realizan el muestreo de puntos y usan el color del borde para comprobar si se usa el sampler correcto. El filtrado y otros aspectos de la cobertura del muestreador se tratan en una prueba de conformidad diferente. Las pruebas de interfaz solo se refieren a la indexación correcta de los muestreadores que usan las instancias de clase durante la ejecución.

Las pruebas que usan recursos se centran en formatos con canales de 8 bits y sin niveles de MIP. Otras pruebas comprueban la corrección de los recursos. Las pruebas de interfaz solo se refieren a la indexación correcta de texturas que usan las instancias de clase durante la ejecución. Solo se usan cargas de recursos. Dado que no se pueden indexar, los UAV no son importantes para las interfaces.

Las pruebas se ejecutan en cada fase del sombreador, ya que se supone que la característica se ajusta a la arquitectura unificada de Shader Model 5.0.

Cada prueba tiene una tarea Pri-1 y una tarea Pri-2, que, cuando se combina, completa la cobertura de la característica. Las tareas pri-1 requieren que una prueba solo se ejecute en una fase específica del sombreador. Las tareas pri-2 prueban las fases restantes del sombreador.

El tiempo de ejecución crea todas las instancias mediante las siguientes llamadas API:

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

Las instancias se establecen cuando el sombreador se establece mediante llamadas XXSetShader().

WGF11Interfaces.exe Interfaces\FunctionTables y fcall\[ PS]

Pri-1 16 horas

La tabla de funciones de gran tamaño comprueba si el hardware puede administrar la salida de los programas de sombreador por el compilador. Esta comprobación es específica de los sombreadores que tienen muchas llamadas de interfaz en cascada que dieron lugar a grandes generaciones de código que tienen muchos cuerpos de función. Esta prueba no prueba el rendimiento de estos sombreadores, pero comprueba si la ejecución es correcta cuando se compara con el rasterizador de referencia.

Se escriben varios sombreadores que duplicarán secuencialmente el número de cuerpos de función creados por el compilador. A continuación, estos sombreadores se ejecutan con varias variaciones en las instancias que rellenan las ranuras, con el fin de comprobar la ejecución correcta a través de un subconjunto de rutas de acceso de código. En cualquier momento, la prueba puede intentar validar todas las rutas de acceso de código y se espera que el hardware no produzca un error en ninguno de ellos. Si el hardware devuelve memoria insuficiente durante el tiempo de creación del sombreador, la prueba devuelve RESULT_SKIP, cuando sea razonable. Los requisitos de recursos de estos sombreadores no deben insertar los límites del hardware. Por lo tanto, el sombreador debe enlazar y ejecutarse correctamente. Si se produce un error de hardware en tablas de funciones pequeñas, se produce una advertencia. El hardware debe admitir un mínimo de 4 KB cuerpos de función.

Las funciones en cascada están diseñadas mediante varios tipos de interfaz, cada una de las cuales se basa en un objeto de otra instancia para su parámetro. Estas llamadas están diseñadas para ser varias capas de profundidad y pueden dar lugar fácilmente a más de 1k cuerpos de función que se van a crear.

La prueba también proporciona cobertura de la instrucción fcall llamando ampliamente a otras funciones para obtener la cobertura adecuada de los cuerpos de función de 4 KB en el sombreador. Esto se puede hacer variando las instancias enlazadas mediante XXSetShader por el tiempo de ejecución. El marco proporciona una manera sencilla de obtener una cobertura adecuada a través de permutaciones de tipos enlazados.

Para asegurarse de que la prueba no necesita mantenimiento debido a cambios en el compilador, cada cuerpo de función debe ser único de todos los demás cuerpos de función. Esto se debe a que el compilador puede en algún momento contraer cuerpos de función con código idéntico para reducir el tamaño del código y proporcionar una tabla de funciones más optimizada. Al asegurarse de que todos los cuerpos de función son diferentes, se impide que la prueba se cambie o se quede obsoleta cuando se agrega esta optimización al compilador. Es importante revisar el IL para asegurarse de que se genera el código esperado.

Ejemplo:

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;

Si se llama a la interfaz de Type3 y cada implementación llama al método de interfaz de un parámetro de entrada, todas las rutas de acceso de código posibles crean 720 cuerpos de función, cada una optimizada para su ruta de acceso de código determinada. Dado que no hay ninguna limitación en el tamaño del código que no sea la memoria, incluso los sombreadores muy grandes deben ejecutarse sin errores.

El código del sombreador está optimizado en todos los sitios de llamada, por lo que es posible que cada llamada sea única en función de la información del autor de la llamada y del destinatario. La multiplicación simple por una constante no es suficiente; en su lugar, cada cuerpo de función debe ser único realizando diferentes operaciones y usando variables miembro. La salida resultante debe comprobarse, por lo que la multiplicación por números primos o algo similar funcionaría. Para comprobar que el sombreador se ejecutó correctamente, se deben realizar las mismas matemáticas en la CPU en función de las instancias de clase enlazadas.

Esta prueba también cubre la profundidad del árbol de llamadas (32). Es importante probar que más de 32 fcalls dan como resultado ninguna operación (solo puede probar 33 en un momento dado). El compilador no permite que el código se escriba simplemente para probar este caso, por lo que necesita un enfoque más sofisticado que pueda cambiar dinámicamente la profundidad de la llamada y comprobar que cada llamada se realizó (o no se realizó).

Una secuencia fibinachi o similar podría ser útil para esto. No se permiten llamadas recursivas, por lo que debe haber 33 interfaces a las que se pueda llamar una después de otra. Localmente, las instancias deben decidir si deben continuar o no la profundidad de la llamada. El tiempo de ejecución enlaza los datos para controlar estas pruebas.

Esta prueba se escribe para el sombreador de píxeles como Pri-1.

La finalización de esta prueba demuestra lo siguiente:

  • La llamada funciona.

  • Las tablas de funciones son correctas y se usan correctamente.

  • Se admite el límite de tabla de funciones de 4 KB.

  • La profundidad de la llamada es 32.

Los resultados de la prueba se capturan en el siguiente destino de representación:

WGF11Interfaces.exe Interfaces\FunctionTables y fcall \[VS,GS, HS,DS,CS]

Pri-2

La prueba cubre todas las fases del sombreador.

La verificación de esta característica admite una amplia gama de patrones de diseño válidos y técnicas de programación de OO que shader Model 5.0 se diseñó para admitir.

Los resultados de estas pruebas se capturan en un búfer de salida de flujo para VS,HS,DS y GS. Los resultados de PS y CS se capturan mediante destinos de representación y búferes que se pueden escribir.

WGF11Interfaces.exe Interfaces\GroupExecutionPathDifferences\[ CS]

Pri-1 40 horas

Aprovechar el paralelismo es muy importante al diseñar hardware. Sin embargo, la capitalización de estas oportunidades no debe interrumpir la ejecución correcta de un sombreador cuando las rutas de acceso de código difieren. Esta prueba se ejecuta en cada fase del sombreador y proporciona cobertura que ejecuta rutas de acceso de código diferentes a pesar del hecho de que los píxeles, los vértices y otras primitivas de fase de canalización podrían ejecutarse como grupos de pasos de bloqueo. Esta prueba no prueba el rendimiento en estos casos. En su lugar, solo comprueba un resultado válido después de la ejecución.

Proporcionar datos a cada fase de canalización es importante y debe realizarse en fragmentos de tamaño para comprobar la cobertura de una ejecución variada entre grupos. El método siguiente proporciona los datos a las pruebas para cada fase del sombreador:

  • Sombreador de proceso:

    Los datos que se usan para seleccionar instancias basadas en ranuras de matriz se proporcionan mediante el uso de recursos para el sombreador de proceso. Los SV_GroupID y SV_GroupThreadID se usan para seleccionar los datos correctos del recurso para elegir qué instancias de clase usar durante la invocación de un sombreador. Los resultados de la ejecución se escriben en un búfer grabable para comprobar que es correcto. Se usa un recuento de dimensiones grandes de subprocesos en cada dimensión. Esto incluye un gran número primo de subprocesos y varios grupos que se enviarán para obtener una cobertura adecuada para esta prueba.

Cada subproceso de hardware debe ejecutar una llamada de método en un tipo diferente proporcionado por el tiempo de ejecución. El tiempo de ejecución puede calcular el resultado de la comprobación en función del tipo utilizado, los datos proporcionados y el algoritmo del tipo. El código de cada método debe variar en longitud y complejidad para demostrar que el hardware puede controlar los sombreadores como este. Se deben usar implementaciones de clase diferentes de 12 a 18 y cada valor de SV_[Index] se puede seudocalizar para elegir el índice de matriz y la instancia de clase que se va a ejecutar.

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

Pri-2 40 horas

La prueba se extiende a las demás fases del sombreador.

  • Sombreador de vértices:

    Se agrega un conjunto de índices de matriz de ranuras de interfaz a los datos de vértices y se usan durante la ejecución del sombreador de vértices para determinar qué instancia de interfaz se va a invocar. Los datos también tratan qué instancias se usan como parámetros cuando se invocan métodos. Se dibuja un bloque de al menos 512 puntos para comprobar el comportamiento del hardware. Un búfer de salida detecta los resultados.

  • Sombreador de casco:

    Los índices de matriz de ranuras de interfaz se agregan a la estructura de entrada del punto de control, lo que permite a cada punto determinar qué instancias de clase se invocan a lo largo del sombreador. Estos datos también tratan qué instancias se usan como parámetros cuando se invocan métodos. Se dibuja una revisión de 32 puntos completa varias veces para comprobar el comportamiento del hardware. Un búfer de salida detectará los resultados.

    Esta prueba también reenvía los datos a la función Patch Constant, que también comprueba el comportamiento correcto.

    Además, el SV_OutputControlPointID y el código de bifurcación específico están activados en el compilador. El código de bifurcación también provoca rutas de ejecución de código divergentes mediante interfaces de esta fase. Se puede acceder a la bifurcación mediante un bucle y la llamada a un método de interfaz desde dentro del bucle.

  • Sombreador de dominio:

    Los datos se pasan a través del sombreador hull en cada punto de control y, a continuación, se recuperan mediante el SV_PrimitiveID disponible en el sombreador de dominio. Las posiciones de salida del teselador se combinan con el SV_PrimitiveID para crear los índices en las ranuras de instancia de clase disponibles durante la ejecución. La revisión completa de 32 puntos se dibuja varias veces para comprobar el comportamiento del hardware. Un búfer de salida detecta los resultados. El foco no es cubrir todos los tipos de dominio.

  • Sombreador de geometría:

    Los índices de ranura de interfaz se adjuntan a primitivos de punto que se proporcionan al sombreador de geometría. Los índices se usan para elegir instancias de clase en las que invocar métodos y usarlos como parámetros durante la ejecución del sombreador. Se dibuja un bloque de al menos 512 puntos para comprobar el comportamiento del hardware. Los resultados se capturan en un búfer de salida de flujo para la comprobación.

  • Sombreador de píxeles:

    En el caso de los sombreadores de píxeles, se usa una textura para proporcionar los índices de instancia de clase para cada píxel. La textura coincide exactamente con el tamaño del destino de representación dibujando un cuadrángulo grande. Se dibuja un área de al menos 512 x 512 píxeles, con los recursos auxiliares, para comprobar el comportamiento del hardware. Los resultados se capturan en un destino de representación para la validación. SV_Position y SV_SampleIndex también se pueden usar para determinar cómo se indexa un píxel en las ranuras de interfaz. Dibujar un triángulo es más interesante que dibujar un cuadrante.

WGF11Interfaces.exe Interfaces\IndexingResources y this[]\[VS]

Pri-1 26 horas

El IL hizo indizables todos los recursos que usa una interfaz para admitir el enlace dinámico en tiempo de ejecución. Los datos se proporcionan a través de la DDI e incluyen la siguiente información:

  • Identificador de tipo de clase

  • Cbuffer

  • Desplazamiento de Cbuffer

  • Ranura de textura

  • Ranura sampler

Esta prueba garantiza que la ejecución del controlador y el sombreador usen correctamente esta información. El acceso a esta información solo se puede realizar a través de la palabra clave "this", que usa un búfer reservado oculto. Las instancias de clase que tienen 256 bytes se pueden enlazar a un sombreador, por lo que esta prueba proporciona cobertura para usar todas las 256 ranuras de instancia. Esto implica que esto debe usarse en combinación con cada una de las otras áreas de esta prueba. Sin embargo, no es necesario comprobar las otras áreas a través de la permutación entre sí.

La ubicación de los ciclos de prueba para todas las ranuras y desplazamientos diferentes de los recursos y usa esos recursos al generar resultados.

Para obtener una cobertura completa, cada instancia de clase debe ejecutar un método que use los datos de recursos para generar un resultado. Al hacerlo, garantiza que el identificador de tipo de instancia se use correctamente con respecto a las tablas de funciones.

Cada cbuffer debe probarse para los datos de clase. Los datos deben colocarse en todo el búfer mediante el parámetro offset. Esto se puede hacer enlazando 256 instancias cada una con una ubicación diferente establecida por el tiempo de ejecución. El sombreador puede ejecutar 256 vértices y usar el SV_PrimitiveID para determinar la ranura de instancia que se va a usar.

Cada ranura tbuffer de la versión 128 disponible debe usarse de la misma manera que se mencionó anteriormente. Solo se necesita usar un búfer simple o textura2, y solo se prueba la instrucción de carga. La prueba solo está interesada en corregir la indexación de los registros de textura.

Cada ranura de muestreo de la 16 disponible para una fase de sombreador debe usarse de la misma manera que se mencionó anteriormente. Los muestreadores se muestrearán fuera del límite de textura para que se devuelva un color de borde. Cada uno de los 16 muestreadores debe tener un color de borde único para que la prueba compruebe que se usó el muestreador correcto.

Estas se pueden probar por separado: la cobertura combinada no es necesaria.

F11Intefaces.exe Interfaces\IndexingResources y este[]\[GS,PS,HS,DS,CS]

Pri-2 26 horas

La prueba anterior se extiende para cubrir todas las fases del sombreador.

(Pri 1 18 horas) El contexto diferido también se debe usar en estas pruebas.

Los casos de prueba descritos también se ejecutarán en un contexto diferido mediante listas de comandos para establecer clases e instancias.

Las listas de comandos no heredan el estado del contexto inmediato. Por lo tanto, las instancias establecidas en el contexto inmediato no deben ser accesibles al ejecutar una lista de comandos.

La desactivación de estado en el contexto diferido (a través del parámetro bool en ExecuteCommandList y FinishCommandList) debe probarse con interfaces y clases.

Sintaxis de comandos

Opción de comando Descripción

Wgf11interfaces

Ejecuta los trabajos de prueba. Sin ninguna opción, la prueba enumera los dispositivos.

-FeatureLevel:XX.X

Establece la característica lewlve, donde XX.X es el nivel de característica que se ejecutará la prueba en: 10.0, 10.1 o 11.0.

Nota

   Para obtener ayuda de la línea de comandos para este binario de prueba, escriba /?.

 

Lista de archivos

Archivo Ubicación

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

Nombre de parámetro Descripción de los parámetros
MODIFIEDCMDLINE Argumentos de línea de comandos adicionales para el ejecutable de prueba
LLU_NetAccessOnly Nombre de LLU de net user
ConfigDisplayCommandLine Línea de comandos personalizada para ConfigDisplay. Valor predeterminado: logotipo
TDRArgs /get o /sets