When recording a vkCmdPipelineBarrier, what is the effect of specifying a stage in dstStageMask which is logically earlier than a stage in srcStageMask?
As an extreme example:
src = VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT
dst = VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT
This is allowed, right? At least i couldn’t find anything in the spec so far that would forbid this…
Does this imply a “next run through the pipeline”, or rather a restart of the pipeline (i can’t see how anything should be able to execute in the remaining stages, as dstStageMask includes logically later stages…) ?
If so, then is this a commonly done thing? I would expect the gpu to be able to traverse through stages in which nothing can execute without wasting too much time?!
You have the wrong intuition about pipeline. Pipeline is not something you find in some specific stage at some specific time. It just is, and commands flow through the pipeline like water flows throught a hose.
srcStageMask and dstStageMask parameters are unrelated, and they have no restriction between themselves (well, with one small exception of subpass self-dependency).
vkCmdPipelineBarrier separates commands into two groups; those that are recorded before it, and those that are recorded after it.
The barrier makes sure that all commands in the first group gone past srcStage in the “hose”, before any of the commands in the second group even reach dstStage.
does is execute all previous commands in full, before starting subsequent commands at all. (BTW, prefer to use STAGE_ALL_COMMANDS for this case as it is clearer to read in the code)
Awesome, was just going to comment that based on your previous answer.
Thank you, then i indeed misunderstood the barriers as “let any commands happening in dstStage wait on commands happening in srcStage”…
Okay, if i at some point have to do this, i will prefer STAGE_ALL_COMMANDS… Of course i will strive to avoid the pipeline-stall if at all possible
