commandPool assignation

Hi,

I’m quite new to Vukan dev, but I have a bunch of XP on DirectX12.

The two approach of command allocation seems very similar, by having one object handle for recording, submission etc… (VkCommandBuffer/d3d command list) and another one used to kind-of manage the allocations (VkCommandPool/d3d command allocator).

Thought, I can’t find a way to assign a new pool to a VkCommandBuffer after its execution ended when we reset it, except than destroying it and creating a new one.
With d3d12 we can do such re-assignation, so we can have on allocator per worker thread, and the command buffers could be used by any other thread from frames to frames by being reset with the according new allocator.
Am I missing something with Vulkan in order to do something similar ?

Without this mechanism, I don’t understand the purpose of having a separated pool object, I would have to ensure a command buffer is always used by the same worker from frame to frame to ensure thread safeness with the pool.

Maybe you can give me more clues on that ?
Thanks.

Thought, I can’t find a way to assign a new pool to a VkCommandBuffer after its execution ended when we reset it, except than destroying it and creating a new one.

You don’t. Several of the useful properties of a command buffer (what kind of queues it runs on, whether the CB is transient) are derived from the command pool; they’re not specifically a part of the buffer. So you can’t just take a CB and assign it to a different pool.

With d3d12 we can do such re-assignation, so we can have on allocator per worker thread, and the command buffers could be used by any other thread from frames to frames by being reset with the according new allocator.

How does a CB get from one thread to another without some form of inter-thread synchronization? It makes much more sense to me for each thread to have its own pools and command buffers.

What do you gain by sharing CBs between threads?

I don’t understand the purpose of having a separated pool object

The point of having a separate pool object is to:

  1. Ensure that CB operations don’t have to synchronize accesses across threads. Without pools, all CBs would have to allocate memory from a global allocator, thus requiring some form of global mutex. That’s bad.

  2. Allow a group of CB’s to be reset at the same time.

Command buffers and command lists have slightly different semantics.

This means a command list handle is essentially a bunch of pointers that doesn’t hold (exclusive?) ownership over memory, while command buffers retain memory they acquire after reset. This can be API hinting you to create a pool per Vulkan-related job, rather than per thread, I guess?

Thank you for those additional information.