Question about vulkan depency chain, how to interpret Scope1st and Scope2nd int the definition

According to the definition of dependency chain:

• Let Ops1 and Ops2 be separate sets of operations. 
• Let Sync be a synchronization command.
• Let Scope1st and Scope2nd be the synchronization scopes of Sync. 
• Let ScopedOps1 be the intersection of sets Ops1 and Scope1st. 
• Let ScopedOps2 be the intersection of sets Ops2 and Scope2nd. 
• Submitting Ops1, Sync and Ops2 for execution, in that order, will result in execution dependency ExeDep between ScopedOps1 and ScopedOps2. 
• Execution dependency ExeDep guarantees that ScopedOps1 happen-before ScopedOps2. 

An execution dependency chain is a sequence of execution dependencies that form a happens-before
relation between the first dependency’s ScopedOps1 and the final dependency’s ScopedOps2. 
For each consecutive pair of execution dependencies, a chain exists if the intersection of Scope2nd in the first dependency and Scope1st in the second dependency is not an empty set.

My question is: are the Scope1st and Scope2nd somewhat.. “fixed”, or are they “dynamic”?
Here, “fix” means they are determined only by stageMasks. On the other hand, “dynamic” means they depend on how the relevant commands are actually recorded.

To make things more clearly, I’d like to play a simple scenario.

Let’s focus on one specific frame, N. After calling vkAcquireNextImage and successfully obtaining an image IDX and a semaphore R, a signal operation referenced by R is submitted for execution. Let’s abbreviate the signal operation as sig_op.

Let’s say our rendering is pretty simple. The command buffer looks like this:

Begin();
vkBeginRenderPass();
Draw();
vkEndRenderPass();
End();

When this command buffer is submitted to a queue, it forms a batch. Let’s call it bat_N. And bat_N will wait for the semaphore R return from vkAcquireNextImage by specifying the wait stage as Color_Output.

Once the queue is submitted, bat_N will define a dependency D_R, according to semaphore waiting operation:

The first synchronization scope includes all semaphore signal operations that operate on
semaphores waited on in the same batch, and that happen-before the wait completes.
The second synchronization scope includes every command submitted in the same batch. In the
case of vkQueueSubmit, the second synchronization scope is limited to operations on the pipeline
stages determined by the destination stage mask specified by the corresponding element of
pWaitDstStageMask.

D_R ‘s 1st scope should be sig_op, and 2nd scope should be color_op in Draw(); D_R can make sure sig_op happens before color_op, and hence, successfully making color_op waiting for presentation reading. So far, So good.

Now, in order to sync the image layout transition with the image acquired from vkAcquireNextImage, i.e., making the transition happen after the image is finished reading, one should introduce a vkSubpassDependency in which srcStage is set to VK_SUBPASS_EXTERNAL. A typical setting may look like this:

    // Create a dependency to external events.
    // We need to wait for the WSI semaphore to signal.
    // Only pipeline stages which depend on COLOR_ATTACHMENT_OUTPUT_BIT will
    // actually wait for the semaphore, so we must also wait for that pipeline stage.
    VkSubpassDependency dependency = {0};
    dependency.srcSubpass          = VK_SUBPASS_EXTERNAL;
    dependency.dstSubpass          = 0;
    dependency.srcStageMask        = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
    dependency.dstStageMask        = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;

    // Since we changed the image layout, we need to make the memory visible to
    // color attachment to modify.
    dependency.srcAccessMask = 0;
    dependency.dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_READ_BIT |    VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;

Our purpose is to make the layout transition wait for sig_op. It can be achieved by making D_S wait for D_R, and this logically forms a dependency chain.

Now let’s analyze whether the chain can be established according to whether we interpret Scope1st and Scope2nd as “fixed” or “dynamic”.

In our example, it is clear that the first dependency is D_R and the following one is D_S.

If we think of them as the “fixed” way, then the Scope2nd of D_R and Scope1st of D_S both contain the STAGE_COLOR_ATTACHMENT_OUTPUT, the intersection is not empty, so the dependency chain is there.

However, I personally prefer thinking of them as the “dynamic” way, since the definition of dependency in the spec states them as synchronization scope. And according to the description of the synchronization scope in vkSubpassDependency:

If srcSubpass is equal to VK_SUBPASS_EXTERNAL, the first synchronization scope 
includes commands that occur earlier in submission order than the vkCmdBeginRenderPass 
used to begin the render pass instance. Otherwise, the first set of commands 
includes all commands submitted as part of the subpass instance identified by srcSubpass 
and any load, store, or multisample resolve operations on attachments used in srcSubpass. 
In either case, the first synchronization scope is limited to operations on the pipeline stages 
determined by the source stage mask specified by srcStageMask

It gives me the sense that things finally getting into the sync scope are based on the context of the dependency being inserted.
Then In our example under this case, the Scope2nd in D_R should be color_op in bat_N. But for the Scope1st in D_S, there is nothing in bat_N cuz vkBeginRenderPass is the very first command in bat_N, so the intersection should be empty and is not supposed to have a chain here.

If the chain does not exist, does it simply mean D_S can not wait for D_R? Then the synchronization must suck, right?

New contributor

Filed under: Kiến thức lập trình - @ 09:12

Thẻ: vulkan

Thiết kế website giá rẻ

Danh mục

Question about vulkan depency chain, how to interpret Scope1st and Scope2nd int the definition