vsgrendertotexture:Want to konw how to synchronize between two commandbuffers in VSG?

[simwangrui]

HI，
I am learning the vsgrendertotexture example, which uses three methods to achieve 3D scene rendering to textures.We know that RTT textures must be rendered first before they can be applied to subsequent quad geometry. To be precise, RTT textures must be rendered before the fragment shader stage of the quad geometry.

khronos.org say that: "vkQueueSubmit is a queue submission command, with each batch defined by an element of pSubmits. Batches begin execution in the order they appear in pSubmits, but may complete out of order." and "The order that command buffers appear in pCommandBuffers is used to determine submission order, and thus all the implicit ordering guarantees that respect it. Other than these implicit ordering guarantees and any explicit synchronization primitives, these command buffers may overlap or otherwise execute out of order."

For this example, although RTT CommandBuffer and Quad geometry CommandBuffer are submitted in chronological order, it cannot guarantee completion in submission order. This means that RTT textures may have been applied to Quad geometry fragment shaders before rendering is completed.
During the actual running of this example, I did not find any issues.I want to know how VSG synchronizes the order of two CommandBuffers?

For each case, I dump the vulkan API:

1).Single CommandGraph with two RenderGraph using commandline --api: the vulkan api struct as follow:

vkBeginCommandBuffer_0 
vkCmdBeginRenderPass
vkCmdDrawIndexed
vkCmdEndRenderPass 

vkCmdBeginRenderPass
    vkCmdDrawIndexed	
vkCmdEndRenderPass
vkEndCommandBuffer_0

vkQueueSubmit:CommandBuffer_0
vkQueuePresentKHR

2).Two CommandGraphs with owned RenderGraph using commandline --api -s:the vulkan api struct as follow:
vkBeginCommandBuffer_0
vkCmdBeginRenderPass
vkCmdDrawIndexed
vkCmdEndRenderPass
vkEndCommandBuffer_0

vkBeginCommandBuffer_1  
  vkCmdBeginRenderPass 
     vkCmdDrawIndexed	
  vkCmdEndRenderPass  
vkEndCommandBuffer_1

vkQueueSubmit:CommandBuffer_0 CommandBuffer_1

vkQueuePresentKHR

3).Nested CommandGraphs with owned RenderGraph using commandline --api -n:the vulkan api struct as follow:
vkBeginCommandBuffer_0
vkCmdBeginRenderPass
vkCmdDrawIndexed
vkCmdEndRenderPass

vkBeginCommandBuffer_1
  vkCmdBeginRenderPass
  vkCmdDrawIndexed
  vkCmdEndRenderPass 
vkEndCommandBuffer_1
vkEndCommandBuffer_0

vkQueueSubmit:CommandBuffer_0 CommandBuffer_1

vkQueuePresentKHR

[timoore]

The synchronization of the render-to-texture pass and the following passes that use the render is all done with a subpass dependency in the render pass that does the RTT. In particular, these lines:

    // XXX This dependency is copied from the offscreenrender.cpp
    // example. I don't completely understand it, but I think its
    // purpose is to create a barrier if some earlier render pass was
    // using this framebuffer's attachment as a texture.
    dependencies[0].srcSubpass = VK_SUBPASS_EXTERNAL;
    dependencies[0].dstSubpass = 0;
    dependencies[0].srcStageMask = VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT;
    dependencies[0].dstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
    dependencies[0].srcAccessMask = VK_ACCESS_SHADER_READ_BIT;
    dependencies[0].dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;
    dependencies[0].dependencyFlags = VK_DEPENDENCY_BY_REGION_BIT;

    // This is the heart of what makes Vulkan offscreen rendering
    // work: render passes that follow are blocked from using this
    // passes' color attachment in their fragment shaders until all
    // this pass' color writes are finished.
    dependencies[1].srcSubpass = 0;
    dependencies[1].dstSubpass = VK_SUBPASS_EXTERNAL;
    dependencies[1].srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
    dependencies[1].dstStageMask = VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT;
    dependencies[1].srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;
    dependencies[1].dstAccessMask = VK_ACCESS_SHADER_READ_BIT;
    dependencies[1].dependencyFlags = VK_DEPENDENCY_BY_REGION_BIT;

I should correct the first comment at some point because I do now understand the purpose of the first dependency. There is only one copy of the target texture, so the first dependency prevents the RTT from starting before the previous frame has finished using it.

[simwangrui]

HI,
Thanks for your response, it was very helpful to me.I'm trying to understand the impact of the dependencies parameter on synchronization, so I tried modifying the parameter.
Regardless of how I modify the dependencies parameter, the program still runs correctly, even if I change both CommandGraph submitOrders to 0, then place main_commandGraph first and rtt_commandGraph behind it, the program still runs correctly. So I don't know why this is happening?

dependencies[1].srcSubpass = 0;
dependencies[1].dstSubpass = VK_SUBPASS_EXTERNAL;
dependencies[1].srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
dependencies[1].dstStageMask = VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT; //my change
dependencies[1].srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;
dependencies[1].dstAccessMask = VK_ACCESS_SHADER_READ_BIT;
dependencies[1].dependencyFlags = VK_DEPENDENCY_BY_REGION_BIT;

auto rtt_commandGraph = vsg::CommandGraph::create(window);
rtt_commandGraph->submitOrder = 0; //my change
rtt_commandGraph->addChild(rtt_RenderGraph);
auto main_commandGraph = vsg::CommandGraph::create(window);
main_commandGraph->addChild(main_RenderGraph);
viewer->assignRecordAndSubmitTaskAndPresentation({main_commandGraph,rtt_commandGraph});//my change