For some time I was thinking of a small enhancement to the pipeline stage flags. I want to show it here for someone to find some reasoning errors and feedback if it’s worth suggesting to Khronos.
So there’s TOP_OF_PIPE and BOTTOM_OF_PIPE flags. I see only two valid usages of these flags:
TOP used in srcStage and BOTTOM in dstStage both mean pretty much “no dependency”.
TOP used in dstStage and BOTTOM in srcStage is often used instead of ALL_COMMANDS (I am not even sure that is always a correct usage).
I can’t think of any other usage. It doesn’t make much sense to combine them with other stages and no actual work seems to be done during them.
Would it make sense to obsolete them?
The 2) usage would be completely replaced by ALL_COMMANDS flag.
The 1) usage would be completely replaced by allowing 0 stage flag (which can be also named, e.g. NO_STAGE)
This could potentionally preserve backward compatibility (and be introduced before Vulkan 1.1 by still preserving the TOP and BOTTOM flags)
Sorry for the up, but I needed to have a better understanding about memory barriers than I had before.
1a) I agree, but in this case, if it is not to transition the image, why do you need such a barrier?
2a) Okay, to me it is true that to put bottom in src and top in dst mean ALL_COMMANDS.
For 1b) Why Not, but it makes more complex the architecture than necessary (since it add one value)
2b) In my understanding, it is a “good idea” when it come to use bottom at srcStage. In this case, as I said, to me, BOTTOM and ALL_COMMANDS mean the same thing. But it is one incorrect idea when it comes to use bottom at the dstStage.
Imagine the following case. You render into one image something. After render it, you would want use this image into another queue. If you want to get the better performance, you must use BOTTOM as dst to transition your resource to the new queue. If you put ALL_COMMANDS on it, your subsequents commands in the same queue will stall while with BOTTOM it does not.
It is explained in the specification :
The VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT is useful for accomplishing memory barriers and layout transitions when the next accesses will be done in a different queue or by a presentation engine; in these cases subsequent commands in the same queue do not need to wait, but the barrier or transition must complete before semaphores associated with the batch signal.
However, because TOP as a dst means ALL_COMMANDS and BOTTOM as a src means ALL_COMMANDS as well (if I understand well though), we can wonder if we can not remove ALL_COMMANDS ^^
Firstly, I have seen it used wrongly many times. It is easy to confuse because TOP_OF_PIPE and BOTTOM_OF_PIPE have different (seemingly opposite) meaning depending whether you provide it to src or to dst.
ad 1a)
Transitioning Image is a common operation.
Generally it is used to perform only a half of the Memory dependency. (It is pointless for pure Execution dependencies. Then again those are pointless and reason why barrier commands are designed to do both).
Typically the transition to PRESENT layout, where the semaphore after does the second half.
ad 2a)
I have seen case 2) (TOP_OF_PIPE in dst or BOTTOM_OF_PIPE in src) used many many times, but I think more obvious (and perhaps more correct) equivalent is to use ALL_COMMANDS (or GRAPHIC_COMMANDS or |ed stages).
Despite it being used that way (and driver seem not to protest), it is not clear cut to me they are the same from the spec:
The first half of the dependency makes memory accesses using the set of access types in srcAccessMask performed in pipeline stages in srcStageMask by the first set of commands complete and writes be available for subsequent commands.
Says only the specific stages in srcStageMask.
But using src=BOTTOM_OF_PIPE relies on previous pipeline stages to do that too.
ad 1b)
If you would not count the thus obsoleted TOP_OF_PIPE and BOTTOM_OF_PIPE, then it is actually one less value (two less, if you do not count 0 as somewhat special).
ad 2b)
I addressed that. That is actually case 1). In this proposition to the spec dst=0 would be used instead. As in “no stage”. It could even be named that way ( e.g. 0=NO_COMMANDS, to be the antonym of ALL_COMMANDS )
Okay.
It seems that we were both wrong.
Since BOTTOM and TOP OF PIPELINE does not access memory, it is wrong to admit to put one barrier on one of these stages will make memory visible / available.
It is not because it seems to worked with BOTTOM/TOP that it good.
However, validation layers should tell us when we are using these stages in the wrong way.
Going that way, a “full blocking” barrier must be done with ALL_COMMANDS in both src and dst.
Actually, if you use TOP or BOTTOM, you must put the accessMask to 0. (it seems legit because these stages do not do any memory accesses)
You can have some informations in this following links :
The only thing I don’t have a answer is when should we use TOP_OF_PIPE