Ultimately, I do not think there are any general answers to these questions as of yet. There are too many ways to structure static vs. dynamic command buffers, and far too little knowledge about how these things get implemented to know for certain.
However, it should be noted that command buffer building is intended to be:
-
Cheap (relatively speaking, particularly relative to OpenGL)
-
Threaded. Or at least, separate command buffers can be built simultaneously.
That is, IHVs would not be surprised to see applications that use dynamic command buffers exclusively.
How much effort should you go through to create static command buffers? Could a static primary command buffer with dynamic secondary command buffers be more efficient than submitting that same number of dynamic primary command buffers? What is the cost of submitting a command buffer at all? After all, if you have static command buffers, that generally means having to submit them more than once?
It’s hard to know for sure. But given that each command buffer has its own pipeline state vector, it stands to reason that having a command buffer per-object is probably not a good idea. Such a thing would involve lots of state changes for state that probably isn’t changing, so even doing this for secondary command buffers is probably not going to work well. If you can group lots of objects into a static command buffer, that might help. But then again, it might not.
About memory management, if I understand well, a good way should to use several big memory pool (maybe 32 or 64 mio) and use one for images, another one for vertex, another one for “buffer like SSBO” etc? Am I right?
You should organize your memory allocations based on the organization of your data, not based on some arbitrary division like you suggest here. There is nothing special about buffers or textures; they’re just memory, and you lose nothing by putting them in the same pool of memory (unless you have special needs like mapping and so forth).
If you’re streaming world geometry, then you should have blocks (which could be distinct sections of the same memory allocation) that represent streaming segments. These blocks could contain textures, buffers used for vertex data, buffers for uniforms, etc, all as defined by the needs of that section of world geometry. There’s no reason to try to put such data into different memory allocations just because some of it is intended to be an SSBO and some is intended to be an image.
This has nothing to do with performance per-se; it’s more about reasonable data organization. All your GUI data can go into one allocation, whether that data is a UBO, vertex data, or textures. And so forth.
Remember: the reason Vulkan gives you low-level control is so that you can use that control.