More synchronization examples in the wiki?

[MangoSister]

I find the synchronization examples in the wiki really helpful for beginners like me, as synchronization is a difficult topic in vulkan, and there aren't so many tutorials/examples in the wild. I wonder if there's any plan to finish the remaining examples in the todo list, such as how to handle resource aliasing. Thank you.

[Tobski]

Hi @MangoSister, I wrote most of those examples - glad you've found them helpful! I'd love to go back and do some more but unfortunately I'm rather more pressed for time these days. I'll talk to some folks internally to see if anyone else is willing to look at writing some examples - are there any particular examples that you'd like to see?

[MangoSister]

Hi @Tobski , Thank you for the reply. Sorry for the late follow-up, right now I do have one particular question: I was wondering whether dependencies are transitive. The spec describes execution dependency chains in 6.1 but even after reading that I wasn't super clear. Here's an example using subpass dependencies, but I guess the same question applies to pipeline barriers / events:

Suppose I have a render pass that includes 3 subpasses, and they all use the same one attachment. The first subpass uses it as a color attachment, the second subpass uses it as an input attachment, and the third pass uses it as a color attachment again. In code maybe something like this:

VkAttachmentDescription attachment= {
    ...
    .loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR,
    .initialLayout = VK_IMAGE_LAYOUT_UNDEFINED,
    .finalLayout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
};

VkAttachmentReference ref1= {
    .attachment = 0,
    .layout     = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL};
}

VkAttachmentReference ref2= {
    .attachment = 0,
    .layout     = VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL};
}

VkSubpassDescription subpasses[3];

subpasses[0] = {
    ...
    .colorAttachmentCount = 1,
    .pColorAttachments= &ref1,
    ...};

subpasses[1] = {
    ...
    .inputAttachmentCount = 1,
    .pInputAttachments= &ref2,
    ...};

subpasses[2] = {
    ...
    .colorAttachmentCount = 1,
    .pColorAttachments= &ref1,
    ...};

VkSubpassDependency  dependencies[2];

// Add a dependency between the first and the second subpass.
dependencies[0]= {
    .srcSubpass = 0,
    .dstSubpass = 1,
    .srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT,
    .dstStageMask = VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT,
    .srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT,
    .dstAccessMask = VK_ACCESS_INPUT_ATTACHMENT_READ_BIT,
    .dependencyFlags = VK_DEPENDENCY_BY_REGION_BIT};

// Add a dependency between the second and the third subpass.
dependencies[1]= {
    .srcSubpass = 1,
    .dstSubpass = 2,
    .srcStageMask = VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT,
    .dstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT,
    .srcAccessMask = VK_ACCESS_INPUT_ATTACHMENT_READ_BIT,
    .dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT,
    .dependencyFlags = VK_DEPENDENCY_BY_REGION_BIT};

// QUESTION: Should I add another dependency between the first and the third subpass?

// Create the render pass
VkRenderPassCreateInfo renderPassCreateInfo = {
    ...
    .attachmentCount = 1,
    .pAttachments = &attachment,
    .subpassCount = 3,
    .pSubpasses = &subpasses
    .dependencyCount = 2,
    .pDependencies = &dependencies};

In this case, should I still need to add another dependency between the first and the third subpass to avoid the potential write-after-write hazard, given that there are dependencies between 1st ->2nd, and 2nd -> 3rd?

In addition, here's another question about the specific paragraph in the examples:

Generally considered more efficient to do a global memory barrier than per-resource barriers, per-resource barriers should usually be used for queue ownership transfers and image layout transitions - otherwise use global barriers.

Could you please elaborate more on it? I failed to find anything in the spec that backs it up. Naively I would think the opposite way because a global barrier means more synchronization work...

Thanks!

[MangoSister]

Actually perhaps I would also like to see an example about using an attachment both as a color and an input attachment (programmable blending?), or both as a depthStencil and an input attachment, in a single subpass. The spec mentions that a subpass self-dependency is needed in this cases, and that I need to also insert barriers, but again I'm not quite sure how that looks like..Thanks!

[Tobski]

Hi @MangoSister, my apologies for the delay here - it's been a somewhat ridiculous few weeks for me and I'm only just now getting back on top of things.

To answer your initial questions:

I was wondering whether dependencies are transitive.

Yes they are.

In this case, should I still need to add another dependency between the first and the third subpass to avoid the potential write-after-write hazard, given that there are dependencies between 1st ->2nd, and 2nd -> 3rd?

No, the dependencies you have are sufficient, as they form an execution dependency chain from 1st -> 3rd.

Could you please elaborate more on it? I failed to find anything in the spec that backs it up.

The reasoning here is that one global memory barrier is easier to handle than several resource barriers. If you have a small number of per-resource barriers it may be more effective to use per-resource barriers, but given that batching barriers is almost universally advisable this is unlikely to occur in practice. As such, the general recommendation is to use global barriers unless PGO (profile guided optimisation) proves otherwise.

[Tobski]

Also: http://themaister.net/blog/2019/08/14/yet-another-blog-explaining-vulkan-synchronization/ gives a great explanation of this stuff, might be worth a read, covers dependency chains fairly well.

[sfricke-samsung]

@MangoSister Thanks for bringing this up, we have thought about this and we think that moving this over to the Vulkan-Guide as an issue there is the right move. We still resolve this issue, but the Vulkan Spec repo is probably not the best place for it. @oddhack should be able to transfer this issue over

[SaschaWillems]

Would it make sense to simply move the sync2 examples from the wiki to a guide page? That would increase visibility by a lot imo, as the wiki is kinda hard to find.

If that's something we want to do, I'd volunteer to do that ;)

[SaschaWillems]

See #251