Backends: Vulkan: Create a custom pipeline for viewports

[skaman]

The main render pass may have a different configuration than the viewport window render pass. Vulkan can reuse the pipeline between different render passes only if the render pass configuration is the same. To fix it, when it's time to RenderDrawData for the viewport window and a pipeline is not yet available, a new pipeline is created for that window to be sure that is compatible with the render pass.

This is related to the issue #6305

[ocornut]

Hello,
Thanks for your PR.

• Could you post a patch (or separate commit which I won't merge) to repro the issue in one of the existing Vulkan example?
• It seems like a shared pipeline could be used for all secondary viewports, in which case it may make more sense to create it during Init and reuse that?

[skaman]

Hello, Thanks for your PR.

• Could you post a patch (or separate commit which I won't merge) to repro the issue in one of the existing Vulkan example?

I created a commit into a different branch: skaman@f974caa

Is it ok?

I created a custom render pass that i pass to the ImGui_ImplVulkan_Init function. To reproduce the issue the render pass should differ from the internal one, so i changed the color format from UNORM to SRGB (the colors are weird but it's just for test). In the real world probably the user have a depth buffer or multiple render passes.

• It seems like a shared pipeline could be used for all secondary viewports, in which case it may make more sense to create it during Init and reuse that?

Yes you're right. I'll change the fix to have a shared pipeline for all secondary windows. I'll let you know when it's done.

[skaman]

Ok, committed the shared pipeline. Now there's only one pipeline for all the secondary windows.

[raaavioli]

Is this being merged? I'm experiencing an issue that would be solved with this. Particularly the RenderPass I'm using in ImGui_ImplVulkan_Init has a VK_FORMAT_B8G8R8A8_SRGB format, but the created window defaults to VK_FORMAT_B8G8R8A8_UNORM, or any of const VkFormat requestSurfaceImageFormat[] = { VK_FORMAT_B8G8R8A8_UNORM, VK_FORMAT_R8G8B8A8_UNORM, VK_FORMAT_B8G8R8_UNORM, VK_FORMAT_R8G8B8_UNORM };.

I could see this as a solution, or some way to request a custom surface format when creating the multi-viewport renderpass.

[theunwisewolf]

Any update on this?

[ocornut]

I created a commit into a different branch: skaman@f974caa

Thank you @skaman and sorry for slow answer.

Why is the if (wd->Pipeline) { vkDestroyPipeline(device, wd->Pipeline, allocator); } code being removed?

[ocornut]

Why is the if (wd->Pipeline) { vkDestroyPipeline(device, wd->Pipeline, allocator); } code being removed?

I realized that:

• wd->Pipeline is misleadingly essentially never used by the backend so far, and therefore always null.
• If anything, it can then only be potentially fed by the application using the ImGui_ImplVulkanH_Window helper, but our own example apps don't use it, our backend doesn't use it anymore, and we discourage users from using those helpers anyway.

Therefore the whole thing is a fishy leftover that once worked. Initially was added in 41e2aa2 for #3459.
That initial version had the ImGui_ImplVulkan_CreatePipeline() call in ImGui_ImplVulkanH_CreateWindowSwapChain(), it made sense.

However it was immediately removed by e8447de also for #3459 and I believe I messed up there. @FunMiles themselves updated later and eventually reacted to it #3459 (comment) but I guess it went unnoticed then :(

While it seems to be my fault I believe it highlight that I need clear repros of the more intricate use cases of Vulkan. (I maintain them in private branches and could probably aim to publish them somewhere). Thanks for providing one here!

[ocornut]

The PR is incorrect as is, as ImGui_ImplVulkanH_XXXX() functions aren't allowed to use backend data. In fact it makes the main.cpp examples asserts because they call ImGui_ImplVulkanH_CreateOrResizeWindow() first.

I have moved the creation in ImGui_ImplVulkan_CreateWindow() instead: ebb8d78 and it works.
I have also vaguely confirmed that it works with my setup for using dynamic rendering.

Apologies @FunMiles ! Thanks all!