[Question]: Is D3D12 encoding properly supported?

[MichaelLudeo]

I am searching the code samples for d3d12 related encoding example and I can't find one. In SimpleEncoder.cpp I see some functions kind of ready for d3d12, but there is also commented our code like this:

#ifdef _WIN32
//static amf::AMF_MEMORY_TYPE memoryTypeIn  = amf::AMF_MEMORY_DX11;
//static amf::AMF_MEMORY_TYPE memoryTypeIn = amf::AMF_MEMORY_DX12;
static amf::AMF_MEMORY_TYPE memoryTypeIn = amf::AMF_MEMORY_VULKAN;
#else
static amf::AMF_MEMORY_TYPE memoryTypeIn  = amf::AMF_MEMORY_VULKAN;
#endif

Does AMF provide solid support for d3d12? If it is , should I do something specific for this case, like explicit synchronization of data transfer at the start/end of encoding?

For example, when I create D3D texture resource from which I am going to submit image data to the encoder,what flags should be set?

D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET? Or maybe also D3D12_RESOURCE_FLAG_ALLOW_SIMULTANEOUS_ACCESS ?

[MikhailAMD]

AMF does fully support D3D12. But because AMF is kind of abstraction in many cases particular D3D API is not very visible. Agreed, we need to provide more documentation in this area. Few points:

• AMFContext2::InitDX12() method either accepts external ID3D12Device device or creates an internal one if nullptr is passed.
• Explicit synchronization: Assume a ID3D12Resource (texture) is created outside of AMF. AMFSurface containing this resource can be created via AMFContext2::CreateSurfaceFromDX12Native() method. If AMF needs to wait for some GPU operation, ID3D12Fence and fence value have to be attached as a private property to the ID3D12Resource. See D3D12AMF.h for property GUIDs and some comments.
• The same is for resource state, the current state has to be attached as a property.
• If AMF submits a GPU job and didn't wait, similarly, fence, fence value and state can be retrieved from ID3D12Resource using the same GUIDs
• ID3D12Resource can be always retrieved via (ID3D12Resource*)(surface->GetPlane(0)->GetNative()), considering that current surface memory type is DX12
• if you plan to use AMF color converter, scaler, or other shader-based component, with your input you need not to use D3D12_RESOURCE_FLAG_DENY_SHADER_RESOURCE.
• If you plan to submit your texture to AMF encoder, you need to allocate it with D3D12_HEAP_FLAG_SHARED flag for heap
• Synchronization specific to encoder: If encoder needs to wait for rendering, provide fence as described above. During encoding encoder stores AMFSurface/ID3D12Resource and it cannot be used from outside. When encoding is complete, output AMFBuffer is returned. From this point the resource can be reused. One can track the resource by providing AMFSurfaceObserver callback to CreateSurfaceFromDX12Native. OnSurfaceDataRelease will be called when AMFSurface is about to be destroyed. Alternatively, you can attach some ID to AMFSurface via base AMFPropertyStorage interface. All properties unknown to the encoder will be copied from encoder input to encoder output.
• The explicit synchronization is somewhat covered in PlaybackHW sample in SwapChainDX12.h and cpp.
• Note, that AMF components use the explicit synchronization described above while they exchange AMFSurface or AMFBuffer objects. I will be glad to answer more questions.

[MichaelLudeo]

Yeah, the lib has thrown me on missing D3D12_HEAP_FLAG_SHARED flag right away. Now it all works. Thanks for the detailed answer ))