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

Размещение

  • Статья

Объект считается резидентным, если он доступен GPU.

Бюджет размещения

Графические процессоры пока не поддерживают сбой страниц, поэтому приложения должны зафиксировать данные в физическую память, пока GPU может получить к нему доступ. Этот процесс называется "создание чего-то резидентного" и должен выполняться как для физической памяти системы, так и для физической дискретной памяти видео. В D3D12 большинство объектов API инкапсулируют некоторое количество памяти, доступной для GPU. Эта память с доступом к GPU создается в процессе создания объекта API и вытесна при уничтожении объекта API.

Объем физической памяти, доступной для процесса, называется бюджетом памяти видео. Бюджет может заметно колебаться, как фоновые процессы пробуждения и сна; и резко меняется, когда пользователь переключается на другое приложение. Приложение может быть уведомлено при изменении бюджета и опросе текущего бюджета и используемого в настоящее время объема памяти. Если приложение не остается в бюджете, процесс будет периодически заморожен, чтобы разрешить другим приложениям выполняться и /или создавать API-интерфейсы будут возвращать сбой. Интерфейс IDXGIAdapter3 предоставляет методы, относящиеся к этой функции, в частности QueryVideoMemoryInfo и RegisterVideoMemorySourceChangeNotificationEvent.

Приложения рекомендуется использовать резервирование для обозначения объема памяти, которую они не могут обойти. В идеале заданные пользователем параметры графики "низкий" или что-то еще меньшее, является правильным значением для такого резервирования. Установка резервирования никогда не даст приложению более высокий бюджет, чем он обычно получает. Вместо этого сведения о резервировании помогают ядру ОС быстро свести к минимуму влияние ситуаций с большим давлением на память. Даже резервирование не гарантируется, что оно доступно приложению, если приложение не является приложением переднего плана.

Ресурсы кучи

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

  • Кучи не могут быть частично резидентными, но обходные пути существуют с зарезервированными ресурсами.
  • Кучи должны быть бюджетированы в рамках определенного пула. Адаптеры UMA имеют один пул, а дискретные адаптеры имеют два пула. Хотя это правда, что ядро может перемещать некоторые кучи на дискретные адаптеры из памяти видео в системную память, это делается только в качестве крайнего последнего способа. Приложения не должны полагаться на чрезмерное поведение ядра и должны сосредоточиться на хорошем управлении бюджетом вместо этого.
  • Кучи можно вытеснить из расположения, что позволяет вывести содержимое на диск. Но разрушение кучи является более надежным способом освободить место размещения во всех архитектурах адаптеров. На адаптерах, где поле D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT MaxGPUVirtualAddressBitsPerProcess находится недалеко от размера бюджета, Evict не будет надежно освободить место проживания.
  • Создание кучи может быть медленным; но он оптимизирован для фоновой обработки потоков. Рекомендуется создавать кучи на фоновых потоках, чтобы избежать сбоя потока отрисовки. В D3D12 несколько потоков могут безопасно вызывать подпрограммы одновременно.

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

  • Выделенные ресурсы одновременно создают ресурс и кучу. Куча неявна и не может быть напрямую доступ к ней. Куча имеет соответствующий размер, чтобы найти весь ресурс в куче.
  • Размещенные ресурсы позволяют размещать ресурс в ненулевых смещениях в куче. Смещения обычно должны быть выровнены по 64 КБ; но некоторые исключения существуют в обоих направлениях. Ресурсы MSAA требуют выравнивания смещения 4 МБ и выравнивание смещения 4 КБ доступно для небольших текстур. Размещение ресурсов невозможно переместить или перенаставить в другую кучу напрямую; но они обеспечивают простое перемещение данных ресурсов между кучами. После создания нового размещенного ресурса в другой куче и копирования данных ресурса необходимо будет использовать новые дескрипторы ресурсов для нового расположения данных ресурса.
  • Зарезервированные ресурсы доступны только в том случае, если адаптер поддерживает плитки уровня 1 или более поздней версии. Когда они доступны, они предлагают самые передовые методы управления размещением; но не все адаптеры в настоящее время поддерживают их. Они позволяют переназначить ресурс без необходимости повторного создания дескрипторов ресурсов, частичного расположения mIP и разреженных сценариев текстуры и т. д. Не все типы ресурсов поддерживаются даже в том случае, если зарезервированные ресурсы доступны, поэтому полностью общий диспетчер размещения на основе страниц еще не возможен.

Приоритеты расположения

Windows 10 Creators Update позволяет разработчикам влиять на то, какие кучи и ресурсы будут предпочитаться оставаться резидентными, если давление на память требует, чтобы некоторые из его ресурсов были понижены. Это помогает разработчикам создавать более эффективное приложение, используя знания, которые среда выполнения не может выводить из использования API. Ожидается, что разработчики станут более удобными и способными указывать приоритеты по мере перехода от использования зафиксированных ресурсов для повторного изменения и плитки ресурсов.

Применение этих приоритетов должно быть проще, чем управление двумя динамическими бюджетами памяти, ручное понижение и продвижение ресурсов bettween их, так как приложения уже могут сделать это. Таким образом, проектирование API приоритета расположения, конечно, определяется разумными приоритетами по умолчанию, назначенными каждой куче или ресурсу в качестве созданного. Дополнительные сведения см. в разделе ID3D12Device1::SetResidencyPriority и перечисление D3D12_RESIDENCY_PRIORITY.

С приоритетами разработчики, как ожидается, будут:

  • Повышение приоритета нескольких исключительных кучи, чтобы лучше смягчить опытное влияние этих кучи на снижение рано или чаще, чем их естественные шаблоны доступа будут требовать. Этот подход, как ожидается, будет использоваться приложениями, перенесенными из графических API, таких как Direct3D 11 или OpenGL, который является моделью управления ресурсами, значительно отличается от модели управления ресурсами Direct3D 12.
  • Переопределите почти все приоритеты кучи с помощью собственной схемы сегментизации приложения, фиксированной на основе знаний программиста о частоте доступа или динамической; Фиксированная схема проще управлять, чем динамическая, но может быть менее эффективной и требовать от программиста целый процесс, так как шаблоны использования изменяются в ходе разработки. Этот подход, как ожидается, будет использоваться приложениями, созданными с помощью управления ресурсами в стиле Direct3D 12, например тех, которые используют библиотеку резиденции (особенно динамические схемы).

Алгоритм приоритета по умолчанию

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

Стратегия, выбранная для создания приоритетов по умолчанию, заключается в классификации кучи в два контейнера, предпочитая (предоставляя более высокий приоритет) кучи, которые, как предполагается, записываются gpu по кучам, которые не являются.

Контейнер с высоким приоритетом содержит кучу и ресурсы, созданные с флагами, которые определяют их как целевые объекты отрисовки, буферы элементов глубины или неупорядоченные представления доступа (UAV). Они назначаются значения приоритета в диапазоне, начиная с D3D12_RESIDENCY_PRIORITY_HIGH; для дальнейшего приоритета между этими кучами и ресурсами, самые низкие 16-разрядные значения приоритета задаются на размер кучи или ресурса, разделенного на 10 МБ (насыщенность для 0xFFFF для очень больших кучи). Эта дополнительная приоритизация способствует большим кучам и ресурсам.

Контейнер с низким приоритетом содержит все остальные кучи и ресурсы, которым назначено значение приоритета D3D12_RESIDENCY_PRIORITY_NORMAL. Не предпринимается дополнительная приоритизация между этими кучами и ресурсами.

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

Простые приложения могут быть в состоянии получить, просто создавая зафиксированные ресурсы, пока не возникают сбои вне памяти. При сбое приложение может уничтожить другие зафиксированные ресурсы или объекты API, чтобы обеспечить успешное создание ресурсов. Но даже простые приложения настоятельно рекомендуется отслеживать негативные изменения бюджета и уничтожать неиспользуемые объекты API примерно один раз в кадре.

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

Еще более сложные проекты будут запрашивать функции текущего адаптера. Эта информация доступна в D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT, D3D12_FEATURE_DATA_ARCHITECTURE, D3D12_TILED_RESOURCES_TIER и D3D12_RESOURCE_HEAP_TIER.

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

ID3D12Heap

Управление памятью