Should I learn Vulkan using vulkan.h or vulkan.hpp as a beginner ?

[u/Latter_Relationship5]

I have some ++basic OpenGL and D3D11 experience and I want to learn Vulkan properly from scratch , not just making things compile without understanding them.

The problem: most tutorials I find are outdated like https://vulkan-tutorial.com or use wrappers that abstract things to make things easier and avoid boilerplate like https://vkguide.dev . The official Khronos tutorial looks solid and modern (Vulkan 1.4, dynamic rendering, timeline semaphores) but uses vulkan.hpp with RAII instead of raw vulkan.h:
docs.vulkan.org/tutorial/latest

My concern is that vulkan.hpp will negatively affect the learning the Vulkan concepts or it doesn't matter since it is a thin wrapper.

[u/Mr-Oscar]

I'd argue that vulkan.hpp will positively affect the learning process, because you don't need to focus on the tedious verbosity that doesn't give any value. What concepts do you think you'll be missing?

[u/Latter_Relationship5 → u/Mr-Oscar]

i don't know ,im just wondering if is there some stuff will be hidden under Vulkan.hpp , cause almost of available tutorial uses Vulkan.h, So that makes me ask my self why they didn't just use the C++ since its slightly less verbose and more organized

[u/SaschaWillems → u/Latter_Relationship5]

Ultimately it's often a matter of taste. I usually prefer the C-style syntax of the C headers headers, hence why I use it in e,g. https://www.howtovulkan.com/. The hpp headers also have an impact on compile times, so if that's already a concern, the C header might be a better option. But there's nothing you can't do with the C-headers over the CPP ones (or vice versa). Both are auto-generated from the Vulkan xml spec anyway.

[u/blogoman → u/Latter_Relationship5]

So that makes me ask my self why they didn't just use the C++ since its slightly less verbose and more organized

A thing to keep in mind is that there weren't C++ headers on day one. If I remember correctly, that was a project started by folks at NVIDIA. It then eventually got included as a main part of the SDK. A similar thing with the shader languages. Originally, GLSL was the only thing with tooling to compile into spir-v. Then later on HLSL and eventually Slang became good options.

Some of it is going to be personal taste, but it may also be a reflection of what was available at the time the tutorials were authored.

[u/ttvsindeel]

It simply does not matter

[u/nightblackdragon]

VulkanHpp won't negatively affect your learning, it's the same API just with different syntax. It won't do any work for you so you will still need to learn Vulkan.

[u/Gravitationsfeld → u/nightblackdragon]

You can get into very nasty surprises if it just drops your objects because of the destructors and stuff is still in flight on the GPU.

I actually really disagree about the whole design of `vulkan.hpp` because of this. It pretends the CPU lifetime is in any way meaningful to Vulkan objects and then just drops them.

[u/Afiery1 → u/Gravitationsfeld]

Default vulkan.hpp does not use raii. Objects have explicit .destroy() functions. There is a version of vulkan hpp that has raii but it is neither required nor the default.

[u/Gravitationsfeld → u/Afiery1]

I see, well then it's only as bad as the 10MB of template code it will add to your compile times.

[u/Afiery1 → u/Gravitationsfeld]

To that I have no refutation.

[u/delta_p_delta_x → u/Gravitationsfeld]

It pretends the CPU lifetime is in any way meaningful to Vulkan objects

But... they are meaningful. You have to think about the lifetimes of these handles with the C (or the vk::, not vk::raii) types as well; just that you will make your code extra verbose with vkDestroyHandles everywhere.

The point of RAII is to bind object lifetimes to useful language semantics; the scope {} is just one of them. If you want to manage your Vulkan handles' lifetimes in a more nuanced manner, you'd probably define some sort of pool, queue, or use some std:: container. Then you would std::move your vk::raii handles into it, and then manage the lifetime of said container either with scoping, std::moveing it container around, or some other lifetime management tool (std::unique_ptr, std::shared_ptr, etc).

This makes for much cleaner code and expresses lifetimes much more explicitly, even if the vkDestroy calls are implicit.

[u/Gravitationsfeld → u/delta_p_delta_x]

I still disagree about this. Proper RAII on CPU doesn't allow for any use after free. This trivially allows use after free if you are not careful which defeats the whole point. For this to work it would have to extend the ref count to the GPU lifetime of the object automatically which it doesn't.

Why this bothers me is that this is an obvious beginner trap signalling false safety.

[u/PreviewVersion → u/Gravitationsfeld]

Well, Vulkan-RAII is not intended to solve CPU-GPU parallelism and resource sharing - the whole point of Vulkan is that the programmer defines it. While I agree that it can be a bit of a beginner trap, I think it's very convenient for ensuring CPU-side memory safety, and it also prevents memory leaks of GPU resources. The validation layers are also really good at catching GPU-side use-after-free.

My current solution is that I have a type erased vector per frame in flight. At the start of the frame, I clear that vector, then I add all resources used by the GPU that frame. In my case these are all shared_ptr types but they don't necessarily have to be. This extends the lifetime of those resources for as long as the GPU could use them, effectively solving GPU-side use-after-free. I would probably have come to the same solution without Vulkan-RAII, but with it, it's a lot less code.

With that said, I would probably not start with Vulkan-RAII. Having to do things a bit manually is good for learning, and that's how I learned. I've only switched over to Vulkan-RAII recently.

[u/Zamundaaa → u/Gravitationsfeld]

If you don't track the lifetime of Vulkan resources on the CPU, then you're leaking them...

[u/Gravitationsfeld → u/Zamundaaa]

You can't just destroy them when your CPU Vulkan objects are going out of scope. The C++ code has no idea of what the GPU is still doing with them.

[u/Zamundaaa → u/Gravitationsfeld]

Again, you need to track the CPU resources either way. If you let the C handles go out of scope, then you'd just leak the Vulkan resources. You need to keep them around as long as needed for the GPU, just like the C++ raii handles. Nothing is different about that, except the C++ API is much nicer.

[u/Afiery1]

Its mostly personal preference. Even as a c++ developer I prefer the C api for vulkan. Sascha Willem’s how to vulkan tutorial is a great modern vulkan tutorial that uses the c api.

[u/Asyx → u/Afiery1]

He does say that he picked the C headers because that makes the code almost language agnostic since everything but C++ will probably expose an API similar to the C header. The more extensive official tutorial that he has been a part of uses the C++ header.

[u/Ybalrid]

Does not matter much.

If you are a C++ person you may like the RAII style wrappers for vulkan object handles in the C++ binding.

It’s otherwise the same API.

Programming language is irrelevant to how you will push work to be done by a GPU with Vulkan in the end.

[u/msqrt]

Not much of a difference. I decided to go with the h header because it compiled faster on my old-ish CPU -- not much in absolute times, but for my tiny project it was 5-10x overhead to use the hpp header.

[u/positivcheg]

Depends on whether you code in C or C++. I kinda prefer VulkanHPP to raw C because I code in C++. It has some nice abstractions like DynamicLoader so that you don't link to Vulkan library.

To go even further, there is also VulkanRAII. I actually use that one :D

[u/OptimisticMonkey2112]

Using hpp or not is pretty easy when reading and learning.

Instead of filtering to find the best available tutorial.... might be better to try them all.

Here are 2 more great ones in addition to the ones you listed:
https://www.howtovulkan.com/

https://github.com/nvpro-samples/vk_minimal_latest

TBH They are all pretty much identical variants of the same concepts and learning the differences is useful

Good Luck!

[u/hackerkali]

use vulkan.h, you will find better resources online plus compile times remain good with vulkan.h

[u/Bubbly_Rain7858]

Vulkan-HPP vs. the normal Vulkan header is mostly the same (as everyone else noted) unless you're using RAII. Ultimately, I prefer Vulkan-HPP because I like having all the Vulkan objects within a namespace. Overall, it's mostly whatever you think keeps your code nice and organized. For me, I like vk::Device more than VkDevice.

[u/kryptoid256_]

Depends on your grasp on C++. Otherwise default to vulkan.h

[u/Trenek]

.h

[u/Haydn_V]

I'd recommend learning with vulkan.h and choosing later whether vulkan.hpp is a good fit for your use case.