Reason for using only a single offscreen FB?

[donguklim]

It seems the only thing that sychronizes drawing on offscreen FB is the render pass for the offscreen FB.
I am new to Vulkan, so maybe I am missing something, but is my thought right?
Or is the offscreen FB sychronized with some other method or is not synchronized at all?

It seems the fences, and semaphores used in prepareFrame method and submitFrame method can only synchronize swap chain FBs.

If what I am thinking is right, wouldn this cause bottleneck in the rendering process?
Also, wouldn't this make using multiple swap chain FB meaningless? (Because rendering commands on all swap chain FBs have to wait for the rendering commands on the offscreen FB.)

Would it be better to use multiple offscreen FBs?

[donguklim]

I have done some research and found the answer.

Basically, you only make data per swapchain frame if the data is read or written by CPU.
Such data are the swapchain frame buffer itself, which is read by CPU when it is uploaded to the monitor, or constant buffers that contain cpu updated data such as view/projection matrix.

You need to keep maintaining those data per frame because the data is being copied to GPU for redering each frame.

GPU only read/write data need not to be made for each frame, because the rendering command in one queue is executed in order.

Making multiple offscreen FB will be meaningless, because while previous frame is being rendered to the offscreen FB, the commands for next frame will be wating in the queue.

This is also the same for depth/stencil buffer, and the reason why there is only one depth/stencil buffer in most applications.

Some GPU hardware may have multiple queue, and in this case more than one frame could be rendered concurrently,
but there would be not much gain on performance by making the GPU only read/write data for each frame.
In this case, you may make the GPU only read/write data per frame only for avoiding race condition,
but it would be better to use synchronization objects such as semaphore and barrier and only using one data for all frames.

Also, it seems most of the hardware just executes rendering commands in order without using multiple queue.
So the code will run fine in most of the GPUs even if there is no subpass dependency that prevents the race condition on offscreen FB buffer.

https://stackoverflow.com/questions/62371266/why-is-a-single-depth-buffer-sufficient-for-this-vulkan-swapchain-render-loop

According to above stack overflow page, the vulkan tutorial(https://vulkan-tutorial.com/) did not prevent race condition on depth buffer(the code is fixed now), but the actual code had been running fine without any problem.

[akeley98]

Thanks for this write up. Now that I'm back from the holidays, I have some things to add,

1. With regards to rendering frames concurrently, generally this is not a goal for GPU optimization, because the parallelism leveraged is from the massive amounts of pixels shaded per frame, i.e. we parallelize the millions of pixels or rays being generated per frame, but keep each frame's execution time separate.
2. For the issue of synchronizing rendering commands, within a single subpass instance, everything proceeds in rasterization order i.e. all render pass clears, attachment clears, and primitives are drawn as-if they were drawn in order (excluding shader side effects) even with no explicit synchronization at all. It's possible the subpass dependencies we have set up (needed for synchronization between render pass instances, e.g. between different frames) might not be by-the-book correct but that seems to be a non-issue on all implementations. More serious issue is that ray tracing is actually a compute command, not inside a render pass, so none of this actually applies and it's possible there's a subtle compute/graphics synchronization bug here, not sure myself one way or the other.