Should one minimize the number of command pools an application creates?

Question

Say that there is a queue family which supports presentation to a surface, and graphics. Is it better (due to technical reasons) to create a single command pool which handles presentation and graphics, or is it better to create two command pools: one the application will use only for graphics (even though it could use it for presentation) and another the application will use only for presentation (even though it could use it for graphics)?

Essentially, should one minimize the number of command pools associated with a particular queue family? Or is it okay to create as many command pools as one desires? More generally (regardless of which queue family the command pools are associated with), should an application minimize how many command pools it creates?

EDIT: I wrote "queues" instead of "command pools" in the initial version of this post. This has been fixed.

Answer 1

The main purpose of a command pool is to be a (mostly) single-threaded allocator for the storage used by a set of command buffers which are filled by that thread. You create pools to serve that purpose.

So if you have three threads that need to generate commands for a particular queue, then you create 3 pools, one for each such thread, and use them to generate the CBs you are interested in.

And depending on your CB resetting strategy, you may want to multi-buffer pools. That is, while a thread is generating commands into CBs from pool A, the GPU is reading from CBs from pool B. That way, when the GPU is done, you can just reset the pool rather than resetting the individual CBs.

The overall point is that you create command pools to serve your application's allocation and CB-building strategy. The association of a pool with a queue family is there solely to help the implementation generate commands for those CBs more efficiently. You should not assume that a pool is consuming some kind of limited resource from the queue.