Why are committed resources better than placed resources?

Question

This NVIDIA document regarding dos and don'ts in DirectX 12 states the following:

Use committed resources where possible to give the driver more knowledge

• This allows the driver to better manage GPU memory
• A good use case for placed resources are resource heaps that are e.g. used during streaming and do hold different sets of read-only textures over their life time

But this raises more questions than it answers:

• What additional knowledge is given to the driver if I use a committed resource? The information on the resource that I pass to both CreateCommittedResource and CreatePlacedResource is pretty much the same...
• What does it mean that the driver will better manage GPU memory?
• If I know what the allocation/deallocation patterns look like in my game, isn't it better if I manage GPU memory manually with placed resources, instead of letting the GPU decide where to place each resource, and potentially run into VRAM fragmentation in the long run? Or will the driver perform heap defragmentation?
• CreateCommittedResource creates an implicit heap each time it is called, while CreatePlacedResource simply creates the resource over the memory I choose on an existing heap, and is therefore much faster. Wouldn't it be preferable in most cases to use placed resources instead? Especially if I am interested in creating loading screens that don't miss a single frame deadline?

I am quite surprised to read from NVIDIA that committed resources are preferable to placed resources. Could anybody explain in more detail what else is happening under the hood, so committed resources are preferable to placed resources?

Answer 1

You will get contradicting suggestions from their own: http://developer2.download.nvidia.com/assets/gameworks/downloads/regular/GDC17/DX12CaseStudies_GDC2017_FINAL.pdf

Page 14: "Sub-allocation from a larger heap (as intended) improved performance by ~15%"

Page 46: "Creating committed resources for everything will use tons of memory"

https://developer.nvidia.com/sites/default/files/akamai/gameworks/blog/GDC16/GDC16_gthomas_adunn_Practical_DX12.pdf

Pages 25 ~ 26

The philosophy of the new-generation APIs is to offload burden from drivers (implicit, extra guess work) to applications who know the needs better (explicit, do only what you need), to boost CPU performance and save GPU memory (less fragmentation, better reuse). D3D12 Committed resources are just like D3D11 resources, if you use Committed resources then you go back to D3D11 with driver and possibly paging (on over-subscription) costs.

https://software.intel.com/content/www/us/en/develop/blogs/direct3d-12-overview-part-3-resource-binding.html

"Resource residency management:

GPUs like to use a lot a video memory, more in fact that is often available. This can be more of problem with discrete video cards with a set amount of memory. So we have resource residency management that pages things in and out of memory as the commands flow. To the game it looks like there is unlimited memory, when really it is just memory management. Once again this comes at a cost of reference counting and tracking.

Just like resource lifetime, the game gets explicit control over resource residency. D3D 11 tracks the residency counts and control flow in the operating system. Typically though the game already knows that a sequence of rendering commands refers to a set of resources. In D3D 12 the game can now explicitly tell the operating system to move them into memory. Later on when the commands have been executed the game can have the resources removed from memory."

Allocations call into the kernel-model driver, which is costly.

Vulkan even has a limit in # of allocations.

https://docs.microsoft.com/en-us/windows/win32/direct3d12/memory-management-strategies

Search for "sub-allocation" + "Direct3D 12"/"Vulkan"/"Metal", you will basically get the same answer except in this NVIDIA DX12 Do's And Don'ts.