0

In a Vulkan example the author dstStageMask as VK_PIPELINE_STAGE_BOTTOM_OF_PIPE and the dstAccessMask as VK_ACCESS_MEMORY_READ_BIT. Now, from my previous questions asked here, the access mask flags only apply specifically and explicitly to each stage flag provided (not to all stages logically before. So for example if I have an access mask of memory read for a stage of fragment shader, then that access mask (cache invalidation) doesn't apply to vertex shader or vertex input, rather I would have to specify both those stage flags separately.

It seems to me, in light of this, that having a dstAccessMask of VK_ACCESS_MEMORY_READ_BIT with a dstStageMask of VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT wouldn't do anything, as the access mask doesn't apply to "logically earlier stages", but only the "BOTTOM_OF_PIPE" stage. Here is Sascha Willem's code from the multisampling example:

dependencies[0].srcSubpass = VK_SUBPASS_EXTERNAL;
dependencies[0].dstSubpass = 0;
dependencies[0].srcStageMask = VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT;
dependencies[0].dstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
dependencies[0].srcAccessMask = VK_ACCESS_MEMORY_READ_BIT;
dependencies[0].dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_READ_BIT | 
VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;
dependencies[0].dependencyFlags = VK_DEPENDENCY_BY_REGION_BIT;

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;
dependencies[1].srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_READ_BIT | VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;
dependencies[1].dstAccessMask = VK_ACCESS_MEMORY_READ_BIT;
dependencies[1].dependencyFlags = VK_DEPENDENCY_BY_REGION_BIT;

And here is the part of the spec that says the access mask only applies to the exact stages as given by each flag explicitly, not logically earlier stages:

Including a particular pipeline stage in the first synchronization scope of a command implicitly includes logically earlier pipeline stages in the synchronization scope. Similarly, the second synchronization scope includes logically later pipeline stages.

However, note that access scopes are not affected in this way - only the precise stages specified are considered part of each access scope.

Zebrafish
  • 11,682
  • 3
  • 43
  • 119
  • So, what is this synchronization trying to do? – Nicol Bolas Sep 16 '22 at 14:33
  • @NicolBolas I'm not exactly sure. But I've asked a question or two here clarifying whether it's 100% correct that the access mask applies ONLY to the specific stage flags given, and it indeed it does. Therefore the access masks for top of pipe and bottom of pipe don't do anything and may as well be 0, however he gave seemingly "meaningful" access masks or'd together as if they actually did something. – Zebrafish Sep 16 '22 at 15:42
  • "*I'm not exactly sure.*" You should be able to look at the commands around it, or the text explaining what the example is doing, to figure out what needs synchronization. Also, the access mask here seems to be unimportant next to how bottom-of-the-pipe works. Knowing what it is trying to synchronization access to would be helpful in knowing how wrong the dependency is. – Nicol Bolas Sep 16 '22 at 16:12

1 Answers1

1

VK_PIPELINE_STAGE_NONE (and equivalents) do not have accesses, and the latest practice is to just write 0 (resp. VK_ACCESS_NONE) in the access flag. Early day Vulkan practices were messy, and you will find plenty of unupdated code...

krOoze
  • 12,301
  • 1
  • 20
  • 34