Reading the specification I have a misunderstanding: “If vkCmdPipelineBarrier was recorded inside a render pass instance, the first synchronisation scope includes only commands that occur earlier in submission order within the same subpass”. Suppose we want to draw something after dispatch and we use a pipeline barrier for synchronisation, is the dispatch command considered to be within that subpass? Also with transfer commands.
The point of the statement is that using a pipeline barrier in a subpass only works within the subpass it is within. If something in a subpass needs to synchronize with external stuff, then it needs to use an external subpass dependency.
For example, to “draw something after dispatch” requires that you began a render pass “after dispatch”. That render pass should include appropriate subpass dependencies for communicating with stuff outside of the subpass.
1 Like
Thank you.
What should I do in case, for example, I want to synchronize access to only one buffer in a draw command, rather than making all draw commands wait in that subpass? Before reading this part of the spec I thought I could use a pipeline barrier by creating a VkBufferMemoryBarrier, but now other than creating multiple subpasses nothing comes to mind.
Also, as far as I know, only the draw command works with subpass, and they don’t need to be synchronized, so the question arises: what can be synchronized in a subpass instance?
What do you mean by that? What kind of “access” are you synchronizing?
Earlier, you mentioned “dispatch”, so presumably you’re talking about synchronizing a compute shader operation with a rendering operation. That’s a subpass external dependency.
And what exactly will it matter if a few rendering operations that don’t use the buffer will have to wait? This will represent very little actual time, as the GPU will still be mostly filling its compute cores with the compute shader itself.
Within a subpass?
Subpass self-dependencies (which is what a pipeline barrier in a subpass must be) are primarily for dealing with attachment data. That is, you wrote some data to a color attachment, and you want to read that data (and potentially write more) from the same pixel of that image. You use a subpass self-dependency and a pipeline barrier to make the first write available and visible to the later access.
1 Like
Could you give an example to the second question?
If you’re asking why you would want to read from the pixel that a previous rendering command wrote to… that’s what blending is: a read/modify/write operation. So you would use a self-dependency if you want blending operations that are more complex than the simplistic blend functions provided by the standard system.
1 Like
You can’t have compute inside Render Pass without something like VK_HUAWEI_subpass_shading extension. Even so, I don’t think it permits mixing graphics and compute within the same single subapass, so vkCmdPipelineBarrier is not relevant here.
Equally, copy commands can’t be recorded inside Render Pass scope.
1 Like