В D3D12, может ли целевой вид рендеринга быть любым буфером?

Question

В образцах, я посмотрел на до сих пор некоторые из команд что-то вроде:

1. D3D12_DESCRIPTOR_HEAP_DESC с D3D12_DESCRIPTOR_HEAP_TYPE :: D3D12_DESCRIPTOR_HEAP_TYPE_RTV
2. ID3D12Device :: CreateDescriptorHeap
3. D3D12_CPU_DESCRIPTOR_HANDLE с ID3D12DescriptorHeap :: GetCPUDescriptorHandleForHeapStart (и, возможно, ID3D12Device :: GetDescriptorHandleIncrementSize)
4. (опционально?) ID3D12Device :: CreateRenderTargetView
   1. (необязательно?) IDXGISwapChain3 :: GetBuffer
5. График рендеринг вещь в список команд, нотные OMSetRenderTargets и DrawInstanced, а затем закройте список команд.
6. ID3D12CommandQueue :: ExecuteCommandLists
   1. (необязательно?) IDXGISwapChain3 :: Присутствуют
7. График сигнала с ID3D12CommandQueue :: Сигнал на заборе
8. Дождитесь GPU, чтобы закончить с ID3D12Fence :: SetEventOnCompletion и WaitForSingleObjectEx

Если возможно, как шаг 4.1 можно заменить на буфер? То есть как можно создать ID3D12Resource * и визуализировать его, а затем прочитать из него, скажем, std :: vector? (Я предполагаю, что если возможно, что шаг 6.1 можно проигнорировать, так как не существует целевого представления рендеринга для своп-цепочки для представления. Возможно, в этом случае необязательный шаг 4. Возможно, важны только вопросы OMSetRenderTargets?)

Answer 1

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

Таким образом, у вас есть ограничения на то, где именно может находиться точка рендеринга. Вот почему вы должны использовать D3D12_HEAP_TYPE_DEFAULT и указывать D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET при создании ID3D12Resource, который вы планируете связывать как цель рендеринга (это неявно выполняется DXGI при создании цели рендеринга подкачки).

Вообще говоря, вы не можете и не должны использовать низкоуровневые API-интерфейсы для создания поверхностей DXGI для создания ресурсов Direct3D. Они в основном существуют для системного использования, а не приложений.

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

Direct3D 12 также предлагает методы «Размещенные ресурсов», а также которые могут обеспечить больший контроль над тем, где именно выделяется память (или более конкретно, где адреса виртуальной памяти выделяются), но вы все равно должны соблюдать основные ограничения архитектуры.В зависимости от архитектуры памяти вы можете «псевдоним» нескольких разных экземпляров ID3D12Resource, использующих одну и ту же память (например, объект рендеринга быть псевдонимом как неупорядоченный ресурс доступа), но вы несете ответственность за вставку необходимых барьеров ресурсов в список команд (и протестируйте его), чтобы убедиться, что он надежно работает на всех аппаратных средствах DX12. См. MSDN.

У вас нет необходимости в Present вашей цели рендеринга, если вам не нужен пользователь, чтобы увидеть результат.

Memory Management Strategies

UMA Optimizations: CPU Accessible Textures and Standard Swizzle

Getting Started with Direct3D 12

Если вы новичок в DirectX 12, вы должны увидеть DirectX Tool Kit for DirectX 12 учебники. Если вы еще не знакомы с DirectX 11, вам следует подождать DirectX 12 и начать с DirectX Tool Kit for DirectX 11.