What's the behavior of overlaping Image Barriers? - vulkan

Question

Standard usage of Barriers is relatively straightforward, but I was wondering what is the behavior of two (or more) overlapping Image Barriers (especially with respect to their side effect -- the layout transition). E.g. (pseudocode):
begin( commandBuffer );
1: write( image );
2: imageBarrier(
image,
src=STAGE_FRAGMENT(from the write at 1:),
dst=STAGE_FRAGMENT(intended for read in FS of read at 4:),
appropriate src and dst access flags,
newLayout=A
);
3: imageBarrier(
image,
src=STAGE_FRAGMENT(from the write at 1:),
dst=STAGE_TRANSFER(intended for read by transfer of readT at 5:),
appropriate src and dst access flags,
newLayout=B
);
4: read( image ); // through vkCmdDraw -- expects layout A
5: readT( image ); // different kind of read through Transfer -- expects layout B
end( commandBuffer );
Is this even legal? (can you back it up by spec quote?)
What is the image layout at each point of the program?
For completeness, what is the proper/best way to write this (one producer, two consumers situation)? (Swap lines 3: and 4: and make it Read-Read dependency?)

Answer 1

An image cannot assume multiple layouts simultaneously. In the case of the code you suggested above, since the two barriers have no dependencies on each other, one would happen before the other, but the order is not specified. So the layout of the image afterwards would be one or the other. Which means one of the two reading operations is going to fail.
If you have two operations that use the image from two different layouts, then one of those operations must execute before the other, since they both cannot read the image in the layout they need to. And therefore, there must be an execution dependency between them:
1: write( image );
2: imageBarrier( image, src=COLOR_ATTACHMENT_OUT, dst=FRAGMENT_SHADER, newLayout=A );
3: read( image ); // e.g. through vkCmdDraw -- expects layout A
4: imageBarrier( image, src=FRAGMENT_SHADER, dst=TRANSFER, newLayout=B );
5: readT( image ); // different kind of read e.g. Transfer -- expects layout B
The dependency in #4 says that the layout transition and later TRANSFER commands will not occur until all previous FRAGMENT_SHADER operations have completed.
make it Read-Read dependency
It's not a "Read-Read dependency". A layout transition modifies the image (theoretically at any rate), just as surely as if you had written values to the image directly. So logically what you have is "I need to read from it in the FS. After that, I have to transition it to a new layout. After that, I need to read from it in a transfer operation".
It's a "Read-Write-Read dependency." The middle part needs to wait until the first read is done, but the second read can't happen until the middle part is finished. You need an execution dependency with an associated image memory barrier&layout transition.