Передачи отрисовки Direct3D 12

Функция передачи отрисовки Direct3D 12 представлена в Windows 10 версии 1809 (WDDM 2.5). Она расширяет общую концепцию отрисовки, предоставляя более структурированный способ объявления зависимостей данных и целевых объектов вывода для набора операций отрисовки, что позволяет повысить эффективность обработки GPU.

В этой статье описываются цели функции рендер-прохода и перечислены ключевые дополнения и изменения DDI, которые поддерживают её. Для получения дополнительной информации см. спецификацию D3D12 Render Passes. Сведения об уровне приложения см. в разделе Direct3D 12 Render Passes.

Цели

Проходы рендеринга D3D12 предназначены для достижения следующих целей:

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

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

    Сокращение ненужных нагрузок и хранилищ ресурсов особенно оптимизирует отрисовку на архитектурах ТБDR (отложенной отрисовки на основе плиток).

  • Разрешить архитектуры ТБDR (отложенная отрисовка на основе плитки) для оппортунистически сохранять ресурсы в кэше на микросхеме в рамках передачи отрисовки (даже в отдельных списках команд)

    • Случай А. Чтение и запись пикселей "один к одному"

      Распространенный шаблон отрисовки — это когда приложение отрисовывает в целевое представление (RTV) A, а затем использует текстуру из этого ресурса как представление ресурсов шейдера (SRV) A в будущем при отрисовке в RTV B. В случаях, когда записи в RTV B считываются из SRV A "один к одному" (пиксели, сопоставленные с идентичным расположением в SRV A), некоторые архитектуры могут продолжать текущий процесс биннинга во время записи в RTV A. Таким образом, эти архитектуры избегают сброса в основную память, так как считывания из SRV A зависят только от текущей плитки.

      Цель проектирования заключается в том, чтобы эти два прохода объединялись без сброса в основную память.

    • Случай B. Запись в одни и те же целевые объекты отрисовки в нескольких списках команд

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

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

  • Разрешить использовать API передачи отрисовки для драйверов, которые не используют их преимущества

    Конструкция позволяет вызывать API для драйверов, которые не используют преимущества функции. Если приложение работает в достаточно новой среде выполнения, рендер-передачи можно использовать на всех устройствах. Приложения могут записывать один путь.

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

  • Разрешить UMD выбрать оптимальный путь рендеринга без высокого штрафа для ЦП

    Эта функция должна соответствовать целям D3D12 по низкой нагрузке на ЦП и должна быть разработана таким образом, чтобы не оказывать значительного влияния на использование ЦП при типичных операциях рендеринга (не более ~20%).

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

    Слой отладки должен помочь определить неправильное использование функции даже при запуске на драйвере, отличном от поддержки. (например, как слой отладки DX11 очищает ресурс случайным цветом в ответ на вызов команды сброса).

Отрисовка передает обновления интерфейса драйвера

В этом разделе описаны обновления интерфейса D3D12, внесенные для поддержки расширенной функции передачи отрисовки.

Объявление доступа к ресурсам

Добавляется перечисление D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0053 . Он задает начальный тип доступа ресурса в проходе рендеринга. Добавлены следующие расширенные значения прохода рендеринга:

  • D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0101_PRESERVE_LOCAL_RENDER
  • D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0101_PRESERVE_LOCAL_SRV
  • D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0101_PRESERVE_LOCAL_UAV

Аналогичным образом добавляется перечисление D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0053 . Он указывает конечный тип доступа ресурса в проходе отрисовки. Добавлены следующие расширенные значения прохода рендеринга:

  • D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0101_PRESERVE_LOCAL_RENDER
  • D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0101_PRESERVE_LOCAL_SRV
  • D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0101_PRESERVE_LOCAL_UAV

Во время pfnBeginRenderPass драйвер получает все ресурсы, которые служат в качестве RTVs/DSVs (представление источника данных) в рамках передачи отрисовки. Пользователь объявляет эти ресурсы и задает характеристики типа доступа начала и окончания. Начальные и конечные значения должны быть предоставлены для всех ресурсов.

Тип начального доступа Соответствующий тип конечного доступа
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0053_DISCARD D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0053_DISCARD
Тип начала доступа к рендер-процессу D3D12DDI_BEGINNING_ACCESS_TYPE_0053_PRESERVE D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0053_PRESERVE
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0053_CLEAR D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0053_RESOLVE
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0053_NO_ACCESS D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0053_NO_ACCESS
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0101_PRESERVE_LOCAL_RENDER D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0101_PRESERVE_LOCAL_RENDER
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0101_PRESERVE_LOCAL_SRV D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0101_PRESERVE_LOCAL_SRV
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0101_PRESERVE_LOCAL_UAV D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0101_PRESERVE_LOCAL_UAV

Тестирование WHLK

Direct3D 11on12 заменяет вызовы OMSetRenderTargets на BeginRenderPass/EndRenderPass соответствующим образом, чтобы проверить основные функции отрисовки с помощью проходов отрисовки.

HLK проверяет другие определенные функциональные возможности, в том числе:

  • Начальный флажок без отрисовки в передаче отрисовки и конечный параметр PRESERVE приводит к ясности для различных форматов ресурсов и типов (и счетчиков RT).

  • Начальная очистка с отрисовкой в передаче отрисовки и конечная команда PRESERVE обеспечивает ясность (с правильной упорядоченностью отрисовки после очистки) для различных форматов ресурсов и типов (и количества целевых объектов отрисовки).

  • Отмена НАЧАЛА, которая использует операции смешения или глубины, которые имеют зависимости от существующего содержимого, не приводит к зависаю GPU (неопределенные значения отрисовки являются тонкими).

  • Разрешение ENDING правильно разрешает ресурсы в различных конфигурациях (включая использование новых возможностей MIN/MAX для глубины или набора элементов, добавленных в ResolveSubresourceRegion).

  • Использование SUSPEND/RESUME не приводит к разнице в отрисовке по сравнению с ENDING_PRESERVE/BEGINNING_PRESERVE для различных форматов и типов ресурсов.

  • В случае использования preserve или preserve_local для НАЧАЛА или ОКОНЧАНИЯ, если в проходе отрисовки не выполняются никакие операции, значения по-прежнему сохраняются в целевом объекте отрисовки вне прохода.

  • Last updated on