How to implement dynamic rendering via vkCmdBeginRendering?

[ariaci]

Hi,

I want to implement DepthPeeling like proposed in chapter 5 of "The Modern Vulkan Cookbook" to handle transparencies correctly.
I'm using DepthPeeling because it seems to be a good middle way between memory- and performance-requirements.

Does vsg support dynamic rendering using vkCmdBeginRendering?

It seems that the current implementation of GraphicsPipeline::Implementation does not support rendering without a valid renderpass and so binding and creating pipeline without a renderpass is not possible.
I think supporting dynamic rendering would improve handling of dynamic situations like transparency handling drastically.

src\vsg\state\GraphicsPipeline.cpp:

////////////////////////////////////////////////////////////////////////
//
// GraphicsPipeline::Implementation
//
GraphicsPipeline::Implementation::Implementation(Context& context, Device* device, const RenderPass* renderPass, const PipelineLayout* pipelineLayout, const ShaderStages& shaderStages, const GraphicsPipelineStates& pipelineStates, uint32_t subpass) :
    _device(device)
{
    VkGraphicsPipelineCreateInfo pipelineInfo = {};
    pipelineInfo.sType = VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO;
    pipelineInfo.layout = pipelineLayout->vk(device->deviceID);
    pipelineInfo.renderPass = *renderPass;  // <= no renderpass results in crash
    pipelineInfo.subpass = subpass;
    pipelineInfo.basePipelineHandle = VK_NULL_HANDLE;
    pipelineInfo.pNext = nullptr;

    ...
}

Khronos states that there is no need for a render pass soon as the pNext-list of VkGraphicsPipelineCreateInfo contains a valid VkPipelineRenderingCreateInfo-structure ...

Is there another way to handle dynamic rendering or shall I describe a render pass having multiple sub-passes?

Thanks in advance.

[nolankramer]

I'd also be curious to hear @robertosfield's thoughts on this - but from what I can tell, VSG is currently built to support Vulkan 1.0 spec (although I believe it enables some extensions that may need greater support).

VSG is also required to work well on mobile, where I think layout transitions are more important for compression optimization/tiling.

This of-course means that Dynamic Rendering, which handles layout transitions and other things automatically, aren't integrated into the VSG yet.

From what I gather, it may be possible to create a patch to VSG to implement it. It would simply require implementing the required API for vkBegin/EndRendering, perhaps with a vsg::DynamicRendering class, and any other supporting structs - then also adding API to vsg::GraphicsPipeline to compile with the appropriate info. This would replace usage of vsg::RenderGraph.

Integrating such a feature into the VSG itself could be tricky - since the actual usage of the API requires runtime checks for availability (I believe the extension is available since 1.2.197, and is Core since 1.3).

I don't know how Robert likes handling these kinds of things. There's no way to do a static assert on the API usage. Perhaps if a user ever creates a vsg::DynamicRendering class, but it's unsupported, immediately do an assert. It should get caught during development/testing. It's then up to app developers to inform users of minimum spec requirements.

[robertosfield]

The minimum Vulkan version for the VSG is 1.1.70, features after this are supported, and for these we check at runtime and individually enable features when supported.

I haven't looked at support for vkCmdBeginRendering and without reviewing the feature spec and examples that use it, I am not in position to comment on how quickly it could be implemented and how well it work with the rest of the VSG.

In terms of implementing dynamic rendering, well this is such an open ended topic that has many different interpretations again I really provide guidance. You can do multi-pass with/without use multiple sub passes. You mix in compute as part of this as well. There are lots of different ways of different things.

[swp-ariaci]

Sorry for my late reply ... I'm very busy at this time ...

After receiving your reply, I spent some time researching to verify the multi-pass approach. I've found out that Khronos also offers an example of depth peeling to process transparencies correctly. All examples are also available on GitHub: https://github.com/KhronosGroup/Vulkan-Samples.git

The example mentioned above is also based on multi-pass rendering and not on dynamic rendering. I'll try to implement this algorithm in VSG using all ideas behind ...

If I have any questions, I will post them in this thread. ;-)

[nolankramer]

FWIW, if it's helpful - transparency rendering can be done in multiple ways. Depth peeling is great (and also typically used as the benchmark), but there's also OIT (Order-Independent-Transparency) methods that are really fast and cheap, and require no depth sorting: https://github.com/nvpro-samples/vk_order_independent_transparency.

[swp-ariaci]

Ok, I've solved depth peeling algorithm with vsg without using Dynamic Rendering (VK_KHR_dynamic_rendering or core since VK_VERSION_1_3). :-)

I've created two render passes:

1. first one is rendering all opaque fragments
2. the second render pass is using sub-passes to render, accumulate and overlay the result for each transparent layer from front to back

After last render pass (and of course outside) the intermediate result image is copied to current swap chain image using vsg::CopyImageViewToWindow.
At its core, it's very simple, but defining all descriptors and shader sets etc. correctly requires a lot of metadata and wasn't easy for a Vulkan beginner like me ;-)

My current shaders use Robert's Phong and Flat implementations. Slightly modified, of course (with input attachments, manual depth checks, etc.) to add depth peeling data.
The resizing of the window and the recreation of all necessary resources is handled by a separate visitor by implementing Visitor::apply(ConfigureWindowEvent&).

Although it works now, in my opinion, dynamic rendering would significantly improve the handling of such situations.
And among us, I like the idea of an additional class vsg::DynamicRendering to handle such situations. :-)

[robertosfield]

Glad you have got something working. I haven't implemented depth peeling with the VSG so can't provide specific input, but when I read that you can needed vsg::CopyImageViewToWindow() I did wonder you might be able to structure it differently to avoid this.

I have lots of others tasks on my plate right now so not in position to look into VK_KHR_dynamic_rendering.

One way forward when implementing features like this is to create a test bed in vsgExamples that is implemented using standard VSG then create an experimental code path that extends the VSG classes then have the ability to toggle between the standard and the extended versions. Then others can chip in and help refine two versions, and finally if it's appropriate create core features that mean the the local extensions in the testbed can be dropped and the new core feature used.

[swp-ariaci]

Yes, you are right. I'm sure that it would be possible to avoid vsg::CopyImageViewToWindow but I had some problems with handling window resizing.

I'm using default vsg::RenderGraph-implementation at this point and set my own framebuffer for collecting intermediate results. For this reason, vsg::RenderGraph::windowResizeHandler is not called, as vsg::RenderGraph uses the size of the frame buffer, which does not change.
My solution was to introduce a separate resizing event that handles all these tasks and updates the framebuffer used.

That's why currently everything is decoupled from window swap chain.

And you are absolutely right - vsgExamples would be a good starting point for implementing such a feature. Maybe I'm asking my boss if it would be possible to contribute some ideas/code how to implement depth peeling.

[swp-ariaci]

Good news... I asked my boss and he says it's possible to invest some time to create an example for vsgExamples! I think I'll start doing that next year ... :-)