I am following Overvoordes tutorial. When he adds a depth attachment to the rendering he changes the subpass dependency to:
.srcSubpass = VK_SUBPASS_EXTERNAL;
.dstSubpass = 0;
.srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT | VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT;
.srcAccessMask = 0; // 0 here implies that the image must already be available, as after waiting for the semaphore, or that we don't care about flushing the resource to L2. I think.
.dstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT | VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT;
.dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT | VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT;
Overvoorde says: The [depth stencil] reading happens in the VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT stage and the writing in the VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT.
My question is: What happens to the writes in the late frag test, from the earlier subpass, which can here happen after the depth attachment layout transition? Aren't we transitioning/reading the depth attachment before the previous pass is done writing to it.
If the srcAccessMask = 0 then what makes the writes be available before the transition/loadOp?
This seems wrong to me. I think we do need a depth dependency with srcStageMask = VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT and srcAccessMask = VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT to ensure that all writes to the depth attachment are available before the next early frag test.
Edit 1
A response to Nicol Bolas Answer.
I think you missed that the srcStageMask = VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT instead of the late frag test stage.
Apart from that. I am a noob so questioning someone with 423000 reputation is somewhat ridiculous. But I have tried to find support in the specs for your claim that:
The stage mask makes writes available; the access mask makes writes visible.
To be fair, confirmation bias probably made me look for support that my preconceived notion was correct instead :) I found this here:
A memory dependency is an execution dependency which includes availability and visibility operations such that:
The first set of operations happens-before the availability operation.
The availability operation happens-before the visibility operation.
The visibility operation happens-before the second set of operations.
Once written values are made visible to a particular type of memory access, they can be read or written by that type of memory access. Most synchronization commands in Vulkan define a memory dependency.
The specific memory accesses that are made available and visible are defined by the access scopes of a memory dependency. Any type of access that is in a memory dependency’s first access scope and occurs in ScopedOps1 is made available. Any type of access that is in a memory dependency’s second access scope and occurs in ScopedOps2 has any available writes made visible to it. Any type of operation that is not in a synchronization command’s access scopes will not be included in the resulting dependency.
Which I interpret as being congruent with what I believe: That the srcAccessScope determines availability and the dstAccessScope determines visibility.
It makes no sense to me to have the src access determine visibility.
Regarding the load op I can only find this:
loadOp and stencilLoadOp define the load operations that execute as part of the first subpass that uses the attachment.
If an attachment is not used by any subpass, loadOp, storeOp, stencilStoreOp, and stencilLoadOp will be ignored for that attachment, and no load or store ops will be performed. However, any transition specified by initialLayout and finalLayout will still be executed.
Together with your specs quote about layout transitions I conclude that if the loadOp requires visibility, then that requirement would be satisfied by a read bit in the dstAccessScope. But my guess is that, just like for layout transitions, available memory is automatically made visible to a loadOp. But I cannot find anything in the specs to either confirm or refute that.
I am grateful for your answer but cannot accept it with less than you referencing specs to support it, or otherwise change my mind.