What are the Strategies for Command Buffers? What about Threading?

The Vulkan multithreading model means that developers are free to generate command buffers in any thread, but they should be submitted in the main thread. While it may be possible to do it differently, this is normally both the optimal and the desired way, so there is no need to be concerned with cases of submissions for multiple threads.

However, command buffers should be generated in other threads if possible. See the GnomeHorde example for a complete start-to-finish implementation of this scenario.

There are numerous ways that an application can be structured, but some patterns will emerge.

Single command buffer submission, multiple command secondary command buffers

This strategy is a very good starting point and general case. Work is mostly generated in the form of secondary command buffers, and these secondary command buffers are gathered and recorded into a single primary command buffer, which is then submitted. Almost all examples in the PowerVR SDK use this strategy.

Multiple parallel command buffers, submitted once

This strategy means creating several command buffers and submitting them together once. A little additional synchronisation might be needed with the acquire and the presentation engine, but there could be cases where some small gain is realised. However, it is much less common for rendering than would be immediately apparent, as a render pass cannot be split to multiple submissions. This means that it is mostly operations on different render targets, especially from different frames, and compute operations on the same queue that can be split into different command buffers.

In this scenario, all those command buffers would be independent and could be scheduled to start after the presentation engine has prepared the rendering image (backbuffer).The presentation engine would then wait for these to finish before it presents the image. This scenario is applicable if no interdependencies exist between the command buffers, or if the developer synchronises them with semaphores or events. For example, it is possible to render different objects to different targets from different command buffers. It is much more complicated to stream computed data with this strategy.

Multiple parallel command buffers, submitted multiple times

When there is no reason to do otherwise, submitting once is fine. Sometimes it is better to completely separate different command buffers into different submissions, especially if using different queues or even queue families and sometimes if activating different hardware. In general, it is necessary to devise a synchronisation scheme in this case, but usually this will be connected to the basic case described above.