Results 1 to 5 of 5

Thread: Pipeline Barriers

  1. #1
    Junior Member
    Join Date
    Dec 2016
    Location
    France
    Posts
    12

    Pipeline Barriers

    Hi,
    I have a problem to understand some parameters of the VkCmdPipelineBarrier.
    What is the meaning of "srcStageMask" and "dstStageMask"? Source/destination of what? The terms source and destination are a bit confusing for me since (I think) they are no "transfer operation".
    Same for VkImageMemoryBarrier. What is the meaning of "srcAccessMask" and "dstAccessMask" ?

    Thanks!

  2. #2
    Senior Member
    Join Date
    Mar 2016
    Posts
    294
    It works under the assumption that you want to get something somewhere. But it could have as well been prev\next or before\after.

    Let's just say you made an image by op1 (source) and you need that image later in op2 (destination). There sorta is a "transfer" there. Firstly (by bit of a 4D thinking) you do have to make sure the image is not at "destination" before the "source" can create it (i.e. Execution Dependency through *StageMask). Secondly (where the sorta-transfer happens) it has to bubble down from the cache hierarchy to general purpose memory, and potentially transfered to special-purpose memory or cache the op2 is able to use (i.e. Memory Dependency through use of the ED + *AccessMask).
    Last edited by krOoze; 04-24-2018 at 05:20 AM.

  3. #3
    Senior Member
    Join Date
    Mar 2016
    Posts
    294
    PS: I think it really pays of to read the spec on this. It is about one page (but you potentially have to read it like 50x before you understand). It is really important to get this theory right, and it is one of the few concepts in Vulkan where you cannot just wing it (at least if and until Validation Layers can catch this solidly and give useful messages).
    Last edited by krOoze; 04-24-2018 at 05:36 AM.

  4. #4
    Junior Member
    Join Date
    Dec 2016
    Location
    France
    Posts
    12
    I think I got it now. So just to be sure: src/dst-stageMask refers to which stage the image currently is and to which stage it should move. src/dst-AccesMask refers to the memory bind to the image. Form which type of memory "layout" it currently is, to which type it should be. Just like image layout. Am I right?

    If so, I thought that those stages where unidirectional: from VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT to VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT. According to the spec, there are other stages than the graphics one. Especially the transfer ones. So how do they insert themselves into the graphics pipeline? (hope I'm clear enough)
    Thanks.

  5. #5
    Senior Member
    Join Date
    Mar 2016
    Posts
    294
    I find your description potentially misleading.

    There's not necessarily any "move" there. It is "source" because that stage of some command produces some data to the image\buffer the "destination" will later need.

    The Execution dependency of the pipeline barrier is making sure the "source" stage (and any logically earlier stage) of any previously recorded command is executed before the "destination" stage (and any logically later stage) of any subsequently recorded command. Otherwise the data written by "source" does not necessarily exist yet when the "destination" needs it, because the "source" was not executed yet.

    The raw Execution dependency does not cover Memory dependecies though. It is tricky, because we are not exposed to Memory dependecies in high-level programming languages, so it feels foreign. There is many underlying reasons to potentially need a Memory dependecy, but lets think of it in terms of a Cache hierarchy. The srcAccessMask makes sure the needed data is flushed from the source. The dstAccessMask makes sure the necessary data is invalidated for the destination.




    As for the pipelines, there are several types of them:


    For the graphics pipeline, the following stages occur in this order:

    VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT

    VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT

    VK_PIPELINE_STAGE_VERTEX_INPUT_BIT

    VK_PIPELINE_STAGE_VERTEX_SHADER_BIT

    VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT

    VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_B IT

    VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT

    VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT

    VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT

    VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT

    VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT

    VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT

    For the compute pipeline, the following stages occur in this order:

    VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT

    VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT

    VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT

    VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT

    For the transfer pipeline, the following stages occur in this order:

    VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT

    VK_PIPELINE_STAGE_TRANSFER_BIT

    VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT

    For host operations, only one pipeline stage occurs, so no order is guaranteed:

    VK_PIPELINE_STAGE_HOST_BIT
    As you can see the transfer is different pipeline than the graphics. So they do not "insert themself" in any way.
    Last edited by krOoze; 04-26-2018 at 07:05 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