Is `vkCmdPipelineBarrier` strong enough to use feedback attachments more than once?

[cold thorn]

When using a feedback attachment (the same attachment bound to both input and color within the same subpass) it is possible for the fragment to query the value it is about to overwrite, but it becomes undefined behavior for any given fragment location to execute more than once due to the lack of coherency.

Does vkCmdPipelineBarrier represent a strong enough memory dependency for several such operations to be chained within a single subpass (i.e. the second invocation can observe the changes made by the first through the same feedback attachment), or must I use several subpasses with appropriate dependencies?

[cold thorn]

Well, it seems to work great on AMD+Mesa!
It was probably silly of me to assume otherwise, especially given that one of the VkAccessFlags is literally VK_ACCESS_INPUT_ATTACHMENT_READ_BIT, very much implying that it is allowable to set up a dependency there. Whoops ^^;;

[acoustic obsidian]

Yeah, you can have a subpass dependency from subpass number n->n. Such dependencies don't do anything themselves but allow you to use a barrier in the middle of a subpass with compatible flags.