zeux/volk

vkSetDebugUtilsObjectNameEXT retrieval problem

turanszkij opened this issue · 6 comments

turanszkij commented

Hi,

Thanks for this amazing tool, it eases the pain of managing vulkan extensions greatly. A slight issue for me is that the vkSetDebugUtilsObjectNameEXT is always null, but if I load it manually like this it works fine:

VkDevice device;
//...

vkSetDebugUtilsObjectNameEXT = (PFN_vkSetDebugUtilsObjectNameEXT)vkGetDeviceProcAddr(device, "vkSetDebugUtilsObjectNameEXT");

(I think it should be in the volkGenLoadDevice function instead of volkGenLoadInstance but I might be mistaken)

This is also true for the following functions:

  • vkSetDebugUtilsObjectNameEXT
  • vkCmdBeginDebugUtilsLabelEXT
  • vkCmdEndDebugUtilsLabelEXT
  • vkCmdInsertDebugUtilsLabelEXT

At the same time, all other extensions that I use work fine without doing anything like this manually (raytracing, mesh shader, vrs... )

Is this intended? Am I not using this library correctly?

Thanks

zeux commented

This looks like an inverse of #8... I'll take a look. Are you using Windows or Linux? Is this with debug layers enabled?

turanszkij commented

That is strange.. I'm using Windows, it's happening with either debug layers enabled or disabled. Vulkan SDK 1.2.162. It's not urgent though, as my workaround is working fine. Thanks!

zeux commented

At the risk of asking a stupid question, are you specifying VK_EXT_debug_utils during instance creation?

The behavior I observe is:

  • When VK_EXT_debug_utils is present in the extension list, the function pointer is non-NULL and correct
  • When VK_EXT_debug_utils is absent from the extension list, the function pointer is NULL; using vkGetDeviceProcAddr retrieves a function pointer but I don't think this is guaranteed.
zeux commented

As for using vkGetDeviceProcAddr for this function, volk isn't doing this since this change: 196003a

Quoting the commit message:

Vulkan specification says that while core device-level commands and
device-level commands provided by device extensions can be loaded by
GDPA, device-level commands provided by instance extensions can't be.

vkSetDebugUtilsObjectNameEXT is provided by VK_EXT_debug_utils which is an instance-level extension.
GDPA happens to work but the specification doesn't guarantee that.

Interestingly, the spec itself has an example of using GDPA to retrieve vkSetDebugUtilsObjectNameEXT which is odd.
I'm going to ask people who understand the spec better than I do and possibly file a spec bug for this.

turanszkij commented

The VK_EXT_debug_utils was a good tip. It was only enabled for me in some specific circumstance, and in that case, Volk creates the functions correctly! Thanks, this is a good solution for me!

zeux commented

Sounds good. I've confirmed that GIPA is the only valid way to retrieve this pointer and filed KhronosGroup/Vulkan-Docs#1432 to address the examples that are part of the spec.