Sign in to follow this  
nbertoa

[D3D12] About CommandList, CommandQueue and CommandAllocator

Recommended Posts

I read D3D12 Documentation and I am reading Frank Luna's book about DirectX12.

 

One thing I do not understand is the following:

 

When you record commands in a ID3D12CommandList, you are really writing commands in a ID3D12Allocator memory. This memory should be in CPU memory (some place in heap memory (RAM)), fo performance reasons.

 

When you execute a ID3D12CommandList, you actually send ID3D12Allocator memory from CPU to GPU memory (CommandQueue memory I think) so the GPU can consume these commands once it reaches your commands in the queue.

 

The question is: If ID3D12CommandList adds commands in an ID3D12Allocator that is in CPU before we execute that command list. Why cannot we record new commands in the same ID3D12CommandList and for the same ID3D12Allocator, if you are actually writing commands in CPU memory?

 

Any of my assumptions is incorrect? Am I missing some architectural decision?

 

Thanks in advance!

Share this post


Link to post
Share on other sites
Thanks for the detailed explanation. Yes, I know you can reuse same cmdList but you nees to be sure about cmdAllocator first or change it. I think I cannot assume any behavior (cpu or gpu memory) because that will depend on gpu architecture and driver implementation. In my case I try to avoid fences when possible.

Share this post


Link to post
Share on other sites

If CPU/GPU memory is not unified there is a latency that GPU must pay if you want to read things from CPU through PCI-Express. And that latency implies GPU could be idle wailting for the new data, and that is not desired.

Let's say it looks like:

CPU<-->"CPU RAM"<-->PCIe<-->GPU Command Processor<-->GPU Compute Units

Let's also say that:

* it takes the command processor 1?s to fetch a draw command and to schedule that work for the GPU compute units.

* the compute cores take 2?s to actually execute the draw command.

* these two parts of the GPU operate in parallel.

^^^ In this situation, the PCIe latency is not an issue whatsoever; the GPU will not idle. While the GPU compute cores are busy executing Draw#1, the command processor easily has enough time to fetch and prepare Draw#2.

 

n.b. if your draw-calls take 2?s each on average, that means you can be performing over 8000 draw-calls in a 60Hz frame. That's a lot; many games won't use anywhere near that many draw commands per frame. So a lot of the time it may be more like 1?s to fetch the next command, in parallel with 20?s execution of the previous command!

 

PCIe latency only becomes a problem if your draw-calls are so small that they take a fraction of a microsecond each, and you're trying to perform 100k of these tiny draw-calls per frame. e.g. if the CP takes 1?s to fetch/prepare a draw command, but the CU's execute it in 0.5?s -- in this situation the GPU will begin to idle due to the slow command fetching. The solution here is to make your draw-calls contain more work each, and use less of them :wink:

Edited by Hodgman

Share this post


Link to post
Share on other sites

@Hodgman:

 

But I think you are assuming you have all the bus for you, in that scenario, latency could not be a problem. But also, through that bus your app or other app that is running simultaneously could be sending resources like buffers, textures, etc. This should be handled by GPU scheduler. Then your bandwidth/latency will not be the same as if the bus is all for you.

 

After reading all your answers, I think I found the answer to my question. If CPU/GPU memory is unified (like consoles) then the CmdAllocator memory will be the same memory than the GPU references, then you cannot write on it until you are sure (through a fence, I think) that all your commands in you allocator were processed by GPU. That is why API has that restriction.

 

@Spinningcubes:

 

I am in Chapter 6, and reading it + documentation + GDC's presentations + forums simultaneously. For now, I think the book is useful and understandable.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this