As I said I am trying to understand this issue as tutorials are unclear and conflicting in how they handle it. Most actually completely ignore the issue by their choice of per frame synchronization.
So for a new person learning he API he might not actually remember all of the Vulkan spec details or know exactly how the synchronizations occur inside of Vulkan.
Take something as simple as were to put the fence while drawing:
The vulkan-tutorial.com at https://vulkan-tutorial.com/Drawing_a_triangle/Drawing/Rendering_and_presentation#page_Frames_in_flight
Puts it just before the new frame is started and right before vkAcquireNextImageKHR.
Others put the fence just before they start using the command buffer again, which seems to have the same effect as vulkan-tutorial. (https://developer.samsung.com/game/usage)
However, the lunar examples at https://vulkan.lunarg.com/doc/sdk/22.214.171.124/windows/tutorial/html/15-draw_cube.html
Puts it before vkQueuePresentKHR and it implies that you need to wait for the command buffer before doing a vkQueuePresentKHR.
To my current understanding all of these will work, but “lunars” will be less efficient and its reason for waiting at the chosen point is wrong.
Is that true? (if so its kind of bad that such a high-profile example is wrong).
Now back to my original question and the answer above
If I only have two, I might see your point for my given example.
But what about if I had three or more buffers and allowed for the same number to be ‘inflight’ (this code was meant to be scalable from 1-x frames in flight).
Frame 1 would be presented on screen, frame 2 renders and is queued via vkQueuePresentKHR (as far as I understand the queue does not necessarily present right away, it’s kind of in the name), frame 3 starts to render
I am really trying to understand which call prevents the depth buffer from frame 2 from being overwritten when frame 3 starts (given the queued present of 2 has not been executed yet).
To provide more context I am using code similar to: https://vulkan-tutorial.com/Drawing_a_triangle/Drawing/Rendering_and_presentation#page_Frames_in_flight
This should clear up exactly how the app code I use do synchronization (it could be doing it wrong, I am open to that)
I might have misunderstood something which is why I asked for clarification and multiple people do seem to be confused about it.
I also read The Most Common Vulkan Mistakes" and he mentions “Command queues run independently of each other.”.
So, given my synchronization scheme in the app and the above example.
The result of command buffer 1 is being presented, command buffer 2 has been filled and queued.
Command buffer 3 is being filled and then queued.
Since command buffer 2+3 run independently of each other what would prevent both of them from drawing to the depth buffer at the same time if sharing a depth buffer.
Vulkan tutorial also duplicates its UBO’s for the inflight frames which is what I would expect to be necessary as there are multiple queues possible rendering at the same time.
Again, this leads me back to the original question if a depth buffer can be shared safely why can’t the UBO’s.
Leading me to conclude I am missing something, hence the need for clarification.