WGF11 インターフェイス
この自動テストでは、インターフェイスが使用されている場合、有効なシェーダーの実行に対してハードウェアとドライバーのさまざまな部分が検証されます。
このテストでは、DDI を通じてドライバーに提供される非表示のバッファー情報 (インターフェイスの種類とリソースの場所を含む) を対象にしています。 関数テーブルやクラス型テーブルなど、インターフェイスで使用される情報の一部は、シェーダー自体に埋め込まれています。 情報を正しく整理およびマップしておくために必要なすべての管理はランタイムによって実行されるため、ハードウェアは、これらのテーブルを正しく呼び出してインデックスを作成するためにのみ必要です。
テストは、有効なシナリオのみを実行して、結果が成功であることを確認します。 認定可能な D3D11 ハードウェアでは、障害は発生しないと想定されています。
このテストでは、以前の準拠テストと同様に、WTT にログが記録されます。これには、IHV が障害をデバッグするために役立つ、障害に関する有用な情報が含まれています。
このトピックは次のテスト ジョブに適用されます。
WGF11 インターフェイス
WGF11 インターフェイス (WoW64)
テストの詳細
| 仕様 |
|
| プラットフォーム |
|
| サポートされているリリース |
|
| 予想される実行時間 (分) | 2 |
| カテゴリ | 互換性 |
| タイムアウト (分) | 120 |
| 再起動が必要です | false |
| 特別な構成が必要です | false |
| Type | automatic |
その他のドキュメント
この機能領域のテストには、前提条件、セットアップ、トラブルシューティング情報など、次のトピックに記載されている追加のドキュメントが含まれている場合があります。
テストの実行
テストを実行する前に、「グラフィック アダプターまたはチップセットのテストの前提条件に関するページ」で説明されているテスト要件に従って、テストのセットアップを完了します。
トラブルシューティング
HLK テスト エラーの一般的なトラブルシューティングについては、「Windows HLK テストのエラーのトラブルシューティング」を参照してください。
トラブルシューティング情報については、「Device.Graphics テストのトラブルシューティング」を参照してください。
このテストを機能レベル < 11 で実行すると SKIP が返されます。 このテストを機能レベル < 11 で実行すると SKIP が返されます。
詳細
WGF11Interfaces - インターフェイス シェーダーの実行
WGF11Interfaces は、シェーダー IL の正しい実行と、ドライバーへのデータ転送のすべての側面を対象としています。
各テスト グループの説明と必要なコマンド ライン パラメーターの一覧を、このセクションの後の方で示します。 シェーダー全体については、このドキュメントでは説明していません。 ただし、Windows Hardware Quality Labs (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 時間
大きな関数テーブルのテストは、コンパイラによって出力されたシェーダー プログラムをハードウェアが管理できるかどうかを確認します。 この検証は、多くの関数本体が含まれる大量のコードが生成されるような、多くのカスケード インターフェイス呼び出しがあるシェーダーに固有のものです。 このテストでは、このようなシェーダーのパフォーマンスはテストされませんが、リファレンス ラスタライザーと比較したときに実行が正しいかどうかをテストします。
複数のシェーダーが書き込まれ、コンパイラによって作成される関数本体の数が順に 2 倍になっていきます。 その後、これらのシェーダーは、コード パスのサブセットを通じて正しく実行されることを確認するために、スロットを埋めるインスタンスでいくつかのバリエーションを使用して実行されます。 テストでは、すべてのコード パスの検証をいつでも試みることができ、いずれのパスでもハードウェアが失敗しないことが期待されます。 シェーダーの作成時にハードウェアがメモリ不足という結果を返した場合、テストは RESULT_SKIP を返します (妥当な場合)。 これらのシェーダーのリソース要件が、ハードウェアの制限を超えないようにする必要があります。 そうすることで、シェーダーは正常にバインドされ、実行されるはずです。 ハードウェアが小さな関数テーブルでも失敗する場合、警告が発生します。 ハードウェアは、少なくとも 4 KB の関数本体をサポートしている必要があります。
カスケード関数は、複数のインターフェイスの種類を使用して設計されています。それぞれの種類が、パラメーターについては、別のインスタンスのオブジェクトに依存しています。 これらの呼び出しは、いくつかのレイヤーの深さになるように設計されており、1k を超える関数本体が容易に作成される場合があります。
また、このテストでは、シェーダーでの 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 のインターフェイスが呼び出され、各実装が入力パラメーターのインターフェイス メソッドを呼び出す場合、すべての可能なコード パスによって 720 個の関数本体が作成され、それぞれが特定のコード パスに対して最適化されます。 メモリ以外にコード サイズの制限がないため、非常に大きなシェーダーでもエラーなしで実行されます。
シェーダー コードは複数の fcall サイトにわたって最適化されているため、呼び出し元と呼び出し先からの情報に基づいて、各呼び出しを一意にすることができます。 定数での単純な乗算だけでは不十分です。代わりに、さまざまな操作を実行し、メンバー変数を使用することによって、各関数本体を一意にする必要があります。 結果として得られる出力を検証する必要があるため、素数による乗算または類似した処理が適しています。 シェーダーが正常に実行されたことを確認するには、バインドされたクラスのインスタンスに基づいて、CPU で同じ数値演算を実行する必要があります。
このテストでは、呼び出しツリーの深さ (32) もカバーされます。 32 個を超える fcall の結果が no-ops になることをテストすることが重要です (一度に実行できるテストは、33 個のみです)。 コンパイラは、単にこのケースをテストするために記述されたコードは許可しません。そのため、呼び出しの深さを動的に変更し、各呼び出しが実行された (または実行されなかった) ことを確認できる、より洗練されたアプローチが必要です。
この場合、フィボナッチ数列のようなものが役に立つ可能性があります。 再帰呼び出しは許可されていないため、1 つずつ呼び出すことができる 33 個のインターフェイスが必要です。 ローカルで、インスタンスは、fcall の深さを継続するかどうかを決定する必要があります。 ランタイムは、これらのテストを促進するためにデータをバインドします。
このテストは、ピクセル シェーダー用に Pri-1 として記述されています。
このテストが完了すると、次のことが証明されます。
fcall が機能している。
関数テーブルが正確で、正しく使用されている。
4 KB の関数テーブルの制限がサポートされている。
呼び出しの深さは 32 である。
テストの結果は、次のレンダー ターゲットでキャプチャされます。
WGF11Interfaces.exe Interfaces\FunctionTables and fcall \[VS,GS, HS,DS,CS]
Pri-2
このテストでは、すべてのシェーダー ステージが対象となります。
この機能の検証では、シェーダー モデル 5.0 がサポートするように設計された、さまざまな有効なデザイン パターンと OO プログラミング手法がサポートされています。
これらのテストの結果は、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 ポイントのパッチが複数回描画されます。 結果は、ストリーム出力バッファーに取得されます。
また、このテストでは、パッチ定数関数にもデータが転送されます。この関数も、動作が正しいことを検証します。
さらに、コンパイラで SV_OutputControlPointID と特定の分岐コードが有効になります。 分岐コードは、このステージのインターフェイスも使用して、コード実行パスを分岐させます。 分岐にアクセスするには、ループを使用し、ループ内からインターフェイス メソッドを呼び出します。
ドメイン シェーダー:
データは、各コントロール ポイントのハル シェーダーを介して渡され、ドメイン シェーダーで使用可能な SV_PrimitiveID を使用して回復されます。 テッセレータの出力位置は、SV_PrimitiveID と組み合わされ、実行中に使用可能なクラス インスタンス スロットのインデックスが作成されます。 ハードウェアの動作を検証するために、完全な 32 ポイントのパッチが複数回描画されます。 結果は、ストリーム出力バッファーに取得されます。 すべてのドメインの種類をカバーすることを主眼にしているわけではありません。
ジオメトリ シェーダー:
インターフェイス スロット インデックスは、ジオメトリ シェーダーに提供されるポイント プリミティブにアタッチされます。 インデックスは、シェーダーの実行中に、呼び出すメソッドのクラス インスタンスを選択したり、パラメーターとして使用するために利用されます。 ハードウェアの動作を検証するために、少なくとも 512 ポイントのブロックが描画されます。 結果は、検証のためにストリーム出力バッファーにキャプチャされます。
ピクセル シェーダー:
ピクセル シェーダーの場合、テクスチャは、各ピクセルのクラス インスタンス インデックスを提供するために使用されます。 テクスチャは、大きな四角形を描画することで、レンダー ターゲットのサイズと正確に一致します。 ハードウェアの動作を確認するために、サポート リソースを使用して、少なくとも 512 x 512 ピクセルの領域が描画されます。 結果は、検証のためにレンダー ターゲットにキャプチャされます。 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 の bool パラメーターを使用) は、インターフェイスとクラスを使用してテストする必要があります。
コマンド構文
| コマンド オプション | 説明 |
|---|---|
Wgf11interfaces |
テスト ジョブを実行します。 オプションを指定しない場合、テストではデバイスが列挙されます。 |
-FeatureLevel:XX.X |
機能レベルを設定します。ここで、XX.X は、テストが実行される機能レベル (10.0、10.1、または 11.0) です。 |
Note
このテスト バイナリのコマンド ライン ヘルプを表示するには、「/?」と入力します。
ファイル一覧
| ファイル | 場所 |
|---|---|
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 | net user の LLU 名 |
| ConfigDisplayCommandLine | ConfigDisplay のカスタム コマンド ライン。 既定値: logo |
| TDRArgs | /get または /set |