How should I handle Vulkan objects for issuing commands

Okay so, we have queues, we submit command buffers to queues, we record render passes to command buffers, we add subpasses to render passes. Why so complicated. I understand that we can use subpasses to efficiently synchronize our commands, and there are whole queues that we can send to the GPU all at once. But why command buffers and render passes. That's not even all, there are command pools to create your command buffers. Why would I need multiple queues with each multiple command buffers with each multiple render passes with each multiple subpasses.

Command pools are useful for multiple threads. Okay. So I can create my command buffer in my thread, why would I need two. Than why would I need two render passes if I can do everything in subpasses, am I missing something?

To be clear I am making an wrapper or an abstraction around Vulkan for my engine and am trying to grasp these concepts. Maybe this is the real problem, I'm trying to abstract everything without having enough knowledge and doing pure Vulkan projects, but in my mind it's easier to learn this way.

I tried looking for some explanations online but couldn't any ones that satisfy my need.

> Why is issuing commands to GPU so complicated in Vulkan

Issuing commands isn't complicated in Vulkan, it's just plain complicated. The GPU is quite possibly the most complicated component in your computer, possibly only slightly behind the x86 instruction decoder. Vulkan, Metal, and D3D12 weren't an evolution on GPU hardware, they were merely exposing the lower-level functionality that has existed for a while.

> But why command buffers

Command buffers have been a thing for a very long time, probably going back to the very beginning of GPU's, they were just hidden from you. Recording commands are incredibly slow, primarily due to state validation (this is also why pipeline states exist and are precompiled), to alleviate this the modern low-overhead APIs exposed the ability to record command buffers in separate threads. This reduces the CPU bottleneck and allows for better multithreaded rendering.

Command buffers also allow for sub command buffers. This can be useful if you have a set of commands that will be used multiple times, to prevent you from having to spend CPU time re-recording identical commands over and over again. You can also re-use primary command buffers, if you're so inclined.

> That's not even all, there are command pools to create your command buffers.

Part of the low-overhead APIs is giving you more control over memory allocation. By splitting pools up by thread Vulkan doesn't need to have internal synchronization during memory allocations, which is why command pools are externally synchronized (and frankly, you shouldn't be performing any synchronization). You're also advised to have individual pools for each frame in your swapchain, this makes it easier to release memory after it's no longer in use and reduce sharding in your memory pools.

> Why would I need multiple queues

You don't, but you have the option to. The queues serve two purposes. The first is to allow for different queue types to be executed simultaneously. A GPU might be able to execute graphics functions, compute functions, and copy functions in parallel, so Vulkan exposes this. The second is to allow for queue priorities. You can have multiple queues in the same family with different queue priorities allowing you to put low priority activities in a lower priority queue to potentially reduce starving high priority tasks of compute time.

<hr />

If you're making a wrapper around multiple graphics APIs, then your options mostly boil down to exposing the minimal functionality, or the maximal functionality. If you expose the minimal functionality you'd be better off just using OpenGL rather than attempting to effectively beat GPU manufacturers at writing an OpenGL driver.

Going the other direction, offering the maximum functionality, will require emulating a lot of functionality, with few benefits. You can implement command buffer wrapper in OpenGL, but you won't actually gain any of the parallel state validation benefits. Queues would also be exclusively implemented in user mode, rather than at the kernel mode and within the GPU.