Hi,
I an new with vulkan. I just finished the hello triangle. I got some theoretical questions:
should I create a frame buffer per pipeline or some a framebuffer for some pipelines which are similar some how?
I guess the answer to the question 1 will be applied to RenderPass.
I saw somewere that it is better to have a command buffer per thread, my quesiton here is what about command pools? can I have only one pool or should I associate a pool to a buffer therfore one pool per thread?
Here is what I think I understool, please feel free to correct me if I am wrong:
if the resulting image are following the same process then I should have one FrameBuffer for all similar pipelines
if a set of pipelines have the same number and identical passes, then I think they should share the same VkRenderPass *.
here I have no Idea of what I am about to do, I randomly decide 1 to 1 to 1. (one buffer per pool per thread).
These are cases where reading through the specification is probably the best way to clear up such questions. It tells you what these objects mean and how you can use them.
For example, the specification is very clear that accesses to a specific command pool object (including any vkCmd* calls on any of the command buffers that the pool creates) are required to be “externally synchronized”. That means you can’t call them from multiple threads.
So if you have a command pool, and you want to create a command buffer from that pool on two different threads, you have to lock access to it with a mutex. Indeed, you’ll have to lock every vkCmd* call with a mutex.
As such, there’s no point in trying to share command pools across threads. Each thread therefore should have its own command pool, from which it will allocate one or more of its own command buffers.
Similarly, the relationships between renderpasses, pipelines, and VkFramebuffer objects is pretty well defined by the standard. When you need which and for what purposes is detailed.
Ok, thank you for your answer, I will have a read. I guess you are talking about Vulkan® 1.x.yyy - A Specification - Khronos Group , If not can you please point me to the correct documentation.
Thank again