Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Synchronize a vkCmdBlitImage before the render pass

  1. #11
    Senior Member Regular Contributor
    Join Date
    Mar 2016
    Posts
    351
    Quote Originally Posted by Ealrann View Post
    Then, two new barrier, to prepare back the srcImage for a new frame, latter (srcImage will not be used anymore in the current frame).
    And another barrier to prepare the swapchain image to the vkCmdDrawIndexed:
    From:
    VK_PIPELINE_STAGE_TRANSFER_BIT, VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL, VK_ACCESS_TRANSFER_WRITE_BIT
    To :
    VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_ACCESS_SHADER_WRITE_BIT
    This seems insufficient to prepare the srcImage for next frame. Either there must be a Semaphore between them, or the dst should also include VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT and VK_ACCESS_SHADER_WRITE_BIT.

    Also how\where do you clear the [VAR]srcImage[VAR]?
    Last edited by krOoze; 01-15-2019 at 06:45 AM.

  2. #12
    Junior Member Newbie
    Join Date
    Jan 2019
    Posts
    6
    Quote Originally Posted by krOoze View Post
    Put a vkDeviceWaitIdle after the frame.

    Actually put vkDeviceWaitIdle and HC barrier everywhere possible. You make a HC barrier with srcStage = dstStage = ALL_COMMANDS, with VkMemoryBarrier of srcAccessMask = dstAccessMask = VK_ACCESS_MEMORY_READ_BIT | VK_ACCESS_MEMORY_WRITE_BIT.
    That should rule out synchronization errors.
    I really tried to put synchronisations everywhere, waitIdle, Fences.. But nothing change about the blink. If I make a bad configuration, the layers print the error.

    Quote Originally Posted by krOoze View Post
    Should be VK_ACCESS_SHADER_WRITE_BIT instead.
    This is weird. The layers should be able to catch this. Which SDK version do you have?
    Bad CC again, yeah the layers catch that kind of error. Indeed, it's VK_ACCESS_SHADER_WRITE_BIT.

    Quote Originally Posted by krOoze View Post
    This seems insufficient to prepare the srcImage for next frame. Either there must be a Semaphore between them, or the dst should also include VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT and VK_ACCESS_SHADER_WRITE_BIT.
    I didn't spoke about the srcImage, because I thought it could not be a problem, here the transition of srcImage I make after the blit:
    From:
    VK_PIPELINE_STAGE_TRANSFER_BIT, VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL, VK_ACCESS_TRANSFER_READ_BIT
    To:
    VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT, VK_IMAGE_LAYOUT_GENERAL, 0

    Quote Originally Posted by krOoze View Post
    Also how\where do you clear the [VAR]srcImage[VAR]?
    Ok, I sum up the full process :

    Code :
    1) Compute execution
    Some compute shaders build srcImage. It's a bit complex, but the image is fully written at the end of this execution (and overwritten).
     
    Between the two executions, I tried to put every Fence, WaitIdle, Barrier possible. Change nothing, the blink still appears.
    But if I put a huge manual sleep, like 200ms, the blink disappear. (for info, the compute execution produce easily srcImage at 120fps on this laptop (however I use Fifo mode, 60 Fps)).
     
    2) Graphic
    Barriers to prepare srcImage and the swapchain image.
    blit srcImage into swapchain image.
    Barriers again, as we saw before.
    (from here, srcImage is not used anymore)
    start render
    drawIndex for the UI.
    end render

    There is nothing shared between the compute execution and the graphic one, except the srcImage. I don't see how the compute could impact the graphic but ... maybe ?
    The srcImage really looks good, and is rendered perfectly on the screen, so the blit works great at least.

    The command buffers are recorded only one time for the test. The blink is random, and "seems" to depend on the load of the compute execution.

    This architecture seems not too complicated. I don't understand why the UI only is not draw sometime.

  3. #13
    Senior Member Regular Contributor
    Join Date
    Mar 2016
    Posts
    351
    Quote Originally Posted by Ealrann View Post
    I didn't spoke about the srcImage, because I thought it could not be a problem, here the transition of srcImage I make after the blit:
    From:
    VK_PIPELINE_STAGE_TRANSFER_BIT, VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL, VK_ACCESS_TRANSFER_READ_BIT
    To:
    VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT, VK_IMAGE_LAYOUT_GENERAL, 0

    Well, anything can be the problem. Mis-synchronization is undefined behavior too. That means it can pretend to work fine, or it can rip the fabric of space and time as we know it, or anything in between.


    You are reusing the srcImage from previous frame. How are you making sure the previous frame does not still read the srcImage while next frame already wants to overwrite it? dst=VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT means no sync. That only makes sense if there is a Semaphore or Fence between the two frames; is there one?


    HmMmMm, maybe make a VK_LAYER_LUNARG_api_dump of the first two frames. That should eliminate copy-paste errors and your abstractions.

  4. #14
    Junior Member Newbie
    Join Date
    Jan 2019
    Posts
    6
    Quote Originally Posted by krOoze View Post
    You are reusing the srcImage from previous frame. How are you making sure the previous frame does not still read the srcImage while next frame already wants to overwrite it? dst=VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT means no sync. That only makes sense if there is a Semaphore or Fence between the two frames; is there one?
    I tried to put Fence and WaitIdle. No change.
    Quote Originally Posted by krOoze View Post
    HmMmMm, maybe make a VK_LAYER_LUNARG_api_dump of the first two frames. That should eliminate copy-paste errors and your abstractions.
    Haha, thank you, I didn't knew API dump layer. Yeah, it will be more reliable... Thank you very much for your help :').
    The first dump I made was 10000 lines... So I removed as many stuff as I can (while keeping the bug alive) in my application (mainly a big piece of computation, and a part of the UI), the new dump is half size. Here the pastebin:
    https://pastebin.com/0nwFZujj
    By the way, I made a new release yesterday, if you are curious to see what we are talking about, here the link:
    https://github.com/Ealrann/VSand/rel...17_SAND_V1.1.0
    Again, thank you very much for your help ...

  5. #15
    Senior Member Regular Contributor
    Join Date
    Mar 2016
    Posts
    351
    OK, your Semaphores seem wrong.


    You take a signal-pending semaphore from vkAcquireNextImageKHR and on vkQueueSubmit you wait on it in pWaitDstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT. But your first use of the swapchain image is the layout transition barrier to TRANSFER_DST_OPTIMAL, which has srcStage = COMPUTE.


    You also take a signal-pending semaphore from the Compute cmdbuffer submission, but again wait on it in pWaitDstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, while first use is again a barrier from srcStage = COMPUTE.


    And your compute seems mis-synchronized too. Last use of the compute image seems to be the barrier


    Code :
    TRANSFER => BOTTOM
    TRANSFER_READ => 0
    TRANSFER_SRC_OPTIMAL => GENERAL


    And first use in the compute again a barrier:


    Code :
    TOP => COMPUTE
    0 => SHADER_WRITE
    UNDEFINED => GENERAL


    And there seems to be nothing in between (no Semaphore waits).
    Firstly one of the barriers is pointless, if you just then transition from UNDEFINED layout. Not to mention you transition to GENERAL twice.
    Secondly there must either be a Semaphore wait, OR it cannot be srcStage=TOP_OF_PIPE.

Page 2 of 2 FirstFirst 12

Similar Threads

  1. Render pass dependencies issue
    By ech2810 in forum Vulkan
    Replies: 6
    Last Post: 03-31-2017, 06:57 AM
  2. Render pass dependencies and conditional execution
    By Julian Edgar in forum Vulkan
    Replies: 8
    Last Post: 03-27-2016, 07:45 PM
  3. Render to texture without vkCmdBlitImage.
    By Ronniko in forum Vulkan
    Replies: 4
    Last Post: 03-22-2016, 09:47 PM
  4. Single-pass render to cubemap
    By dv in forum OpenGL: Advanced Coding
    Replies: 6
    Last Post: 05-03-2008, 01:06 AM
  5. problem about the multi-pass Render-To-Texture
    By foollove in forum OpenGL: Advanced Coding
    Replies: 2
    Last Post: 02-14-2004, 03:24 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