OIT and multiple render passes with multiple views

[theodoregoetz]

We have successfully implemented OIT (order independent transparency) a la https://github.com/KhronosGroup/Vulkan-Samples/tree/main/samples/api/oit_linked_lists using VSG. This requires multiple render passes - 2 or more if we want to split out the opaque elements into it's own pass. The reason for 2 passes is that the technique requires a memory barrier that must be done outside of a render pass.

In our application we also have multiple views - both at the top-level of the scenegraph and nested - which is important to consider in the following case, but ultimately it boils down to having each view record it's own set of render graphs. The actual record would have be done after all children of a given view has been visited.

Judging from our failure to use render graphs to clear only a part of the framebuffer (See this issue and associated PR) we are now considering have each of our views render to a texture in it's own set of render passes and following up with a composite pass to write to the displayed framebuffer in the swapchain.

I guess this is more of a open discussion rather than a specific question. But I'd be interested if anyone thinks there's a better way to complish this.

[robertosfield]

You shouldn't need to use high level syncronization via vkRenderPass/vsg::RenderGraph, should be possible to just putting vk/vsg::PipelineBarrier within a RenderGraph to do the synchronization and any memory access changes that are required.

[theodoregoetz]

We were getting validation errors from Vulkan when we tried to do just that. Also the vsgrendertotexture example showcases using a separate render graph in a very similar way to how the OIT example works.

That said, I'm going to look a little deeper at the Vulkan docs and try again to use barriers within the render graph.

[theodoregoetz]

OK, I think you are right @robertosfield , however when I try to use a PipelineBarrier within a RenderGraph I get this validation error (though the rendered scene actually looks just fine!)

VUID-vkCmdPipelineBarrier-None-07889(ERROR / SPEC): msgNum: -616663606 - Validation Error: [ VUID-vkCmdPipelineBarrier-None-07889 ] Object 0: handle = 0xc000000000c, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0xdb3e75ca | vkCmdPipelineBarrier(): Barriers cannot be set during subpass 0 of VkRenderPass 0xc000000000c[] with no self-dependency specified. The Vulkan spec states: If vkCmdPipelineBarrier is called within a render pass instance using a VkRenderPass object, the render pass must have been created with at least one subpass dependency that expresses a dependency from the current subpass to itself, does not include VK_DEPENDENCY_BY_REGION_BIT if this command does not, does not include VK_DEPENDENCY_VIEW_LOCAL_BIT if this command does not, and has synchronization scopes and access scopes that are all supersets of the scopes defined in this command (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdPipelineBarrier-None-07889)

I had initially read that to mean we couldn't use a PipelineBarrier at all within a RenderPass, but that's not the case. I'm now guessing that I'll need to create my own RenderPass that has this subpass-self-dependency and attach it to the Window instead of relying on the default RenderPass that would otherwise be created for me.