WGF11 介面 (WoW64)
此自動化測試會在使用介面時驗證硬體的不同部分和驅動程式，以執行有效的著色器。
此測試著重于涵蓋透過 DDI 提供給驅動程式的隱藏緩衝區資訊，其中包括介面類別型和資源位置。 介面中使用的某些資訊會內嵌在著色器本身，例如函式資料表和類別類型資料表。 硬體只需要正確呼叫和編制這些資料表的索引，因為執行時間會執行保持正確組織及對應資訊所需的所有管理。
測試只會執行有效的案例，並驗證結果是否成功。 認證 D3D11 硬體上不會發生任何失敗。
如先前的一致性測試一樣，測試會記錄到 WTT，並包含失敗的相關實用資訊，以協助 IHV 偵錯失敗。
本主題適用于下列測試作業：
WGF11 介面
WGF11 介面 (WoW64)
測試詳細資料
| 規格 |
|
| 平台 |
|
| 支援的版本 |
|
| 預期的執行時間 (以分鐘為單位) | 2 |
| 類別 | 相容性 |
| 以分鐘為單位的逾時 () | 120 |
| 需要重新開機 | false |
| 需要特殊設定 | false |
| 類型 | automatic |
其他檔
此功能區域中的測試可能會有其他檔，包括必要條件、設定和疑難排解資訊，可在下列主題中找到 () ：
執行測試
執行測試之前，請完成測試設定，如測試需求中所述： 圖形配接器或晶片組測試必要條件。
疑難排解
如需 HLK 測試失敗的一般疑難排解，請參閱 針對 Windows HLK 測試失敗進行疑難排解。
如需疑難排解資訊，請參閱 針對 Device.Graphics Testing 進行疑難排解。
測試會在功能層級 < 11 上執行時傳回 SKIP。 測試會在功能層級 < 11 上執行時傳回 SKIP。
詳細資訊
WGF11Interfaces - 介面著色器執行
WGF11Interfaces 涵蓋資料傳輸至驅動程式的所有層面，以及正確執行著色器 IL。
本節稍後會列出每個測試群組和必要命令列參數的描述。 本檔未提供整個著色器。 不過，會描述著色器的預期目標和輸入類型，以提供如何在 Windows 硬體品質實驗室中測試的資訊， (WHQL) 。 此外，每個測試都會在所有著色器階段上執行，以驗證符合統一架構目標之功能一致的行為。
測試會盡可能使用 ints 和 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 Interface\FunctionTables and fcall\[ PS]
Pri-1 16 小時
大型函式資料表測試會驗證硬體是否能夠管理編譯器的著色器程式輸出。 這項驗證專屬於著色器，這些著色器有許多級聯介面呼叫，導致產生許多函式主體的大量程式碼世代。 此測試不會測試這類著色器的效能，但會測試相較于參考轉譯器時，是否正確執行。
撰寫數個著色器，會循序將編譯器所建立的函式主體數目加倍。 這些著色器接著會在填滿位置的實例上執行數種變化，以驗證透過程式碼路徑子集的正確執行。 測試可以隨時嘗試驗證所有程式碼路徑，而且預期硬體不會在任何程式碼路徑上失敗。 如果硬體在著色器建立期間傳回記憶體不足，則當合理時，測試會傳回RESULT_SKIP。 這些著色器的資源需求不應推送硬體的限制。 因此，著色器應該系結並執行正常。 如果即使是小型函式資料表上的硬體失敗，就會發生警告。 硬體至少應支援 4 KB 的函式主體。
級聯函式是使用數種介面類別型所設計，每個類型都依賴另一個實例的物件作為參數。 這些呼叫的設計目的是要深度數層，而且很容易就會建立超過 1k 個函式主體。
測試也會透過大量呼叫其他函式來提供 fcall 指令的涵蓋範圍，以取得著色器中 4 KB 函式主體的適當涵蓋範圍。 這可以藉由使用執行時間使用 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 會導致無作業 (您只能在指定時間測試 33) 。 編譯器不允許撰寫程式碼來直接測試此案例，因此您需要更複雜的方法來動態變更呼叫深度，並確認每個呼叫都已 (或未進行) 。
fibinachi 序列或類似專案可能很適合此情況。 不允許遞迴呼叫，因此必須有 33 個介面可以彼此呼叫。 在本機，實例必須決定是否要繼續 Fall 深度。 執行時間會系結資料以驅動這些測試。
此測試會針對圖元著色器撰寫為 Pri-1。
此測試完成證明如下：
fcall 運作正常。
函式資料表正確且正正確使用。
支援 4 KB 函式資料表限制。
通話深度為 32。
測試結果會在下列轉譯目標中擷取：
WGF11Interfaces.exe Interface\FunctionTables 和 fcall \[VS、GS、HS、DS、CS]
Pri-2
測試涵蓋所有著色器階段。
這項功能的驗證支援各種有效的設計模式，以及著色器模型 5.0 設計來支援的 OO 程式設計技術。
這些測試的結果會在 VS、HS、DS 和 GS 的資料流程輸出緩衝區中擷取。 PS 和 CS 的結果會由轉譯目標和可寫入緩衝區擷取。
WGF11Interfaces.exe Interface\GroupExecutionPathDifferences\[ CS]
Pri-1 40 小時
設計硬體時，利用平行處理原則非常重要。 不過，當程式碼路徑不同時，對這類機會進行大寫不應中斷著色器的正確執行。 此測試會在每個著色器階段上執行，並提供涵蓋範圍，即使圖元、頂點和其他管線階段基本類型可能以鎖定步驟群組的形式執行，仍會執行不同的程式碼路徑。 此測試不會在這類情況下測試效能。 相反地，它只會在執行之後驗證有效的結果。
將資料提供給每個管線階段很重要，而且必須在可調整大小的區塊中完成，以驗證群組之間不同執行的涵蓋範圍。 下列方法會將資料提供給每個著色器階段的測試：
計算著色器：
用來選取以陣列位置為基礎的實例的資料，會使用資源提供給計算著色器。 SV_GroupID和SV_GroupThreadID可用來從資源選取正確的資料，以選擇要在叫用著色器期間使用的類別實例。 執行的結果會寫入可寫入緩衝區，以驗證其正確無誤。 會使用每個維度中線程的大型維度計數。 這包括大量執行緒和多個群組，這些群組將會分派以取得此測試的適當涵蓋範圍。
每個硬體執行緒都應該在執行時間所提供的不同類型中執行方法呼叫。 執行時間可以根據所使用的型別、提供的資料，以及類型的演算法來計算驗證結果。 每個方法的程式碼應該會隨著長度和複雜度而有所不同，以證明硬體可以處理如下的著色器。 應該使用 12-18 個不同的類別實作，而且每個SV_[Index] 值都可以進行虛擬強制回應，以挑選要執行的陣列索引和類別實例。
WGF11Interfaces.exe Interface\GroupExecutionPathDifferences\[VS，GS，PS，HS，DS]
Pri-2 40 小時
測試會延伸至其他著色器階段。
頂點著色器：
一組介面位置陣列索引會新增至頂點資料，並在頂點著色器執行期間使用，以判斷要叫用的介面實例。 當叫用方法時，資料也會涵蓋哪些實例做為參數使用。 繪製至少 512 點的區塊，以確認硬體行為。 結果會由資料流程輸出緩衝區攔截。
殼層著色器：
介面位置陣列索引會新增至控制點輸入結構，允許每個點判斷在著色器過程中叫用哪些類別實例。 當叫用方法時，該資料也涵蓋哪些實例做為參數使用。 系統會繪製完整的 32 點修補程式數次，以確認硬體行為。 結果會由資料流程輸出緩衝區攔截。
此測試也會將資料轉送至 Patch Constant 函式，這也會驗證正確的行為。
此外，編譯器會開啟SV_OutputControlPointID和特定的筆跡程式碼。 筆跡程式碼也會使用此階段中的介面，造成分岔程式碼執行路徑。 您可以使用迴圈來存取分叉，並從迴圈內呼叫介面方法。
網域著色器：
資料會透過每個控制點上的殼層著色器傳遞，然後使用網域著色器中可用的SV_PrimitiveID復原。 鑲嵌器輸出位置會與SV_PrimitiveID結合，以在執行期間將索引建立至可用的類別實例位置。 系統會繪製完整的 32 點修補程式數次，以確認硬體行為。 結果會由資料流程輸出緩衝區攔截。 焦點不是涵蓋所有網欄位型別。
幾何著色器：
介面位置索引會附加至提供給幾何著色器的基本類型。 索引可用來選擇類別實例，以叫用 方法，並在著色器執行期間當做參數使用。 繪製至少 512 點的區塊，以確認硬體行為。 結果會在資料流程輸出緩衝區中擷取以進行驗證。
圖元著色器：
針對圖元著色器，紋理是用來為每個圖元提供類別實例索引。 紋理會藉由繪製大型四邊形，完全符合轉譯目標的大小。 使用支援的資源繪製至少 512x512 圖元的區域，以驗證硬體行為。 結果會在轉譯目標中擷取以進行驗證。 SV_Position和SV_SampleIndex也可以用來判斷圖元索引在介面位置中的索引方式。 繪製三角形比繪製四邊形更有趣。
WGF11Interfaces.exe Interface\IndexingResources 和 this[]\[VS]
Pri-1 26 小時
介面所使用的所有資源都是由 IL 建立可編制索引，以支援動態執行時間系結。 資料是透過 DDI 提供，並包含下列資訊：
類別類型識別碼
Cbuffer
Cbuffer 位移
紋理位置
取樣器位置
此測試可確保驅動程式和著色器執行會正確使用這項資訊。 只有透過使用隱藏保留緩衝區的 「this」 關鍵字，才能存取此資訊。 256 個位元組的類別實例可以系結至著色器，因此此測試提供使用所有 256 個實例位置的涵蓋範圍。 這麼做表示這必須與此測試中的每個其他區域搭配使用。 不過，其他區域不需要透過彼此排列來驗證。
資源中所有不同位置和位移的測試週期位置，並在產生結果時使用這些資源。
為了取得完整涵蓋範圍，每個類別實例都應該執行方法，以利用資源資料來產生結果。 這麼做可確保實例類型識別碼在函式資料表方面正確使用。
每個 cbuffer 都必須針對類別資料進行測試。 資料必須使用 offset 參數在整個緩衝區中放置。 這可以藉由系結 256 個實例，每個實例都有執行時間所設定的不同位置。 著色器可以執行 256 個頂點，並使用 SV_PrimitiveID來判斷要使用的實例位置。
128 中可用的每個 tbuffer 位置都必須以先前所述的相同方式使用。 只需要使用簡單的緩衝區或 texture2d，而且只會測試負載指令。 測試只對紋理暫存器的正確編制索引感興趣。
著色器階段可用的 16 個取樣器位置必須與先前所述的相同方式使用。 取樣器會在紋理界限外取樣，以便傳回框線色彩。 每個 16 個取樣器都應該有唯一的框線色彩，以便測試確認使用了正確的取樣器。
這些可以個別測試，不需要結合涵蓋範圍。
F11Intefaces.exe Interface\IndexingResources 和 this[]\[GS，PS，HS，DS，CS]
Pri-2 26 小時
先前的測試會擴充以涵蓋所有著色器階段。
(Pri 1 18 小時) 延後的內容也應該用於這些測試中。
概述的測試案例也會使用命令清單來設定類別和實例，在延後的內容上執行。
命令清單不會從立即內容繼承狀態。 因此，在執行命令清單時，不應該存取在即時內容上設定的實例。
透過 ExecuteCommandList 和 FinishCommandList) 中的 bool 參數，延遲的內容 (狀態清除，應該使用介面和類別進行測試。
命令語法
| 命令選項 | 描述 |
|---|---|
Wgf11interfaces |
執行測試作業。 如果沒有任何選項，測試就會列舉裝置。 |
-FeatureLevel：XX.X |
設定功能 lewlve，其中 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 NET 使用者的名稱 |
| ConfigDisplayCommandLine | ConfigDisplay 的自訂命令列。 預設值：標誌 |
| TDRArgs | /get 或 /sets |