vkSetDebugUtilsObjectNameEXT retrieval problem about volk HOT 6 CLOSED

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

from volk.

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!

from volk.

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.

from volk.

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.

from volk.

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!

from volk.

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.

from volk.