Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why is ImGui_ImplVulkan_CreatePipeline commented out? #6515

Open
cpp-just opened this issue Jun 13, 2023 · 4 comments
Open

Why is ImGui_ImplVulkan_CreatePipeline commented out? #6515

cpp-just opened this issue Jun 13, 2023 · 4 comments

Comments

@cpp-just
Copy link

Version/Branch of Dear ImGui:

Version: Most recent version (cloned it from github)
Branch: docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_glfw.cpp + imgui_impl_vulkan.cpp
Compiler: MSVC
Operating System: Windows 10 Pro Version 21H2

Line 1337 in imgui_impl_vulkan.cpp is commented out. However, my Render Pass is not compatible with ImGui's render pass (according to the validation layer). When my window is dragged outside my game's viewport, it turns black and I get the following errors:

Validation Error: [ VUID-vkCmdDrawIndexed-renderPass-02684 ] Object 0: handle = 0x5684940000000068, type = VK_OBJECT_TYPE_RENDER_PASS; Object 1: handle = 0x9638f80000000036, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0x8cb637c2 | vkCmdDrawIndexed: RenderPasses incompatible between active render pass w/ VkRenderPass 0x5684940000000068[] and pipeline state object w/ VkRenderPass 0x9638f80000000036[]: First dstStageMask is VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, but second dstStageMask is VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT|VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT. 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.236.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdDrawIndexed-renderPass-02684)

Validation Error: [ VUID-vkCmdDrawIndexed-renderPass-02684 ] Object 0: handle = 0x5684940000000068, type = VK_OBJECT_TYPE_RENDER_PASS; Object 1: handle = 0x9638f80000000036, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0x8cb637c2 | vkCmdDrawIndexed: RenderPasses incompatible between active render pass w/ VkRenderPass 0x5684940000000068[] and pipeline state object w/ VkRenderPass 0x9638f80000000036[]: First dstAccessMask is VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT, but second dstAccessMask is VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT|VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT. 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.236.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdDrawIndexed-renderPass-02684)

Validation Error: [ VUID-vkCmdDrawIndexed-renderPass-02684 ] Object 0: handle = 0x5684940000000068, type = VK_OBJECT_TYPE_RENDER_PASS; Object 1: handle = 0x9638f80000000036, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0x8cb637c2 | vkCmdDrawIndexed: RenderPasses incompatible between active render pass w/ VkRenderPass 0x5684940000000068[] and pipeline state object w/ VkRenderPass 0x9638f80000000036[] Attachment 0 is not compatible with 0: They have different formats.. 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.236.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdDrawIndexed-renderPass-02684)

As far as I understand, that's because my pipeline, which is bound to VK_PIPELINE_BIND_POINT_GRAPHICS, has a render pass which is incompatible with the imgui render pass. I managed to fix this issue by commenting out the line 1337 linked above (and also getting the required data with ImGui_ImplVulkan_GetBackendData()). When the imgui window is inside of my viewport it works as intended (because it's using my render pass?? idk). My question is: Am I supposed to call ImGui_ImplVulkan_CreatePipeline in my own code? That would be kinda tedious because I'd need to access wd->RenderPass, bd->Subpass, etc. which in the code you're getting with ImGui_ImplVulkan_GetBackendData(); which is only defined in the impl cpp file.

Standalone, minimal, complete and verifiable example: (see #2261)
I think a minimal example is not required in this case as I'm mainly just asking about best practice. Also, the example would be kinda long since I'd have to provide my entire vulkan setup code. If it's necessary, I'll do it though.

@KarimIO
Copy link

KarimIO commented Jul 9, 2023

@ocornut I am facing a similar issue. I'm passing my renderpass through the following means:
ImGui_ImplVulkan_Init(&imguiInitInfo, vulkanRenderPass->GetRenderPassHandle());

I like this approach because it allows my code to simply inject my own renderPass into ImGui. Then, when I need to resize the screen, I must call ImGui_ImplVulkanH_CreateOrResizeWindow which passes control of everyhting over to ImGui.

If ImGui_ImplVulkan_GetBackendData() and ImGui_ImplVulkan_CreatePipeline() was accessible, that would allow me to use the vulkan backend properly. An even better solution would be something like ImGui_ImplVulkan_UseNewRenderPass(VkRenderPass renderPass);
This could call ImGui_ImplVulkan_CreatePipeline and set the renderPass. If you are interested in this approach I can make a pull request for it.

KarimIO added a commit to KarimIO/Grindstone that referenced this issue Jul 9, 2023
The actual resizing of ImGui Pipelines so it can actually work will come later. In the meantime, I've asked here: ocornut/imgui#6515
@TechnicJelle
Copy link

I am wondering the same thing. I've been breaking my head over this issue for hours now, reading all the GitHub issues and StackOverflow answers about this, and the only working solutions I've found are one of these two:

  • Use a UNORM surface format, like VK_FORMAT_B8G8R8A8_UNORM instead of VK_FORMAT_B8G8R8A8_SRGB.
    I would prefer to not have to do that.
  • Uncomment that line.

Or is the more "proper" solution to make a separate render pipeline for Dear ImGui?
I already have a separate render pass. Is that not enough?

What is the best solution for fixing this issue, without having to uncomment that line?

If anyone is interested: here is my code: TechnicJelle/VulkanPsychedelicCloths@8db6a8e

But you can also reproduce this issue very easily in the example: just add VK_FORMAT_B8G8R8A8_SRGB at the front of this array:

const VkFormat requestSurfaceImageFormat[] = { VK_FORMAT_B8G8R8A8_UNORM, VK_FORMAT_R8G8B8A8_UNORM, VK_FORMAT_B8G8R8_UNORM, VK_FORMAT_R8G8B8_UNORM };

But make sure you have debug mode properly enabled, so the error actually logs, and doesn't get hidden.
I had to add this ⬇️ to the CMakeLists.txt file to make it properly enable debug mode.

if (CMAKE_BUILD_TYPE MATCHES Debug)
	add_definitions(-D_DEBUG)
endif ()

@CheapMeow
Copy link

CheapMeow commented Apr 29, 2024

Still have this question. If you have more custom setting about render pass, such as a render pass with multiple subpass, you will find your pipeline are incompatible with the built-in render pass. It is much more difficult to deal with than surface format, because you actually need multiple subpass.

I am sure that best solution is create a separate render pass, with setting same as imgui example. Then pass it into ImGui_ImplVulkan_Init.

VkAttachmentDescription attachment = {};
attachment.format = wd->SurfaceFormat.format;
attachment.samples = VK_SAMPLE_COUNT_1_BIT;
attachment.loadOp = wd->ClearEnable ? VK_ATTACHMENT_LOAD_OP_CLEAR : VK_ATTACHMENT_LOAD_OP_DONT_CARE;
attachment.storeOp = VK_ATTACHMENT_STORE_OP_STORE;
attachment.stencilLoadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE;
attachment.stencilStoreOp = VK_ATTACHMENT_STORE_OP_DONT_CARE;
attachment.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;
attachment.finalLayout = VK_IMAGE_LAYOUT_PRESENT_SRC_KHR;
VkAttachmentReference color_attachment = {};
color_attachment.attachment = 0;
color_attachment.layout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;
VkSubpassDescription subpass = {};
subpass.pipelineBindPoint = VK_PIPELINE_BIND_POINT_GRAPHICS;
subpass.colorAttachmentCount = 1;
subpass.pColorAttachments = &color_attachment;
VkSubpassDependency dependency = {};
dependency.srcSubpass = VK_SUBPASS_EXTERNAL;
dependency.dstSubpass = 0;
dependency.srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
dependency.dstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
dependency.srcAccessMask = 0;
dependency.dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;
VkRenderPassCreateInfo info = {};
info.sType = VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO;
info.attachmentCount = 1;
info.pAttachments = &attachment;
info.subpassCount = 1;
info.pSubpasses = &subpass;
info.dependencyCount = 1;
info.pDependencies = &dependency;
err = vkCreateRenderPass(device, &info, allocator, &wd->RenderPass);
check_vk_result(err);

@AliceRemake
Copy link

I am wondering the same thing. I've been breaking my head over this issue for hours now, reading all the GitHub issues and StackOverflow answers about this, and the only working solutions I've found are one of these two:

  • Use a UNORM surface format, like VK_FORMAT_B8G8R8A8_UNORM instead of VK_FORMAT_B8G8R8A8_SRGB.
    I would prefer to not have to do that.
  • Uncomment that line.

Or is the more "proper" solution to make a separate render pipeline for Dear ImGui? I already have a separate render pass. Is that not enough?

What is the best solution for fixing this issue, without having to uncomment that line?

If anyone is interested: here is my code: TechnicJelle/VulkanPsychedelicCloths@8db6a8e

But you can also reproduce this issue very easily in the example: just add VK_FORMAT_B8G8R8A8_SRGB at the front of this array:

const VkFormat requestSurfaceImageFormat[] = { VK_FORMAT_B8G8R8A8_UNORM, VK_FORMAT_R8G8B8A8_UNORM, VK_FORMAT_B8G8R8_UNORM, VK_FORMAT_R8G8B8_UNORM };

But make sure you have debug mode properly enabled, so the error actually logs, and doesn't get hidden.
I had to add this ⬇️ to the CMakeLists.txt file to make it properly enable debug mode.

if (CMAKE_BUILD_TYPE MATCHES Debug)
	add_definitions(-D_DEBUG)
endif ()

#8061 may fix this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants