CODEWITHSUNDEEP
vulkan
Antoine Morrier
Antoine Morrier

Reputation: 4078

Barrier and image transition

I am wondering why we usually (from Vulkan tutorial and Sascha Willems example) the barrier on the top of pipeline.

If I am reasoning like a producer and consumer (for mipmap creation for example), I have both in src and dst stage the "flag" "TRANSFER_BIT". So, if I am using the same stage for src and dst, the barrier should happend immediatly, which is the same case if I am using TOP_OF_PIPE flag?

Am I right?

Upvotes: 1

Views: 1108

Answers (1)

krOoze
krOoze

Reputation: 13246

I am not sure if I understand the question, but hopefully I will cover it explaining barriers.

src=TOP_OF_PIPE or dst=BOTTOM_OF_PIPE make a non-blocking barrier (effectivelly being only a half of a Memory Dependency and no Execution Dependency). Is that what you mean by "immediatelly happening" barrier?

dst=TOP_OF_PIPE or src=BOTTOM_OF_PIPE is supposed to be all-blocking barrier (at least I often see it in examples and tutorials). I am not so clear about that from the spec (especially if Memory Dependency needs to be there too) and ALL_COMMANDS (or |ing specific stages) seem to be a better replacement.

(BTW I have written about my peeve with that API design.)

Generally as for Execution Dependency what the barriers do is: they make sure srcStage of all the commands recorded before the barrier is finished before dstStage of any of the commands recorded after the barrier started.
(The above special cases should be consistent with that description too.)

So, that being said, TOP_OF_PIPE does not seem like a suitable replacement for TRANSFER. It would either not perform its intended function at all or be inefficient (based on the descriptions above).

Having srcStage==dstStage has no special meaning. Using TRANSFER in that case means TRANSFER stage of previously recorded commands finished before TRANSFER stage of commands recorded after the barrier.

Upvotes: 3

Related Questions