Correct subpass dependency understanding - c++

Question

So, I am trying to understand Vulkan synchronization and subpass dependencies (heh)
I am following this doc here: https://github.com/KhronosGroup/Vulkan-Docs/wiki/Synchronization-Examples#swapchain-image-acquire-and-present
As I understand that's the most up to date?
Specifically trying to understand why the "Combined Graphics/Present Queue" subpass dependencies do what they do.
I found this awesome gist that explained it better than anything else I found: https://gist.github.com/chrisvarns/b4a5dbd1a09545948261d8c650070383
So using that gists style I tried to fill in what the steps on the second subpass mean.
Can anyone validate if the line by line comments of each parameter are correctly describing what it is doing?
VkSubpassDependency dependencies[2] = {
{
// https://gist.github.com/chrisvarns/b4a5dbd1a09545948261d8c650070383
// In subpass zero...
.dstSubpass = 0,
// ... at this pipeline stage ...
.dstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT,
// ... wait before performing these operations ...
.dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT,
// ... until all operations of that type stop ...
.srcAccessMask = VK_ACCESS_NONE_KHR,
// ... at that same stages ...
.srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT,
// ... occuring in submission order prior to vkCmdBeginRenderPass ...
.srcSubpass = VK_SUBPASS_EXTERNAL,
// ... have completed execution.
.dependencyFlags = 0,
},
{
// ... In the external scope after the subpass ...
.dstSubpass = VK_SUBPASS_EXTERNAL,
// ... before anything can occur with this pipeline stage ...
.dstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT,
// ... wait for all operations to stop ...
.dstAccessMask = VK_ACCESS_NONE_KHR,
// ... of this type ...
.srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT,
// ... at this stage ...
.srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT,
// ... in subpass 0 ...
.srcSubpass = 0,
// ... before it can execute and signal the semaphore rendering complete semaphore
// set to VK_PIPELINE_STAGE_2_COLOR_ATTACHMENT_OUTPUT_BIT_KHR on vkQueueSubmit2KHR.
},
};

Answer 1

The first dependency says subpass 0 can't start fragment output until previous commands in the stream (before the start of the render pass) have completed their fragment output.
The second dependency says no external (i.e. the next render pass) can start its color attachment output until subpass 0 has completed it's attachment output.
The semaphore on the submit gets signalled when the submitted command buffer is complete (vkQueueSubmit()) or at least past the selected stages (vkQueueSubmit2() with a stageMask). You do need to make sure the frame is rendered before you notify the window system that it is available. Waiting for fragment attachment output is necessary somewhere. This could be enforced inside the submitted commands, or just using the semaphore itself.
Wouldn't the renderingCompleteSemaphore on the presentQueue provide all necessary memory separation and waiting?
For the purposes of the swapchain signalling, yes. But it doesn't provide any guarantee that the graphics workload submits complete in order.
Vulkan commands are specified to start in command queue submission order, but can complete out of order. The dependencies in the main rendering command buffer ensure that the submits retire in-order, which is the desired behavior for frames.