In the online docs here: https://msdn.microsoft.com/en-us/library/windows/desktop/dn899205(v=vs.85).aspx#recording_command_lists its says "you can call Reset while the command list is still being executed.". However in the second paragraph under the Remarks heading here: https://msdn.microsoft.com/en-us/library/windows/desktop/dn903895(v=vs.85).aspx it says "We recommend that apps only call Reset after they ensure that the graphics processing unit (GPU) has finished all previous executions of the command list.". Am I misunderstanding something or do these contradict each other?

Thanks in advance.

I don't know, the thing that is really confusing me is this line from my first link: "A typical pattern is to submit a command list and then immediately reset it to reuse the allocated memory for another command list." Why would it be a typical pattern if its not recommended? A typical pattern to who...? The DX team since they're the only people experienced at D3D12 at this time.

You can reset command lists as much as you want without need to synchronize. Command lists might have their own internal (CPU-side for misc stuff) allocations. If you reset & reuse them, you can avoid further re-/allocations. That's why it's a recommended pattern.

It says typical pattern not a recommended pattern, and I'm trying to get a feel of best practices. It seems to me depending on how its implemented this pattern might not be optimal... I was gonna benchmark but it makes sense to hold off for more mature drivers to be released.

It is the command allocator's reset that you need to ensure is still not in use by the GPU. But beware if you don't ever reset the allocator, memory consumption will grow until you run out of it and crash.

Yeah I saw a couple of places depicting how an allocator keeps its largest size unless reset, since a reset list is still associated with the same allocator it seems the memory of a single allocator will balloon if you keep reusing lists. Definitely something to keep in mind when architecting your renderer.

Yeah I saw a couple of places depicting how an allocator keeps its largest size unless reset, since a reset list is still associated with the same allocator it seems the memory of a single allocator will balloon if you keep reusing lists. Definitely something to keep in mind when architecting your renderer.

It actually keeps its largest size until destruction, not reset. Resetting an allocator just indicates that you can reuse the memory it's holding for other command lists, not that the memory it was holding onto got released.

This makes things even more complex in that you have to keep track of which allocators are appropriate for which command lists, as otherwise all of your allocators will grow to the worst case scenario. You definitely don't want to make a global allocator pool out of which you arbitrarily fetch allocators for use with arbitrary command lists. It's all about being aware of the memory footprint of your code.

It actually keeps its largest size until destruction, not reset. Resetting an allocator just indicates that you can reuse the memory it's holding for other command lists, not that the memory it was holding onto got released.

Doh you are absolutely correct, and I knew better. I hate when I do that.

This makes things even more complex in that you have to keep track of which allocators are appropriate for which command lists, as otherwise all of your allocators will grow to the worst case scenario. You definitely don't want to make a global allocator pool out of which you arbitrarily fetch allocators for use with arbitrary command lists. It's all about being aware of the memory footprint of your code.

Yeah memory management is whats making me pause my coding efforts. I trying to get it right or easily correctable on the first try. What makes things worst WRT command submission is that I haven't seen a way to track memory allocations of lists/allocators so I can't get to know them more intimately. Then again I haven't used the Graphics debugger that VS2015 has.

Doh you are absolutely correct, and I knew better. I hate when I do that.

No worries, this is all uncharted territory so far, it even gets confusing for people who have been working with it for a while.

I trying to get it right or easily correctable on the first try.

Maybe going through this API with a trial and error approach is actually a better strategy than just trying to 'get it right' the first time. In all honesty, there often is no single one 'right way' do to things, it's all very specific to your application's needs.