# Why are committed resources better than placed resources?

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?

• The general answer is that the more flexibility you provide the driver, the better it can choose the right kind of memory based on the specific device. CreatePlacedResources is more proscriptive than CreateCommittedResource for technologies like nVidia TurboCache as well as dealing with video memory overcommittment. What actually happens is up to the driver writer here, which is basically what nVIDIA would prefer as noted in their article. In the end it's general advice, so you need to test on a variety of cards to see what actually works. – Chuck Walbourn Dec 4 '18 at 18:17
• @ChuckWalbourn: Thanks for the insight. I thought the entire point of Direct3D 12 was to leave less decisions to the driver so you can optimize for your use case, so I'm surprised that they would prefer to defer those decisions to the driver. – Panda Pajama Dec 7 '18 at 10:53

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"

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.