4 ms·
The idea that it's a bottleneck is wrong. Just because it's one thread doesn't make it a bottleneck. Draining from N queues into 1 queue and posting that work o
by kllrnohj 12y ago
The idea that it's a bottleneck is wrong. Just because it's one thread doesn't make it a bottleneck. Draining from N queues into 1 queue and posting that work off to the GPU is never going to be a bottleneck. Even an arduino can handle that task fast enough to saturate the latest & greatest from Nvidia or AMD.
Also fwiw in DX12 even if parallel submission is supported, what's going to happen is N user threads are going to submit to 1 driver thread that then submits to the actual GPU.
- shmerl 12y agoI understood it that GPU itself can handle multiple commands concurrently, no? So if hardware supports it and there is just one thread submitting them, hardware isn't used to full capacity. Or that's wrong? And what's the point of making one thread do it, if multiple can? Queuing through one usually makes sense if you need some ordering.
- kllrnohj 12y agoMost GPUs cannot handle multiple arbitrary commands concurrently, but even if they can you're still going to easily saturate that with a single thread pushing over command buffers. The command buffers in this case are large, complex work units, not small microtransactions like the APIs of old. And yes, ordering is needed here.
- shmerl 12y agoSo how exactly then DX12 and Mantle do it? They don't appear to have such single queue manager thread. You said driver does that task. So if it does, can't it do it for Vulkan as well? Or their point is to reduce driver complexity here? I can see that it might be not a major issue if time that takes it to fetch from the queue is way smaller than time it takes to execute some command [buffer]. I.e if queue manager will fetch and push commands to the queue, returning to fetch another without waiting for the first to finish, then it will work fine (it will have to handle GPU saturation though). But if it will be blocking - it will be some bottleneck which won't let using hardware fully.
- kllrnohj 12y agoGraphics APIs are almost universally non-blocking, this won't be blocking either. Vulkan is basically a rebranded Mantle. I suspect you're just mistaken about Mantle, but as that API is not (yet?) open we don't really know if this was a change Khronos made when adopting Mantle or if this is just how Mantle works as well. DX12 works the same as Vulkan, though, with a single submission thread ("The only serial process necessary is the final submission of command lists to the GPU via the command queue, which is a highly efficient process." http://blogs.msdn.com/b/directx/archive/2014/03/20/directx-12.aspx http://blogs.msdn.com/b/directx/archive/2014/03/20/directx-1...)
- shmerl 12y agoAbout Mantle, I saw this: http://techreport.com/review/25683/delving-deeper-into-amd-mantle-api/2 http://techreport.com/review/25683/delving-deeper-into-amd-m... It shows that multiple queues can be used for one GPU. I guess Vulkan can allow the same but it's not clear from that diagram.
- kllrnohj 12y agoTake a look at that again. There's one queue per type. One queue for graphics, one queue for compute, and one queue for DMA. Note that multiple threads are all feeding the single graphics queue.
- shmerl 12y agoYeah, I understood that. One queue per independent type of tasks. But Vulkan diagram didn't mention even that. May be such parallelism is AMD specific, and Vulkan being more generic has to cater for the wider range of GPUs. Not sure.
- shmerl 12y agoI found the answer: https://www.youtube.com/watch?v=EUNMrU8uU5M&t=19m50s https://www.youtube.com/watch?v=EUNMrU8uU5M&t=19m50s Vulkan does support multiple command queues. And there can be several queues of the same type for one GPU.