Интерфейсы WGF11 (WoW64)

Этот автоматизированный тест проверяет различные части оборудования и драйвера на допустимость выполнения шейдера при использовании интерфейсов.

В ходе теста основное внимание уделяется скрытию сведений о буфере, предоставляемых драйверу через DDI, включая типы интерфейсов и расположения ресурсов. Некоторые сведения, используемые в интерфейсах, внедряются в сам шейдер, например таблицы функций и таблицы типов классов. Оборудование требуется только для правильного вызова и индексирования этих таблиц, так как среда выполнения выполняет все необходимые операции управления для правильного упорядочения и сопоставления информации.

Тест выполняет только допустимые сценарии и проверяет успешное выполнение результатов. На сертифицированном оборудовании D3D11 не должно произойти никаких сбоев.

Журналы тестов для WTT, как и предыдущие тесты соответствия, и содержат полезные сведения о сбое, чтобы помочь IHV в отладке их сбоев.

Этот раздел относится к следующим тестовых заданиям:

• Интерфейсы WGF11

• Интерфейсы WGF11 (WoW64)

Сведения о тесте

Дополнительная документация

Тесты в этой области функций могут содержать дополнительную документацию, включая предварительные требования, сведения о настройке и устранении неполадок, которые можно найти в следующих разделах:

• Дополнительная документация по Device.Graphics

Выполнение теста

Перед запуском теста завершите настройку теста, как описано в разделе Требования к тестированию : Предварительные требования для тестирования графического адаптера или набора микросхем.

Устранение неполадок

Общие сведения об устранении неполадок при тестировании HLK см. в разделе Устранение неполадок при тестировании Windows HLK.

Сведения об устранении неполадок см. в разделе Troubleshooting Device.Graphics Testing.

Тест возвращает SKIP при запуске на уровне < компонентов 11. Тест возвращает SKIP при запуске на уровне < компонентов 11.

Дополнительные сведения

WGF11Интерфейсы — выполнение шейдера интерфейса

WGF11Interfaces охватывают все аспекты передачи данных драйверу, а также правильное выполнение IL-шейдера.

Описание каждой тестовой группы и необходимый параметр командной строки перечислены далее в этом разделе. В этой документации не указаны целые шейдеры. Однако описание предполагаемой цели шейдера и типы входных данных приводятся для предоставления сведений о том, как выполнять тестирование в Лабораториях качества оборудования Windows (WHQL). Кроме того, каждый тест выполняется на всех этапах шейдера, чтобы проверить согласованное поведение функции, которая соответствует целям единой архитектуры.

Тесты используют ints и uints в качестве входных данных и во время вычислений везде, где это возможно, так как точность и проверка математических вычислений с плавающей запятой рассматриваются в другом тесте соответствия.

Тесты, использующие выборки, выполняют выборку точек и используют цвет границы, чтобы проверить, используется ли правильный выборщик. Фильтрация и другие аспекты покрытия выборки рассматриваются в другом тесте соответствия. Тестирование интерфейса связано только с правильным индексированием выборок, используемых экземплярами класса во время выполнения.

Тесты, использующие ресурсы, ориентированы на форматы с 8-разрядными каналами без уровней MIP. Другие тесты проверяют правильность ресурса. Тестирование интерфейса связано только с правильным индексированием текстур, используемых экземплярами класса во время выполнения. Используются только загрузки ресурсов. Поскольку они не могут быть проиндексированы, БПЛА не важны для интерфейсов.

Тесты выполняются на каждом этапе шейдера, так как эта функция должна соответствовать единой архитектуре модели шейдера 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 КБ тела функций.

Каскадные функции разработаны с использованием нескольких типов интерфейсов, каждый из которых зависит от объекта другого экземпляра в своем параметре. Эти вызовы предназначены для нескольких уровней глубины и могут легко привести к созданию более 1 000 тел функций.

Тест также обеспечивает охват инструкции fcall путем активного вызова других функций, чтобы получить соответствующий охват 4 КБ тела функций в шейдере. Это можно сделать, изменив привязанные экземпляры с помощью 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, поэтому каждый вызов может быть уникальным на основе информации от вызывающего и вызываемого объекта. Простого умножения на константу недостаточно; Вместо этого каждый текст функции должен быть уникальным, выполняя различные операции и используя переменные-члены. Результирующие выходные данные должны быть проверены, поэтому умножение на простое число или что-то подобное будет работать. Чтобы убедиться, что шейдер выполнен правильно, необходимо выполнить те же математические вычисления на ЦП на основе привязанных экземпляров класса.

Этот тест также охватывает глубину дерева вызовов (32). Важно проверить, что более 32 fcalls приводят к отсутствием операций (вы можете протестировать только 33 в данный момент времени). Компилятор не позволяет писать код для простого тестирования этого случая, поэтому вам нужен более сложный подход, который может динамически изменять глубину вызова и проверять, что каждый вызов был выполнен (или не выполнен).

Для этого может быть полезна последовательность фибиначи или аналогичная. Рекурсивные вызовы не допускаются, поэтому должно быть 33 интерфейса, которые можно вызывать один за другим. Локально экземпляры должны решить, следует ли продолжить глубину fcall. Среда выполнения привязывает данные для выполнения этих тестов.

Этот тест написан для шейдера пикселей как Pri-1.

Выполнение этого теста подтверждает следующее:

• Fcall работает.

• Таблицы функций являются правильными и используются правильно.

• Поддерживается ограничение в 4 КБ для таблицы функций.

• Глубина вызова — 32.

Результаты теста записываются в следующем целевом объекте отрисовки:

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

Pri-2

Тест охватывает все этапы шейдера.

Проверка этой функции поддерживает широкий спектр допустимых конструктивных шаблонов и методов программирования на основе OO, для поддержки которыми была разработана модель Шейдера 5.0.

Результаты этих тестов записываются в буфер потоковой передачи для VS, HS, DS и GS. Результаты для PS и CS фиксируются целевыми объектами отрисовки и буферами, доступными для записи.

WGF11Interfaces.exe Interfaces\GroupExecutionPathDifferences\[ CS]

Pri-1 40 часов

Использование параллелизма очень важно при проектировании оборудования. Однако при использовании таких возможностей не следует нарушать правильное выполнение шейдера, если пути кода расходятся. Этот тест выполняется на каждом этапе шейдера и предоставляет покрытие, которое выполняет различные пути кода, несмотря на то, что пиксели, вершины и другие примитивы этапов конвейера могут выполняться как группы шагов блокировки. Этот тест не проверяет производительность в таких случаях. Вместо этого проверяется только допустимый результат после выполнения.

Предоставление данных для каждого этапа конвейера важно и должно выполняться в виде больших блоков, чтобы проверить охват разнообразных выполнений в разных группах. Следующий метод предоставляет данные для тестов для каждого этапа шейдера:

• Шейдер вычислений:

  Данные, используемые для выбора экземпляров, основанных на слотах массива, предоставляются с помощью ресурсов для вычислительного шейдера. SV_GroupID и SV_GroupThreadID используются для выбора правильных данных из ресурса и выбора экземпляров класса, используемых во время вызова шейдера. Результаты выполнения записываются в записываемый буфер для проверки правильности. Используется большое число потоков в каждом измерении. Сюда входят большое простое количество потоков и несколько групп, которые будут отправлены для получения адекватного покрытия для этого теста.

Каждый аппаратный поток должен выполнять вызов метода в другом типе, предоставляемом средой выполнения. Среда выполнения может вычислить результат проверки на основе используемого типа, предоставленных данных и алгоритма типа. Код для каждого метода должен отличаться по длине и сложности, чтобы доказать, что оборудование может обрабатывать шейдеры, как это. Необходимо использовать 12–18 различных реализаций классов, и каждое значение SV_[Индекс] может быть псевдомодировано для выбора индекса массива и экземпляра класса для выполнения.

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

Pri-2 40 часов

Тест распространяется на другие этапы шейдера.

• Вершинный шейдер:

  Набор индексов массива слотов интерфейса добавляется к данным вершины и используется во время выполнения вершинного шейдера, чтобы определить, какой экземпляр интерфейса следует вызвать. В данных также описывается, какие экземпляры используются в качестве параметров при вызове методов. Для проверки поведения оборудования рисуется блок не менее 512 точек. Результаты перехватываются буфером потоковой передачи.

• Шейдер корпуса:

  Индексы массива слотов интерфейса добавляются во входную структуру контрольной точки, что позволяет каждой точке определить, какие экземпляры класса вызываются в ходе шейдера. Эти данные также описывают, какие экземпляры используются в качестве параметров при вызове методов. Полное исправление в 32 точки нарисовывается несколько раз, чтобы проверить поведение оборудования. Результаты будут перехватываться буфером потоковой передачи.

  Этот тест также перенаправляет данные в функцию Patch Constant, которая также проверяет правильное поведение.

  Кроме того, в компиляторе включены SV_OutputControlPointID и определенный код вилки. Код вилки также вызывает различные пути выполнения кода с помощью интерфейсов на этом этапе. Доступ к вилке можно получить с помощью цикла и вызова метода интерфейса из цикла.

• Шейдер домена:

  Данные передаются через шейдер корпуса в каждой контрольной точке, а затем восстанавливаются с помощью SV_PrimitiveID, доступных в шейдере домена. Выходные позиции tessellator объединяются с SV_PrimitiveID для создания индексов в доступных слотах экземпляров класса во время выполнения. Полное исправление из 32 точек нарисовывается несколько раз, чтобы проверить поведение оборудования. Результаты перехватываются буфером потоковой передачи. Основное внимание уделяется не всем типам доменов.

• Геометрический шейдер:

  Индексы слотов интерфейса присоединяются к точечным примитивам, которые предоставляются шейдеру геометрии. Индексы используются для выбора экземпляров класса для вызова методов и использования в качестве параметров во время выполнения шейдера. Для проверки поведения оборудования рисуется блок не менее 512 точек. Результаты записываются в потоковый буфер для проверки.

• Шейдер пикселей:

  Для пиксельных шейдеров текстура используется для предоставления индексов экземпляра класса для каждого пикселя. Текстура точно соответствует размеру целевого объекта отрисовки путем рисования большого четырехугольника. Для проверки поведения оборудования рисуется область не менее 512 x 512 пикселей с вспомогательными ресурсами. Результаты фиксируются в целевом объекте отрисовки для проверки. SV_Position и SV_SampleIndex также можно использовать для определения того, как пиксель индексирует слоты интерфейса. Рисование треугольника более интересно, чем рисование квадроцикла.

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

Pri-1 26 часов

Все ресурсы, используемые интерфейсом, были сделаны индексируемыми il для поддержки динамической привязки среды выполнения. Данные предоставляются через DDI и включают в себя следующие сведения:

• Идентификатор типа класса

• Cbuffer

• Смещение Cbuffer

• Слот текстуры

• Слот выборки

Этот тест гарантирует, что все эти сведения правильно используются при выполнении драйвера и шейдера. Доступ к этой информации можно получить только через ключевое слово "this", в котором используется скрытый зарезервированный буфер. Экземпляры класса размером 256 байт могут быть привязаны к шейдеру, поэтому этот тест обеспечивает охват для использования всех 256 слотов экземпляров. Это означает, что это необходимо использовать в сочетании с каждой из других областей в этом тесте. Однако другие области не нужно проверять путем перестановки друг с другом.

Тестовые циклы расположений для всех различных слотов и смещения в ресурсах и используют эти ресурсы при получении результатов.

Чтобы получить полный охват, каждый экземпляр класса должен выполнять метод, который использует данные ресурса для получения результата. Это гарантирует правильное использование идентификатора типа экземпляра по отношению к таблицам функций.

Каждый cbuffer должен быть протестирован на наличие данных класса. Данные должны размещаться по всему буферу с помощью параметра offset. Это можно сделать, привязав 256 экземпляров с разным расположением, заданным средой выполнения. Шейдер может выполнять 256 вершин и использовать SV_PrimitiveID для определения используемого слота экземпляра.

Каждый слот tbuffer в доступном 128 необходимо использовать таким же образом, как упоминалось ранее. Требуется использовать только простой буфер или texture2d, и тестируется только нагрузочные инструкции. Тест заинтересован только в правильном индексировании регистров текстуры.

Каждый слот выборки в 16 доступных для этапа шейдера должен использоваться так же, как упоминалось ранее. Выборки будут выполняться за пределами границ текстуры, чтобы возвращался цвет границы. Каждый из 16 выборок должен иметь уникальный цвет границы, чтобы тест смог убедиться, что использовался правильный выборщик.

Их можно тестировать отдельно. Объединенное покрытие не требуется.

F11Intefaces.exe Interfaces\IndexingResources and this[]\[GS,PS,HS,DS,CS]

Pri-2 26 часов

Предыдущий тест расширен для охвата всех этапов шейдера.

(При 1 18 часов) В этих тестах также следует использовать отложенный контекст.

Описанные тестовые случаи также будут выполняться в отложенном контексте с помощью списков команд для задания классов и экземпляров.

Списки команд не наследуют состояние от непосредственного контекста. Поэтому экземпляры, заданные в непосредственном контексте, не должны быть доступны при выполнении списка команд.

Очистка состояния в отложенном контексте (с помощью параметра bool в ExecuteCommandList и FinishCommandList) должна быть протестирована с помощью интерфейсов и классов.

Синтаксис команды

Список файлов

Параметры