Use vulkan-hpp will definitely kill almost all performace of C++ compiling.

[HuazyYang]

Vulkan-hpp is definitely a bad practise to manipulate vulkan API which abuse template usage so as to kill C++ compiling performace.

When just including <vulkan.hpp> in any of emty source, compiling duration can take quater of a hour. This dependency will definitely
make your work useless.

[apanteleev]

The entire library builds in way less than a minute on any reasonably modern machine.
Maybe you could get some help with troubleshooting build times on your system, but not with this attitude calling nvrhi useless. Closing.

[BlurryLight]

<vulkan.hpp> is referenced in nvrhi/include/nvrhi/vulkan.h
, which could easily propogate to application-side framework code and be unexpectedly included in alot of source files.
It does have some negatvie impact on compliation speed, and also on IDE indexing/intelligence, especially when nvrhi/vulkan.h is included in alot of translate units.
Since there are only some strcture/function definitions in nvrhi/vulkan.h, I replaced all vulkan.hpp related structs with corresponding vanilla C structures, and replaced vulkan.hpp with vulkan.h and it worked well.

[apanteleev]

Ok, that is a good observation @BlurryLight

I just went through the same exercise replacing vulkan.hpp with vulkan.h in the public header, and it's not that many changes. What worries me a bit here is that it breaks compatibility with existing code using NVRHI: such code will need to include vulkan.hpp on their own (if needed), and add type casts when using the NVRHI functions that changed, like createHandleForNativeFramebuffer because the vk:: and Vk types are not trivially compatible.

[BlurryLight]

Agree with it. It will be a break change since it need application side code to add <vulkan.hpp> in their code, and adjust some API signature.

[apanteleev]

The change removing vulkan.hpp is done in 2f6a8c3
Closing.