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

Wrong vulkan command dispatch classification #110

Open
evopen opened this issue Nov 27, 2023 · 3 comments
Open

Wrong vulkan command dispatch classification #110

evopen opened this issue Nov 27, 2023 · 3 comments

Comments

@evopen
Copy link

evopen commented Nov 27, 2023

Currently a command dispatch type is determined by first parameter of its function signature in classifyCommandDispatch.

This is wrong for functions provided by instance extension VK_EXT_debug_utils. Those functions' first param is a VkDevice.

@evopen evopen changed the title Wrong vulkan command dispatch classifiction Wrong vulkan command dispatch classification Nov 27, 2023
@Snektron
Copy link
Owner

Which function does this apply to? I checked them all and they seem to have the right parameter.

@evopen
Copy link
Author

evopen commented Dec 1, 2023

For example, the function vkSetDebugUtilsObjectNameEXT is provided by instance extension VK_EXT_debug_utils. Its first parameter is VkDevice. So this function is registered in vk.DeviceWrapper.

Generally you pass vkGetDeviceProcAddr loader to vk.DeviceWrapper.load(), but for vkSetDebugUtilsObjectNameEXT, it should be load by vkGetInstanceProcAddr.

@Snektron Snektron added this to the Spring cleaning 2024 milestone Apr 26, 2024
@Snektron
Copy link
Owner

Snektron commented Apr 28, 2024

This is weird. There is no indication anywhere that this should be loaded by the vkGetInstanceProcAddr, and in amdvlk vkSetDebugUtilsObjectNameEXT seems to be a device-level function. Which driver and version are you using? Do you have a repro?

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

No branches or pull requests

2 participants