WGF11 接口
此自动测试将验证硬件和驱动程序的各个部分，以便在使用接口时执行有效的着色器。
此测试重点涵盖通过 DDI 提供给驱动程序的隐藏缓冲区信息，其中包括接口类型和资源位置。 接口中使用的某些信息（例如函数表和类类型表）嵌入在着色器本身中。 硬件只需正确调用这些表并为其编制索引，因为运行时会执行所需的所有管理来确保信息组织有序且正确映射。
测试仅执行有效方案，并验证结果是否成功。 通过 D3D11 认证的硬件预计不会出现任何故障。
与以前的符合性测试一样，此测试也记录到 WTT，并包含有关故障的有用信息，可帮助 IHV 调试其故障。
本主题适用于以下测试作业：
WGF11 接口
WGF11 接口 (WoW64)
测试详细信息
| 规范 |
|
| 平台 |
|
| 支持的版本 |
|
| 预计运行时间（以分钟为单位） | 2 |
| 类别 | 兼容性 |
| 超时（以分钟为单位） | 120 |
| 需要重启 | false |
| 需要特殊配置 | false |
| 类型 | automatic |
其他文档
此功能区域中的测试可能会有其他文档，包括先决条件、设置和故障排除信息，这些内容可在以下主题中找到：
运行测试
在运行测试之前，请按照如下测试要求中所述完成测试设置：图形适配器或芯片组测试先决条件。
故障排除
有关 HLK 测试失败的常规故障排除，请参阅排查 Windows HLK 测试失败问题。
有关故障排除信息，请参阅排查 Device.Graphics 测试问题。
针对低于 11 的功能级别运行此测试时，将返回 SKIP。 针对低于 11 的功能级别运行此测试时，将返回 SKIP。
更多信息
WGF11Interfaces - 接口着色器执行
WGF11Interfaces 涵盖了到驱动程序的数据传输的所有方面，以及正确执行着色器 IL。
本节后面列出了每个测试组的说明和必要的命令行参数。 本文档未提供全部着色器。 但是，本文描述了着色器的预定目标和输入类型，以提供有关如何在 Windows 硬件质量实验室 (WHQL) 中进行测试的信息。 此外，每个测试都在所有着色器阶段运行，以验证功能的一致行为是否符合统一体系结构目标。
这些测试在计算过程中尽可能使用 int 和 uint 作为输入，因为浮点数学的精度和验证在不同的符合性测试中进行介绍。
这些测试使用采样器来执行点采样，并使用边框颜色来验证使用的采样器是否正确。 采样器覆盖范围的筛选和其他方面在不同的符合性测试中进行介绍。 接口测试仅涉及在执行期间由类实例使用的采样器的正确索引。
使用资源的测试侧重于具有 8 位通道的格式，而不是任何 MIP 级别。 其他测试将验证资源的正确性。 接口测试仅涉及在执行期间由类实例使用的纹理的正确索引。 仅使用资源负载。 由于它们无法编制索引，因此 UAV 对接口并不重要。
这些测试在每个着色器阶段运行，因为该功能应符合着色器模型 5.0 的统一体系结构。
每个测试都有一个 Pri-1 任务和一个 Pri-2 任务，只有在完成这两个任务后才完全覆盖该功能。 Pri-1 任务要求测试仅在特定着色器阶段运行。 Pri-2 任务测试剩余的着色器阶段。
所有实例都由运行时使用以下 API 调用创建：
HRESULT CreateClassInstance(LPCWSTR pszClassTypeName,UINT ConstantBufferOffset,UINT ConstantVectorOffset,UINT TextureOffset,UINT SamplerOffset,ID3D11ClassInstance **ppInstance);
当使用 XXSetShader() 调用设置着色器时，将设置实例。
WGF11Interfaces.exe Interfaces\FunctionTables and fcall\[ PS]
Pri-1（16 小时）
大型函数表测试将验证硬件是否能够管理编译器输出的着色器程序。 此验证特定于具有许多级联接口调用的着色器，这些调用导致生成大量包含许多函数体的代码。 此测试不会测试此类着色器的性能，但会测试与引用光栅器相比较执行是否正确。
将编写多个着色器，这会按顺序将编译器创建的函数体的个数加倍。 然后，将使用多个变体在填充槽的实例上运行这些着色器，以便通过一部分代码路径验证执行是否正确。 测试可以随时尝试验证所有代码路径，并且预计硬件在任意路径都不会失败。 如果硬件在创建着色器期间返回内存不足错误，则测试在合理时会返回 RESULT_SKIP。 这些着色器的资源要求不应突破硬件的限制。 因此，着色器应正确绑定并执行。 如果硬件甚至在小型函数表上发生故障，则会出现警告。 硬件应最少支持 4 KB 的函数体。
级联函数使用多种接口类型进行设计，每个函数都使用其他实例的对象作为其参数。 这些调用设计为多层深，并且可以轻松地生成超过一千个函数主体。
该测试还通过广泛地调用其他函数，在着色器中获得 4 KB 函数体的相应覆盖范围，从而提供 fcall 指令的覆盖范围。 这可以通过由运行时使用 XXSetShader 改变已绑定实例来实现。 框架提供了一种简单方法，用于通过排列已绑定类型来获得充分的覆盖范围。
为确保不必因为编译器发生更改而对测试进行维护，每个函数体对于所有其他函数体都必须是唯一的。 这是因为编译器有时可能会折叠具有相同代码的函数体，以减小代码大小并提供更优化的函数表。 通过确保所有函数体都不同，可以防止在将此优化添加到编译器时测试发生更改或变得过时。 请务必查看 IL，以确保生成预期代码。
示例：
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;
如果调用 Type3 的接口，并且每个实现都调用输入参数的 interface 方法，将由所有可能的代码路径创建 720 个函数体，每个函数体都针对其特定的代码路径进行了优化。 由于除内存外，代码大小没有限制，因此即使非常大的着色器也应正确执行而不会出错。
着色器代码跨 fcall 站点进行了优化，因此，根据来自调用方和被调用方的信息，每个调用都可能是唯一的。 用常量进行简单相乘并不足以满足要求；相反，必须通过执行不同的运算并使用成员变量来确保每个函数体都是唯一的。 必须验证生成的输出，以便可以使用质数或类似数字进行相乘。 要验证着色器是否正确执行，必须基于已绑定类实例在 CPU 上执行相同的数学运算。
此测试还涵盖调用树深度 (32)。 请务必测试超过 32 个 fcall 是否会导致无操作（在给定的时间只能测试 33 个 fcall）。 编译器不允许编写代码来仅测试这种情况，因此你需要一种可以动态更改调用深度并验证是否已发出每个调用的更复杂方法。
fibinachi 序列或类似序列可能对此很有用。 不允许递归调用，因此必须有 33 个接口，以便逐个调用这些接口。 在本地，实例必须决定是否沿 fcall 深度继续前进。 运行时会绑定数据以驱动这些测试。
此测试针对像素着色器编写为 Pri-1。
完成此测试可证明以下事项：
fcall 有效。
函数表正确且使用正确。
支持 4 KB 函数表限制。
调用深度为 32。
测试结果在以下呈现器目标中捕获：
WGF11Interfaces.exe Interfaces\FunctionTables and fcall\[VS,GS, HS,DS,CS]
Pri-2
此测试涵盖所有着色器阶段。
此功能的验证支持着色器模型 5.0 旨在支持的多种有效设计模式和面向对象的编程技术。
这些测试的结果在 VS、HS、DS 和 GS 的流输出缓冲区中捕获。 PS 和 CS 的结果由呈现器目标和可写缓冲区捕获。
WGF11Interfaces.exe Interfaces\GroupExecutionPathDifferences\[CS]
Pri-1（40 小时）
在设计硬件时，利用并行非常重要。 但是，当代码路径分叉时，利用此类机会不应中断着色器的正确执行。 此测试在每个着色器阶段运行，尽管像素、顶点和其他管道阶段基元可能作为一致步调组执行，也能提供执行不同代码路径的覆盖范围。 此测试不会测试在这种情况下的性能。 相反，它只会验证执行后的有效结果。
向每个管道阶段提供数据非常重要，并且必须以可调整大小的区块提供数据，以验证各个执行跨组的覆盖范围。 以下方法可向每个着色器阶段的测试提供数据：
计算着色器：
用于选择基于数组槽的实例的数据是使用资源提供给计算着色器的。 SV_GroupID 和 SV_GroupThreadID 用于从资源中选择正确的数据，以选择要在调用着色器期间使用的类实例。 执行结果将写入到可写缓冲区，以验证执行是否正确。 每个维度使用大量线程。 这包括大量线程和多个组，将调度这些线程和组，以使此测试获得充分的覆盖范围。
每个硬件线程应执行运行时提供的不同类型的方法调用。 运行时能够根据所使用的类型、提供的数据和算法的类型计算验证结果。 每个方法的代码长度和复杂性应有所不同，以证明硬件可以处理此类着色器。 应使用 12 到 18 个不同的类实现，并且可以对每个 SV_[Index] 值进行伪取模，以选取要执行的数组索引和类实例。
WGF11Interfaces.exe Interfaces\GroupExecutionPathDifferences\[VS,GS,PS,HS,DS]
Pri-2（40 小时）
此测试将扩展到其他着色器阶段。
顶点着色器：
一组接口槽数组索引将添加到顶点数据中，并在执行顶点着色器期间用于确定要调用的接口实例。 这些数据还涵盖调用方法时用作参数的实例。 绘制一个至少包含 512 个点的块来验证硬件行为。 结果由流输出缓冲区捕获。
外壳着色器：
接口槽数组索引将添加到控制点输入结构中，使每个点都能确定在着色器过程中调用哪些类实例。 这些数据还涵盖调用方法时用作参数的实例。 多次绘制一个包含全部 32 个点的补丁来验证硬件行为。 结果将由流输出缓冲区捕获。
此测试还会将数据转发到 Patch Constant 函数，该函数还会验证行为是否正确。
此外，SV_OutputControlPointID 和特定分叉代码在编译器中打开。 分叉代码在此阶段还会使用接口导致代码执行路径分叉。 可以使用循环并从循环中调用 interface 方法来访问分叉。
域着色器：
数据通过每个控制点上的外壳着色器传递，然后使用域着色器中提供的 SV_PrimitiveID 进行恢复。 将细化器输出位置与 SV_PrimitiveID 结合使用，以在执行期间创建到可用类实例槽的索引。 多次绘制包含全部 32 个点的补丁来验证硬件行为。 结果由流输出缓冲区捕获。 重点不是涵盖所有域类型。
几何着色器：
接口槽索引附加到提供给几何着色器的点基元。 索引用于选择要调用方法的类实例，并在执行着色器期间用作参数。 绘制一个至少包含 512 个点的块来验证硬件行为。 结果在流输出缓冲区中捕获以进行验证。
像素着色器：
对于像素着色器，纹理用于为每个像素提供类实例索引。 纹理通过绘制大四边形与呈现器目标的大小完全匹配。 绘制一个至少包含 512x512 像素的区域，并使用支持资源来验证硬件行为。 结果在呈现器目标中捕获以进行验证。 SV_Position 和 SV_SampleIndex 还可用于确定像素如何索引到接口槽中。 绘制三角形比绘制四边形更有趣。
WGF11Interfaces.exe Interfaces\IndexingResources and this[]\[VS]
Pri-1（26 小时）
接口使用的所有资源都可由 IL 编制索引，以支持动态运行时绑定。 数据通过 DDI 提供，包括以下信息：
类类型 ID
cbuffer
cbuffer 偏移
纹理槽
采样器槽
此测试可确保驱动程序和着色器执行正确使用所有这些信息。 只能通过“this”关键字访问这些信息，该关键字使用隐藏的保留缓冲区。 256 个字节的类实例可以绑定到着色器，因此此测试提供了使用全部 256 个实例槽的覆盖范围。 这样做意味着需要将此与此测试的其他每个区域结合使用。 但是，不需要通过彼此排列来验证其他区域。
此测试将循环资源中所有不同槽和偏移的位置，并在生成结果时使用这些资源。
为了获得完整覆盖范围，每个类实例都应执行一个方法，该方法利用资源数据生成结果。 这样做可确保在函数表中正确使用实例类型 ID。
必须测试每个 cbuffer 的类数据。 需要使用 offset 参数在整个缓冲区中放置数据。 为此，可以绑定 256 个实例，每个实例都具有由运行时设置的不同位置。 着色器可以执行 256 个顶点，并使用 SV_PrimitiveID 来确定要使用的实例槽。
必须按前面提到的相同方式使用 128 个可用 tbuffer 槽中的每一个。 只需使用简单缓冲区或 texture2d，并且仅测试加载指令。 此测试仅涉及正确为纹理寄存器编制索引。
必须按前面提到的相同方式使用 16 个可用于着色器阶段的采样器槽中的每一个。 采样器将在纹理边界之外进行采样，以便返回边框颜色。 16 个采样器中的每一个都应具有唯一的边框颜色，以便测试验证是否使用了正确的采样器。
这些可以单独进行测试，而不需要同时涵盖它们。
F11Intefaces.exe Interfaces\IndexingResources and this[]\[GS,PS,HS,DS,CS]
Pri-2（26 小时）
将扩展上一个测试，以涵盖所有着色器阶段。
（Pri 1 [18 小时]）还应在这些测试中使用延迟上下文。
本文所述的测试用例还将使用命令列表在延迟上下文中运行，以设置类和实例。
命令列表不从即时上下文继承状态。 因此，执行命令列表时，应无法访问在即时上下文中设置的实例。
应使用接口和类来测试延迟上下文中的状态清除（通过 ExecuteCommandList 和 FinishCommandList 中的布尔参数）。
命令语法
| 命令选项 | 说明 |
|---|---|
Wgf11interfaces |
运行测试作业。 不使用任何选项时，测试将枚举设备。 |
-FeatureLevel:XX.X |
设置功能级别，其中 XX.X 是测试将运行的功能级别：10.0、10.1 或 11.0。 |
注意
有关此测试二进制文件的命令行帮助，请键入 /?。
文件列表
| 文件 | 位置 |
|---|---|
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 |
参数
| 参数名称 | 参数说明 |
|---|---|
| MODIFIEDCMDLINE | 测试可执行文件的其他命令行参数 |
| LLU_NetAccessOnly | 网络用户的 LLU 名称 |
| ConfigDisplayCommandLine | ConfigDisplay 的自定义命令行。 默认值：徽标 |
| TDRArgs | /get 或 /set |