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

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

  • Статья

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

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

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

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

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

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

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

Управление жизненным циклом объектов, отделенное от привязки

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

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

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

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

Синхронизация сопоставленной памяти ЦП GPU отделена от привязки

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

Привязка ресурсов