-
-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
VuIkan: invalid Dynamic Rendering functions from the Instance-level loader #7554
Comments
Because it can be very setup-specific, here's my Vulkan SDK version, driver and related hardware: Vulkan SDK: 1.3.261.0 |
Hello, Thanks for the careful report! Dealing with fringe backend-related issues, and in particular Vulkan ones, has been too time consuming so for now I haven't really read this. I am open to PR with solution given than you carefully research the reason current things are in place this way (you can generally use git blame). The trail gives: 121072c, 7812e83, #5446, #5037, see discussions in those threads. Thank you!
FYI you shouldn't need to define this, it's defined automatically when the Vulkan header version has it.
Unless I am mistaken, in your specific configuration ImGuiImplVulkanFuncs_vkCmdBeginRenderingKHR = reinterpret_cast<PFN_vkCmdBeginRenderingKHR>(vkGetInstanceProcAddr(info->Instance, "vkCmdBeginRenderingKHR"));
ImGuiImplVulkanFuncs_vkCmdEndRenderingKHR = reinterpret_cast<PFN_vkCmdEndRenderingKHR>(vkGetInstanceProcAddr(info->Instance, "vkCmdEndRenderingKHR")); Therefore the only function loading code that runs is through your loader?
I noticed by looking at your screenshots that your version of the code is before b720c0f. This was meant to solve another issue but it interfere in same places of the code making this a little confusion.
Thanks a lot! |
Version/Branch of Dear ImGui:
Version 1.90.5, Branch: docking
Back-ends:
imgui_impl_vulkan.cpp + imgui_impl_win32.cpp
Compiler, OS:
Windows 10 + MSVC 2022
Full config/build information:
Details:
ImGuiImplVulkanFuncs_vkCmdBeginRenderingKHR
andImGuiImplVulkanFuncs_vkCmdEndRenderingKHR
have invalid function pointersEdit (see following comments): because they are requested via string with KHR postfix
Hi!
I'm currently in the process of integrating ImGui docking branch in my Vulkan renderer. In my app I link vulkan dynamically by loading function pointers via
vkGetInstanceProcAddr
andvkGetDeviceProcAddr
So I have defines that force ImGui to do almost the same thing:
#define IMGUI_IMPL_VULKAN_HAS_DYNAMIC_RENDERING
#define IMGUI_IMPL_VULKAN_NO_PROTOTYPES
#define VK_NO_PROTOTYPES
I provide function loader via ImGui_ImplVulkan_LoadFunctions:
The callback is called and all necessary functions seem to be loaded, no asserts triggered, etc.
For main viewport everything works great, the app handles surrounding render passes, command buffer is recorded by ImGui and then app does synchronization and submits the command buffer to the queue on it's own agenda.
Which just forwards call here
Though when I drag ImGui windows out of the main viewport, the Win32 window is created by ImGui with all associated resources (some of them I provide via callback, like VkSurface).
Drawing separate windows is delegated to
ImGui_ImplVulkan_RenderWindow
as you can see in the callstack of the following screenshot. Though I hit NULL function pointer directly underImGuiImplVulkanFuncs_vkCmdBeginRenderingKHR
(double checked for EndRendering, same thing)I've managed to fix this issue by providing vulkan function pointers from my app to the vulkan_impl (red - new code, green - original):
The main difference between functions obtained via ImGui_ImplVulkan_LoadFunctions and my app function pointers is that I use pointers obtained from the device
vkGetDeviceProcAddr
while ImGui uses instance-level functionvkGetInstanceProcAddr
.Another difference:
My thought is that Vulkan trampoline fails to dispatch instance-level functions correctly for dynamic rendering extension. Worth noting that in my app I allow ImGui to obtain Vulkan pointer after I initialize my app's function table. So that could be the reason why the loader is freaking out. But I'm not completely if it's the expected behavior.
(Read about vulkan loaders and trampolines here).
This could be hot-fixed on the side of application if I hack the callback for loading functions. But it's "meh".
Is there a particular reason why ImGui loads all functions on the Instance level?
Is it worth providing Device-level function loading?
Core functions that ImGui obtains from Instance seem to work just fine.
Screenshots/Video:
No response
Minimal, Complete and Verifiable Example code:
No response
The text was updated successfully, but these errors were encountered: