структура 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 могут быть грубыми, чем ожидает приложение, особенно записи из шейдеров. Некоторые страницы отслеживания записи могут отображаться грязными, даже если это не очевидно, как записи GPU могут повлиять на них. Операции GPU, связанные с загрузкой и обратной загрузкой кучи, хорошо работают со страницами отслеживания записи, но иногда могут создавать ложные срабатывания, которые можно безопасно игнорировать.
Замечания
Использование 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 помогает приложениям лучше оптимизировать свойства базового адаптера.
Некоторым приложениям может потребоваться оптимизировать дискретные адаптеры и обеспечить дополнительную сложность управления памятью системы и бюджетами памяти видео. Если размер кучи отправки соперничает с размером текстур по умолчанию, доступно почти удвоение использования памяти. При поддержке таких оптимизаций приложение может обнаружить два бюджета расположения или распознать UMAfalse.
Некоторые приложения могут улучшить оптимизацию для интегрированных адаптеров или адаптеров UMA, особенно тех, которые заинтересованы в продлении срока работы батареи на мобильном устройстве. Простые приложения D3D12 вынуждены копировать данные между кучами с различными атрибутами, если это не всегда необходимо для UMA. Тем не менее, свойство UMA, само по себе, охватывает достаточно расплывчатую серую область конструкций GPU. Не предполагайте, что UMA означает, что все доступные для GPU память могут быть свободно доступны для ЦП, так как это не так. Существует свойство, которое более тесно соответствует этому типу мышления: CacheCoherentUMA.
Если CacheCoherentUMAfalse, доступен один бюджет размещения, но дизайн UMA обычно выгоден от трех куч. Существуют возможности для удаления копирования ресурсов с помощью мудрого использования ресурсов отправки и обратного чтения и кучи, которые обеспечивают доступ к памяти ЦП. Такие возможности не являются четкими, хотя. Поэтому приложения должны быть осторожными; и экспериментирование в различных системах "UMA" рекомендуется, так как может быть оправдано включение или включение или включение определенных идентификаторов устройств. Понимание архитектуры памяти GPU и рекомендуемого преобразования типов кучи в свойства кэша. Вероятность успешного выполнения зависит от частоты чтения или записи данных, размера и локальности доступа к данным каждого процессора и т. д. Для расширенных разработчиков: если UMA имеет значение true, а CacheCoherentUMAfalse, самая уникальная особенность для этих адаптеров заключается в том, что кучи отправки по-прежнему объединяются. Однако некоторые адаптеры UMA получают преимущества как без доступа к ЦП, так и для объединения записей свойств по умолчанию и отправки кучи. Дополнительные сведения см. в GetCustomHeapProperties.
Если CacheCoherentUMA верно, приложения могут более сильно развлекать присвоение кучи и использовать пользовательскую кучу эквивалента кучи отправки везде. Оптимизации UMA с нулевой копией, такие как предлагаемые WriteToSubresource, как правило, рекомендуется, так как больше сценариев будет просто выгоднее от общего использования. Модель памяти очень способствует большему сценарию и более широкому внедрению. Некоторые угловые случаи по-прежнему могут существовать, когда преимущества не легко получить, но они должны быть гораздо реже и менее вредными, чем другие варианты. Для расширенных разработчиков: CacheCoherentUMA означает, что значительное количество кэшей в иерархии памяти также унифицированы или интегрированы между ЦП и GPU. Самая уникальная наблюдаемая характеристика заключается в том, что кучи отправки фактически записываются обратно на CacheCoherentUMA. Для этой архитектуры использование кучи отправки с объединением записей обычно является ущербом.
Низкоуровневые сведения должны игнорироваться подавляющей частью приложений с одним адаптером. Как правило, приложения с одним адаптером могут упростить ландшафт и обеспечить, чтобы ЦП записывает данные для отправки кучи использовать шаблоны, которые являются понятными для записи. Подробные сведения более низкого уровня помогают укрепить основные понятия для приложений с несколькими адаптерами. Приложения с несколькими адаптерами, вероятно, должны понимать свойства архитектуры адаптера достаточно хорошо, чтобы выбрать оптимальные настраиваемые свойства кучи для эффективного перемещения данных между адаптерами.
Требования
| Требование | Ценность |
|---|---|
| заголовка | d3d12.h |