структура D3D12_FEATURE_DATA_ARCHITECTURE1 (d3d12.h)
Предоставляет подробные сведения об архитектуре каждого адаптера, чтобы приложение лучше оптимизировать для определенных свойств адаптера.
Синтаксис
typedef struct D3D12_FEATURE_DATA_ARCHITECTURE1 {
UINT NodeIndex;
BOOL TileBasedRenderer;
BOOL UMA;
BOOL CacheCoherentUMA;
BOOL IsolatedMMU;
} D3D12_FEATURE_DATA_ARCHITECTURE1;
Члены
NodeIndex
В операции с несколькими адаптерами это указывает, какой физический адаптер устройства имеет значение. См. раздел Многоадаптерные системы. NodeIndex заполняется приложением перед вызовом CheckFeatureSupport, так как приложение может получить сведения об архитектуре каждого адаптера.
TileBasedRenderer
Указывает, поддерживает ли оборудование и драйвер отрисовщик на основе плиток. Среда выполнения задает этому члену значение TRUE , если оборудование и драйвер поддерживают отрисовщик на основе плиток.
UMA
Указывает, поддерживает ли оборудование и драйвер UMA. Среда выполнения задает этому члену значение TRUE , если оборудование и драйвер поддерживают UMA.
CacheCoherentUMA
Указывает, поддерживают ли оборудование и драйвер UMA, согласованные с кэшем. Среда выполнения задает этому члену значение TRUE , если оборудование и драйвер поддерживают согласованное в кэше UMA.
IsolatedMMU
SAL: Out
Указывает, поддерживает ли оборудование и драйвер изолированную единицу управления памятью (MMU). Среда выполнения задает этому члену значение TRUE , если GPU учитывает свойства таблицы страниц ЦП, такие как MEM_WRITE_WATCH (дополнительные сведения см. в разделе VirtualAlloc) и PAGE_READONLY (дополнительные сведения см. в разделе Константы защиты памяти).
Если задано значение TRUE, приложение должно не использовать память с этими свойствами таблицы страниц с GPU, так как GPU может активировать эти свойства таблицы страницы непредвиденными способами. Например, операции записи в GPU могут быть более грубыми, чем ожидает приложение, особенно из шейдеров. Некоторые страницы watch записи могут отображаться грязное даже в том случае, если не очевидно, как на них повлияла запись в GPU. Операции GPU, связанные со сценариями использования кучи отправки и обратного чтения, хорошо работают с watch страниц с watch записи, но иногда могут создавать ложные срабатывания, которые можно игнорировать.
Комментарии
Использование UMA и CacheCoherentUMA
Приложения D3D12 должны быть связаны с управлением местом расположения памяти и предоставлением оптимальных свойств кучи. Приложения D3D12 могут оставаться упрощенными и работать достаточно хорошо во многих архитектурах GPU, управляя расположением только для ресурсов в D3D12_HEAP_TYPE_DEFAULT кучах. Эти приложения должны вызывать только IDXGIAdapter3::QueryVideoMemoryInfo для DXGI_MEMORY_SEGMENT_GROUP_LOCAL, и они должны быть терпимыми, что D3D12_HEAP_TYPE_UPLOAD и D3D12_HEAP_TYPE_READBACK поступать из той же группы сегментов памяти.Однако такая простая конструкция слишком ограничена для приложений, которые накладывают ограничения. Таким образом, D3D12_FEATURE_DATA_ARCHITECTURE помогает приложениям лучше оптимизировать базовые свойства адаптера.
Некоторым приложениям может потребоваться оптимизировать дискретные адаптеры, а также дополнительно усложнить управление системной и видеопамятью. Если размер кучи отправки соперничает с размером текстур по умолчанию, доступно почти удвоение использования памяти. При поддержке такой оптимизации приложение может обнаружить два бюджета места жительства или распознать UMAкак false.
Некоторым приложениям может потребоваться оптимизировать интегрированные адаптеры или адаптеры UMA, особенно те, которые заинтересованы в продлении времени работы батареи на мобильных устройствах. Простые приложения D3D12 вынуждены копировать данные между кучами с разными атрибутами, когда это не всегда необходимо для UMA. Однако свойство UMA само по себе охватывает довольно расплывчатую серую область конструкций GPU. Не думайте, что UMA означает, что вся доступная gpu память может быть свободно доступна ЦП, так как это не так. Существует свойство, которое более тесно соответствует такому типу мышления: CacheCoherentUMA.
Если CacheCoherentUMA имеет значение false, доступен единый бюджет резидентности, но дизайн UMA обычно выигрывает от трех присвоений кучи. Существуют возможности для удаления копирования ресурсов за счет разумного использования ресурсов отправки и обратного чтения, а также кучи, которые обеспечивают доступ ЦП к памяти. Однако такие возможности не являются четкими. Поэтому приложения должны быть осторожны; и экспериментировать в различных системах "UMA" рекомендуется, так как использование включения или исключения определенных идентификаторов устройств может быть оправдано. Рекомендуется получить представление об архитектуре памяти GPU и о том, как типы кучи преобразуется в свойства кэша. Возможность успешного выполнения, скорее всего, зависит от того, как часто каждый процессор считывает или записывает данные, от размера и места доступа к данным и т. д. Для опытных разработчиков: если UMA имеет значение true, а CacheCoherentUMA — false, наиболее уникальной характеристикой этих адаптеров является то, что кучи отправки по-прежнему объединяются с записью. Однако некоторые адаптеры UMA получают преимущества от использования свойств без доступа к ЦП и записи и объединения кучи по умолчанию и отправки. Дополнительные сведения см. в разделе GetCustomHeapProperties .
Если cacheCoherentUMA имеет значение true, приложения могут более сильно развлечь отказ от присвоения кучи и использование пользовательской кучи, эквивалентной кучам отправки везде. Оптимизация UMA с нулевым копированием, например, предлагаемая WriteToSubresource , в целом рекомендуется, так как больше сценариев просто выиграют от общего использования. Модель памяти очень способствует расширению сценариев и более широкому внедрению. Некоторые угловые случаи по-прежнему могут существовать, когда выгоды не легко получить, но они должны быть гораздо реже и менее вредными, чем другие варианты. Для опытных разработчиков : CacheCoherentUMA означает, что значительный объем кэшей в иерархии памяти также унифицирован или интегрирован между ЦП и GPU. Наиболее уникальной наблюдаемой характеристикой является то, что кучи отправки на самом деле обратно записываются в CacheCoherentUMA. Для этой архитектуры использование записи и объединения в кучах отправки обычно является ущербом.
Низкоуровневые сведения следует игнорировать в подавляющем большинстве приложений с одним адаптером. Как обычно, приложения с одним адаптером могут упростить ландшафт и гарантировать, что ЦП, записываемые для отправки кучи, используют шаблоны, удобные для записи и объединения. Более низкие сведения помогают укрепить концепции приложений с несколькими адаптерами. Приложениям с несколькими адаптерами, скорее всего, потребуется достаточно хорошо понимать свойства архитектуры адаптеров, чтобы выбрать оптимальные настраиваемые свойства кучи для эффективного перемещения данных между адаптерами.
Требования
| Требование | Значение |
|---|---|
| Заголовок | d3d12.h |
См. также раздел
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по