Results 1 to 4 of 4

Thread: Can't figure out renderpass dependencies

  1. #1
    Junior Member
    Join Date
    Sep 2017
    Posts
    5

    Can't figure out renderpass dependencies

    Hey, I have been researching render-pass dependencies passively for a week or two now and I still can't figure out how they work.

    I have a very simple situation I want to work out to help me understand dependencies and render passes.

    Basically I have a scene, I want to render it to an offscreen texture, then I want to use this texture as an input attachment and perform a post processing effect on, then render it to screen.

    However I get terribly confused in regards to what stage/access masks to use. And would be extremely grateful if someone could explain it to me, or refer to a post/website which explains this in depth.
    The Vulkan specification confuses me even more, most code I find is not commented, so I really hope someone can help me out.

  2. #2
    Basically I have a scene, I want to render it to an offscreen texture, then I want to use this texture as an input attachment and perform a post processing effect on, then render it to screen.
    OK from this point forward, I'm going to assume that this "post processing effect" does not require having the FS read more than one texel from the image. Because if it does, you have to break the render pass to do that, and therefore renderpass dependencies don't really matter anymore.

    So you have two subpasses: one which uses the image as a color attachment, and one which uses the image as an input attachment. So you create a subpass dependency between the two dependencies.

    I don't really see what's difficult about this. `VkSubpassDependency` only has 7 parameters:

    `srcSubpass` and `dstSubpass` define which two subpasses the dependency is between. The `*StageMask` and `*AccessMask` parameters mean exactly what they mean for any other dependency: the stages that produce/consume the data, and the methods of access that produce/consume the data. Since you're writing to a color attachment, the `srcStageMask` is `VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT`. And since you're reading it in the fragment shader, the `dstStageMask` is `VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT`. Since the data is being written to a color attachment, the `srcAccessMask` should be `VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT`. And since the data is being read as an input attachment, the `dstAccessMask` should be `VK_ACCESS_INPUT_ATTACHMENT_READ_BIT`.

    Very simple.

    The `dependencyFlags` should be `VK_DEPENDENCY_BY_REGION_BIT`, since you're creating a dependency between two "framebuffer-space" pipeline stages (color attachment output and fragment shader).

  3. #3
    Junior Member
    Join Date
    Sep 2017
    Posts
    5
    Really thanks a lot! To me this explanation makes more sense than anything I have read so far, very easy indeed. In regards to having two renderpasses, do I need to create a dependency which the access mask at least match from one render pass to the other as well?
    Last edited by Mercesa; 10-12-2017 at 11:46 AM.

  4. #4
    Senior Member
    Join Date
    Mar 2016
    Posts
    227
    Quote Originally Posted by Mercesa View Post
    In regards to having two renderpasses, do I need to create a dependency which the access mask at least match from one render pass to the other as well?
    In Vulkan queue you need to synchronize anything with everything.
    That is if one of your rendepasses writes a resource (i.e. Image or a Buffer) and the other renderpass reads or writes the same resource, then you do need to add a dependency between them.

    I am not sure what you mean by "access mask match from renderpass to renderpass".
    What you would have is one barrier operation (whether it is a VkSubpassDependency or a vkCmdPipelineBarrier) That has in srcStage the pipeline stage which corresponds to where you did last use the common resource in the first renderpass, and it has in dstStage where the first use of the common resource by the second renderpass is gonna be.

    (Alternativelly it could be spread into two barrier operations, which each can perform only half of the dependency. But let's not complicate things while you are learning...)

    And access masks are simple. They are mostly what the Table 4. Supported access types table says. Usually there's a 1:1 match with the stage masks used, only difference being whether it is *_READ or *_WRITE.
    Last edited by krOoze; 10-13-2017 at 05:22 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean