1

I've run into some odd behavior with getting a handle to vkCmdDebugMarkerBeginEXT using vkGetDeviceProcAddr, which differs between AMD and Nvidia. However, using vkGetInstanceProcAddr works.

VkDevice device = ...; // valid initialized device
VkInstance instance = ...; // valid initialized instance

PFN_vkVoidFunction fnDevice = vkGetDeviceProcAddr(device, "vkCmdDebugMarkerBeginEXT");
// fnDevice == nullptr on AMD. Non-null on Nvidia
PFN_vkVoidFunction fnInstance = vkGetInstanceProcAddr(instance, "vkCmdDebugMarkerBeginEXT");
// fnInstance == Non-null on both

From the layer interface documentation:

vkGetDeviceProcAddr can only be used to query for device extension or core device entry points. Device entry points include any command that uses a VkDevice as the first parameter or a dispatchable object that is a child of a VkDevice (currently this includes VkQueue and VkCommandBuffer). vkGetInstanceProcAddr can be used to query either device or instance extension entry points in addition to all core entry points.

The prototype for vkCmdDebugMarkerBeginEXT seems to match this description:

VKAPI_ATTR void VKAPI_CALL vkCmdDebugMarkerBeginEXT(
    VkCommandBuffer                             commandBuffer,
    VkDebugMarkerMarkerInfoEXT*                 pMarkerInfo);

While I can quite easily call the device version, and if this fails, call the instance version (to avoid the extra dispatch cost, if possible), I'm wondering if this is expected behavior, or a driver bug?

MuertoExcobito
  • 9,741
  • 2
  • 37
  • 78

1 Answers1

0

Yes, vkCmdDebugMarkerBeginEXT fits that description.

You should quote Vulkan spec instead (which IMO should have higher specifying power in this matter).

There is one additional requirement: the particular extension has to be enabled on that device for vkGetDeviceProcAddr to work. Otherwise seems like a driver bug.

In fact, the in-spec Example 2 does use vkGetDeviceProcAddr.

krOoze
  • 12,301
  • 1
  • 20
  • 34