Backends: Vulkan: Support for dynamic_rendering

[spnda]

With the VK_KHR_dynamic_rendering extension Vulkan received a whole new way of how to rasterize. In the end, it got rid of VkRenderPass and VkFramebuffer, which is the reason for me opening this PR. Developers who want to utilize the new extension, which also got made core in Vulkan 1.3, and are attempting to use its functionality would have to fallback to the old VkRenderPass and VkFramebuffer system, effectively being unable to utilize anything new.

With this PR, one can set a boolean in the ImGui_ImplVulkan_InitInfo struct while initializing the backend so that it does not require a valid VkRenderPass to be passed into ImGui_ImplVulkan_Init. The new dynamic_rendering functionality only requires an attachment format, which is the reasoning for the new ColorAttachmentFormat member in the ImGui_ImplVulkan_InitInfo struct. This value is used while creating the pipeline instead of the render pass. The color format is allowed to be 0, or VK_FORMAT_UNDEFINED, which is why I do not assert there. The application developer is also responsible for checking if the extension is present or if the device supports Vulkan 1.3.

[ocornut]

Hello,

Thanks for the PR.
I wanted to merge this today, but wanted to check if you could confirm the same logic would apply well to secondary viewports created by the backend in the docking branch. Have you tested it?

In particular, ImGui_ImplVulkan_CreatePipeline() USED to not use InitInfo directly because it was initially used in docking branch as part of secondary viewport creation, but it's not the case anymore. It would generally be good if you could double check your changes with that branch and multi-viewports enabled.

Thanks!

[spnda]

Hello @ocornut,
I don't have a Windows/Linux PC at the moment and would need to modify my Vulkan SDK install to use VK_KHR_dynamic_rendering. I also don't use the docking branch and have no idea how it works currently, and from my quick search I couldn't find an example on that branch where I could quickly test the functionality. Perhaps I missed something?
I'm going to look at the code on its branch a bit but I think it might be quicker and better for someone else to test this at the moment :)

[ocornut]

Any of the examples where the ViewportEnable configuration flag is set will demonstrate use of multi-viewports. See wiki https://github.com/ocornut/imgui/wiki/Multi-Viewports for a description of that feature.

[spnda]

Took me a few hours but I got a master build of MoltenVK to run on this Mac and managed to get the example_glfw_vulkan with some minor modifications so that it uses this feature to work, and I guess this looks correct?

I also pushed a small edit, but I want to make a few changes first. Hang tight :)

[spnda]

Ok @ocornut this is good to go now. If you want to see what I changed in the example (or perhaps want a new one in this repo?), see here: spnda@3ffcea4.

[David-DiGioia]

When I try to run this it fails when I try to drag an imgui window, with the validation error

[DebugCallback]: Validation Error: [ VUID-vkCmdDrawIndexed-renderPass-02684 ] Object 0: handle = 0x44695a0000000071, type = VK_OBJECT_TYPE_RENDER_PASS; Object 1: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0x8cb637c2 | vkCmdDrawIndexed: RenderPasses incompatible between active render pass w/ VkRenderPass 0x44695a0000000071[] with flags of 0 and pipeline state object w/ VkRenderPass 0x0[] with a flags of 3387955248. The Vulkan spec states: The current render pass must be compatible with the renderPass member of the VkGraphicsPipelineCreateInfo structure specified when creating the VkPipeline bound to VK_PIPELINE_BIND_POINT_GRAPHICS (https://vulkan.lunarg.com/doc/view/1.3.204.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdDrawIndexed-renderPass-02684)

in ImGui_ImplVulkan_RenderDrawData at vkCmdDrawIndexed. Looks like ImGui_ImplVulkan_RenderWindow is creating a renderpass and trying to use it to render an undocked imgui window but the pipeline mismatches the renderpass since it has VK_NULL_HANDLE as its renderpass because of dynamic rendering.

[spnda]

ImGui_ImplVulkan_RenderView will definitely need upgrading on the docking branch, after this PR has been merged. The change is really trivial, I'm only unsure how the function pointers to the KHR functions should be loaded...
I have quickly pushed spnda@3ac36d5 which you could perhaps use to patch your local version. It works perfectly fine on my system with MVK with no validation errors. Note that you will probably get linker errors because of the function pointer not being exposed by the loader... though not sure if the current backend can work with extension methods yet, which would require a bit of a change to how it loads functions.

Also @ocornut, any updates on merge status for this PR?

[ocornut]

Hello @spnda, sorry i was waiting on a commit for docking. Could you open or rework this PR over docking in two separate commits, one that will merge over master and a second one over docking?

[ocornut]

Pushed 7812e83 + small amends 121072c + docking amends ac85738

Than you!

[ocornut]

For reference, attached is the patch to enable dynamic rendering in GLFW+Vulkan's main.cpp:

imgui-5ac7227-Examples GLFW+Vulkan Add compile-time flag to use Dynamic Rendering (5446).patch