charles-lunarg/vk-bootstrap

VkBootstrapDispatch.h combines core and extension functions when they should be separate

charles-lunarg opened this issue · 4 comments

For example vkCmdBeginRendering is the 1.3 core function while vkCmdBeginRenderingEXT is the extension function. The dispatch table doesn't allow usage of the extension function at all, only the core.

Since there are many valid use cases where the extension is desirable over core, the dispatch table should include both.

Having experienced pain and suffering before, I know that this is not an easy feature to add, since aliased functions should not use core parameters, so there will have to be spelunking through the registry to patch together the correct function.

FWIW I ran into this exact issue when attempting to update vk-bootstrap the other day. I'm currently locked to 61f7761, the commit just prior to 04ec13b where presumably vkCmdBeginRendering was promoted to a core feature instead of an extension.

This isn't a major issue, though it is preventing me from making use of a couple of more recent changes (like the instance dispatch table).

FYI I feel really dumb because the implementation was already there, just had a bug where I was checking if the alias existed instead of the base type. Flipping the two around, it appears as if it works as expected.

@Valakor Would appreciate it if you could verify before merging. This kind of change is easy to get wrong due to the nature of how vulkan extension promotion works.

@charles-lunarg this does seem to work for me, at least when I test on my Mac via MoltenVK. I get nullptr for the core vkCmdBeginRendering function but a valid pointer for vkCmdBeginRenderingKHR.

It is somewhat unfortunate that these methods get aliased in this way, requiring the user to juggle function pointers based on whether they're using the core functionality or the extension. This is more a comment on Vulkan extensions in general, but I do wonder if there's some way the library could hide this from the user? Or is that unsafe because of your comment "since aliased functions should not use core parameters"?

It’s unsafe from my perspective because you have to do different things to enable core thins vs extension things. So even though the types are aliases in C as far as the API is concerned they are distinct functions.

Also glad to hear that it works for you.