Deano's 101 on Command Processors
-------------------------
What is a Command Processor? A Command Processor (CP) takes a list of packets AKA commands from the CPU and decodes them firing off the actual hardware to do stuff.
Whats a command? a command is a binary packet with header and information the hardware will need to perform the job the software asks of it.
i.e.a draw packet might have this kind of info
DrawPacket: header, pointer to index buffer, ptr to vertex buffer, state Id
What does the CP do?
Internally a GPU isn't logically like the interface provided via API, its essentially a bunch of different IP blocks each with there own registers and state. The CP decodes the packet into those various register sets and dma fetches etc. so that command actually get done.
CPs have to do A LOT of work, a modern GPU needs many packets of work to not idle, additionally its usually part of its job to ensure MMU tables and caches are flushed, sometimes handle power concerns, exceptions and state changes (preemption etc.). Whilst we like to see nice block diagram of a GPU with 30+ CU blocks, in reality each block is itself made of lots of bits of interacting HW. CPs will help with scheduling (depending on architecture how much) including breaking things in 'right sized' workloads. Because they often have to wait for various conditions, they usually themselves have a few threads and/or cores that can do work even whilst one part of the CP is stalling due to something or other. Additional there are multiple CPU cores/threads, different priorities and parts of the GPU themselves may issue work to the CP in a variety of conditions, the CP has to merge all this in a single stream of hardware instructions and potentially order some of the work once its been done (writes to host memory etc.)
Oh and the whole thing is hard real time else stuff breaks.
How does ExecuteXXX work? In a effort to reduce the CPU work, modern APIs have commands the offload work to the CP. A packet like this
ExecuteDrawPacket: header, number of draws, pointer to draw buffer each containing a index + vertex buffer ptr and state id
The could be done on the CPU with
from draw call 0 to number of draw
DrawPacket: index buffer ptr[draw call], vertex buffer ptr[draw call], state id[draw call]
So its purely an optimisation reducing work on the CPU and the space/bandwidth up to the CP
There is also ExecuteIndirect calls, these are a further optimisation where the parameters aren't known until after the CPU push the command into the command buffer
An example would be where you want to draw bunch of particles but how many is calculated via a compute shader
They *could* be emulated on the CPU but it would be slow, as it would have to copy the result of the compute shader down to the CPU and then write the command buffer.
ExecuteIndirect get the CP to fetch the parameters via its own dma which is usually fast as the compute buffer and CP will like share the same memory/cache hierarchy
BTW Its called microcode, as its essentially the same as old (pre RISC) CPUs, there the CPU ISA was actually decoded by the microcode engine into the real CPU hardware sets.
So thats the basics of a CP, they are the less glamorous assistant to the magicians in the shader cores, but without them the shader cores would rely on the main CPU a lot more and even then would run at a fraction of the speed they do.
-------------------------
Wrote this quickly, so hopefully no major mistakes, though I expect my grammar, spelling and wrong words will be there as usual for when I write stuff.
HTH,
Deano
