다음을 통해 공유


WGF11 인터페이스(WoW64)

이 자동화된 테스트는 인터페이스가 사용될 때 유효한 셰이더 실행을 위해 하드웨어와 드라이버의 다른 부분을 확인합니다.

테스트는 인터페이스 유형 및 리소스 위치를 포함하는 DDI를 통해 드라이버에 제공되는 숨겨진 버퍼 정보를 다루는 데 중점을 둡니다. 인터페이스에서 사용되는 일부 정보는 함수 테이블 및 클래스 유형 테이블과 같이 셰이더 자체에 포함됩니다. 런타임은 정보를 올바르게 구성하고 매핑하는 데 필요한 모든 관리를 수행하기 때문에 하드웨어는 이러한 테이블을 올바르게 호출하고 인덱싱하는 데만 필요합니다.

테스트는 유효한 시나리오만 실행하고 결과가 성공적인지 확인합니다. 인증 가능한 D3D11 하드웨어에서는 오류가 발생하지 않을 것으로 예상됩니다.

테스트는 이전 준수 테스트와 마찬가지로 WTT에 기록하고 IHV가 실패를 디버그할 수 있도록 하는 실패에 대한 유용한 정보를 포함합니다.

이 항목은 다음 테스트 작업에 적용됩니다.

  • WGF11 인터페이스

  • WGF11 인터페이스(WoW64)

테스트 세부 정보

   
사양
  • Device.Graphics.AdapterRender.D3D111Core.D3D111CorePrimary
  • Device.Graphics.AdapterRender.D3D11Core.D3D11CorePrimary
플랫폼
  • Windows 10, 클라이언트 버전(x64)
  • Windows Server 2016(x64)
  • Windows 10, 클라이언트 버전(Arm64)
지원되는 릴리스
  • Windows 10
  • Windows 10 버전 1511
  • Windows 10 버전 1607
  • Windows 10, 버전 1703
  • Windows 10, 버전 1709
  • Windows 10, 버전 1803
  • Windows 10, 버전 1809
  • Windows 10, 버전 1903
  • Windows 10에 대한 다음 업데이트
예상 실행 시간(분) 2
범주 호환성
시간 제한(분) 120
다시 부팅 필요 false
특별한 구성 필요 false
형식 automatic

 

추가 설명서

이 기능 영역의 테스트에는 다음 항목에서 찾을 수 있는 필수 조건, 설정, 문제 해결 정보를 포함한 추가 설명서가 있을 수 있습니다.

테스트 실행

테스트를 실행하기 전에 테스트 요구 사항 그래픽 어댑터 또는 칩셋 테스트 필수 구성 요소에 설명된 대로 테스트 설정을 완료합니다.

문제 해결

HLK 테스트 실패의 일반적인 문제 해결은 Windows HLK 테스트 실패 문제 해결을 참조하세요.

문제 해결 정보는 Device.Graphics Testing 문제 해결을 참조하세요.

테스트는 기능 수준 < 11에서 실행될 때 SKIP을 반환합니다. 테스트는 기능 수준 < 11에서 실행될 때 SKIP을 반환합니다.

추가 정보

WGF11Interfaces - 인터페이스 셰이더 실행

WGF11Interfaces는 셰이더 IL의 올바른 실행과 함께 드라이버로의 데이터 전송의 모든 측면을 다룹니다.

각 테스트 그룹에 대한 설명과 필요한 명령줄 매개 변수는 이 섹션의 뒷부분에 나열되어 있습니다. 이 설명서에서는 전체 셰이더를 제공하지 않습니다. 그러나 WHQL(Windows Hardware Quality Labs)에서 테스트하는 방법에 대한 정보를 제공하기 위해 셰이더의 의도된 목표와 입력 유형에 대한 설명이 설명되어 있습니다. 또한 각 테스트는 통합 아키텍처 목표를 준수하는 기능에 대한 일관된 동작을 확인하기 위해 모든 셰이더 단계에서 실행됩니다.

부동 소수점 수학의 정밀도와 검증은 다른 준수 테스트에서 다루기 때문에 테스트는 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을 반환합니다. 이러한 셰이더의 리소스 요구 사항은 하드웨어의 한계를 넘지 않아야 합니다. 따라서 셰이더는 잘 바인딩되고 실행되어야 합니다. 작은 함수 테이블에서도 하드웨어가 실패하면 경고가 발생합니다. 하드웨어는 최소 4KB 함수 본문을 지원해야 합니다.

계단식 함수는 여러 인터페이스 유형을 사용하여 설계되었으며, 각 인터페이스 유형은 해당 매개 변수에 대해 다른 인스턴스의 개체에 의존합니다. 이러한 호출은 여러 계층으로 설계되었으며 쉽게 1k 이상의 함수 본문이 만들어질 수 있습니다.

테스트는 또한 셰이더에서 4KB 함수 본문의 적절한 적용 범위를 가져오기 위해 다른 함수를 광범위하게 호출하여 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개만 테스트할 수 있음). 컴파일러는 이 경우를 단순히 테스트하기 위해 코드를 작성하는 것을 허용하지 않으므로 호출 깊이를 동적으로 변경하고 각 호출이 수행되었는지(또는 수행되지 않았는지) 확인할 수 있는 보다 정교한 접근 방식이 필요합니다.

피보나치 수열 또는 이와 유사한 것이 유용할 수 있습니다. 재귀 호출은 허용되지 않으므로 차례로 호출할 수 있는 인터페이스가 33개 있어야 합니다. 로컬에서 인스턴스는 fcall 깊이를 계속할지 여부를 결정해야 합니다. 런타임은 이러한 테스트를 실행하기 위해 데이터를 바인딩합니다.

이 테스트는 픽셀 셰이더에 대해 Pri-1로 작성되었습니다.

이 테스트를 완료하면 다음이 증명됩니다.

  • fcall이 작동합니다.

  • 함수 테이블이 올바르고 올바르게 사용 중입니다.

  • 4KB 함수 테이블 제한이 지원됩니다.

  • 호출 깊이는 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개의 포인트 블록이 그려집니다. 결과는 확인을 위해 스트림 출력 버퍼에 캡처됩니다.

  • 픽셀 셰이더:

    픽셀 셰이더의 경우 텍스처를 사용하여 각 픽셀에 대한 클래스 인스턴스 인덱스를 제공합니다. 텍스처는 큰 쿼드를 그려서 렌더링 대상의 크기와 정확히 일치합니다. 하드웨어 동작을 확인하기 위해 지원 리소스와 함께 최소 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는 클래스 데이터에 대해 테스트해야 합니다. 오프셋 매개 변수를 사용하여 버퍼 전체에 데이터를 배치해야 합니다. 이는 런타임에 의해 설정된 다른 위치로 각각 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)입니다.

참고

   이 테스트 이진에 대한 명령줄 도움말을 보려면 /?를 입력합니다.

 

파일 목록

파일 위치

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 사용자의 LLU 이름
ConfigDisplayCommandLine ConfigDisplay용 사용자 지정 명령줄 기본값: 로고
TDRArgs /get 또는 /sets