Поделиться через

Различия в модели привязки от Direct3D 11

  • Статья

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

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

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

В следующих разделах перечислены некоторые изменения модели привязки ресурсов с момента D3D11.

Управление резидентностью памяти, отделенное от привязки

Приложения имеют явный контроль над тем, какие поверхности должны быть доступны для прямого использования GPU (называется "резидентными"). И наоборот, они могут применять другие состояния к ресурсам, например явно делать их не резидентными, или разрешать ОС выбирать для определенных классов приложений, требующих минимального объема памяти. Важно отметить, что управление тем, какие ресурсы находятся в постоянной памяти приложения, полностью отделено от того, как этот доступ предоставляется шейдерам.

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

Управление временем существования объектов, отделенное от привязки

В отличие от предыдущих API, система больше не отслеживает привязки ресурсов к конвейеру. Ранее это позволяло системе поддерживать работоспособность ресурсов, от которых приложение отказалось, потому что на них всё ещё ссылаются незавершённые задачи GPU.

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

Отслеживание состояния ресурса драйвера, отделенное от привязки

Система больше не проверяет привязки ресурсов, чтобы понять, когда произошли переходы ресурсов, для которых требуется дополнительная работа драйвера или GPU. Распространенный пример для многих GPU и драйверов заключается в понимании, когда поверхность используется сначала как представление цели визуализации (RTV), а затем как представление ресурсов шейдера (SRV). Приложения сами должны определять, когда происходят любые переходы ресурсов, которые могут заинтересовать систему, с помощью выделенных API.

Синхронизация отображенной памяти между CPU и GPU отделена от привязки

Система больше не проверяет привязки ресурсов, чтобы понять, нужно ли отложить отрисовку, поскольку она зависит от ресурса, отображенного для доступа к ЦП, но еще не был размасштабирован. Теперь приложения несут ответственность за синхронизацию доступа к памяти ЦП и GPU. Чтобы помочь с этим, система предоставляет механизмы для приложения, чтобы запросить, чтобы поток ЦП находился в режиме ожидания, пока работа не будет завершена. Опрос также можно сделать, но может быть менее эффективным.

привязки ресурсов