Ah, so it's more like different handlers for different tasks instead of three general-purpose units, though by the sound of it it's not even that clear with the distinction between drawing and computing. The latter was for whatever reason my first assumption. From that perspective it felt reasonable to think that there would be no reason to be more of them than there are CPU cores to feed them with commands. Teaches me to not make quick assumptions!
Thanks for taking the time to tell about this. Even though I obviously haven't delved into these lower level matters much, they are interesting to me too.
Yeah there's overlap between the draw+compute queue and the compute-only queue.
The idea here is kinda like hyper-threading -- if the current draw/dispatch command from the graphics queue isn't using 100% of the GPU's resources (maybe it's stalled, waiting for memory) then the GPU can use those idle resources to perform some work for the compute queue.
In the future, more and more compute-only queues will likely be added too. More queues = more independent jobs ready to be run = more chances for the GPUs scheduler to actually make use of all of its resources.
Extra draw queues aren't added simply because of complexity AFAIK. Draw commands require special scheduling, fixed function logic, but most importantly, are stateful (rely on a state machine, even at the hardware level). Compute (dispatch) commands are stateless at the hardware level (everything required to perform it is bundled into the command), making it much easier to juggle parallel execution, or constantly start/stop processing them.
The DMA queue is similar to the others, but it can't process draw/dispatch/compute tasks at all, it can only perform (async) memcpy tasks. Whenever the memory controller is not busy, it will try to do the next item in the DMA queue -- allowing it to sustain being busy if you've queues up a lot of work for it.
It might get magically used by things like glBufferData if you're lucky ;)
Note though that any number of CPU threads (or applications!) can share these queues. Console games can have 8 threads each producing their own "command buffers", and then doing some very minor synchronization to insert these command buffers into a single GPU queue.
Mantle/D3D12 will allow you to do the same, greatly increasing the amount of commands that the CPU is able to produce each frame ;-)
If Intel/nVidia actually get on board and form a Mantle committee with AMD, then I could see it seriously competing with GL, even replacing GL in future games... Unless the GL committee lifts their game!
It might even make some sense for Khronos to have some kind of "low-level GL" specification alongsinde OpenGL, because that way the latter could have an actual cross-platform and cross-vendor implementation built on the former. Then the folks who still want or need to use OpenGL would have to fight against just one set of quirks. Well, as long as the LLGL actually had uniformly working implementations...
