vulkan.hpp support

[Sephirothbahamut]

Either via an external define or an alternative namespace, it would be great if the library allowed to return the Unique variants of Vulkan entities.
Trying to wrap the currently returned values in vulkan.hpp's Unique wrappers is easy in most cases, but when it comes to extensions that need a dynamic loader it becomes a mess (like the debug messenger). Ideally the "RAII variant" of the library would directly return the Unique wrappers to the user.
(Edit: I don't know how to flag as suggestion)

[charles-lunarg]

This opens up a can of worms that I really don't intend to solve with vk-bootstrap.
One of the core philosophies of vk-bootstrap was to 'do what I need to initialize vulkan, returns all the relevant data, and get out of the applications way.
Initialization code shouldn't have any lingering 'effects' on your main render loop for instance.

I think a single 'header' that inclues vk-bootstrap and vulkan.hpp would be adequate so that C API users don't include the C++ bindings and bloat their compile times unecessirily.

However, I don't know of which problem you speak of with 'extensions that need the dynamic loader'. I return the vkGetInstanceProcAddr function pointer in the vkb::Instance struct specifically for users to initialize dynamic function loaders.

vk-bootstrap/src/VkBootstrap.h

Line 217 in 95b82a9

PFN_vkGetInstanceProcAddr fp_vkGetInstanceProcAddr = nullptr;

So such code is possible with vk-bootstrap

auto instance = vkb::InstanceBuilder().build().value(); //construct instance

 VULKAN_HPP_DEFAULT_DISPATCHER.init(instance.vkGetInstanceProcAddr);

Unless of course the above does not work, as I haven't tested it. (but I'm rather familiar with the internal guts of vulkan.hpp and vk-bootstrap that I don't know why this wouldn't work).

The DynamicLoader of vulkan.hpp loads all function pointers, regardless of whether you tried to enable the appropriate function pointers. The init functions of DynamicLoader attempt to load all the functions pointers available, eg based of the VK_USE_PLATFORM_XXX macros. That means all the debug utils functions will always be queried from the vulkan.hpp dynamic loader, and will have null functions if you don't enable the extension in the instance create info. Now I think I may need to change the default behavior to always enable the extension as currently if you don't provide a debug messenger callback or use the default one, the extension wont be loaded. Of course you can add the extension manually.

[charles-lunarg]

I've found out that vulkan.hpp is planning on splitting the header into multiple files, which gave me the idea that there could be a 'vulkan.hpp vk-bootstra wrapper' header that more or less just takes the return type of the builder structs and turns them into the appropriate vulkan.hpp structures. That would be easier than having two separate implementations of the library, one for each header type.
I'm not sure how to make this wrapper elegant to use, but at least it should be easier than having two entirely separate codepaths.

[rickyjames35]

Are there still plans on implementing this enhancement in the future?

[charles-lunarg]

Yes, unfortunately this repo is a low priority. Plus, work to make vulkan.hpp is a big undertaking and thus hard to just 'do'. I am very open to PR's though, if anyone is willing.