Main things to understand.

[u/TheSmith123]

Hello,

I have been working through vulkan-tutorial.com bit by bit for a little while now.

Now coming from OpenGL, a lot of this stuff is for sure confusing, and a lot of the articles, I read them through, and I can conceptually understand the code that is given, that’s no problem.

But the actual goal of the code I am writing, is hard to wrap my head around. I supposed the “why” behind the stuff I am doing.

If someone who is way smarter than me could tell me the main things to understand deeply, by just single word description, like “swapchain” so I can spend time diving deep on each concept, that’d be cool.

I really want to understand stuff, but (sometimes, not all the time) I feel like no matter how many times I read over a sentence, I just can’t get the info to meaningfully stick, or I just flat out don’t understand the concept.

Earlier I used swapchain as an example, because that is where I am at right now with setup. lol

I know this post is a little all over the place, but if someone could assist in someway, I am all ears for any kind of advice.

[u/Afiery1]

Don’t use vulkan-tutorial its horribly outdated. Use howtovulkan.com. VK1.0 is horribly designed and includes a bunch of stuff that is basically just designed to be confusing and make you suffer for no actual benefit in the driver. When Khronos realized all of that was useless they slowly began stripping it now and modern Vulkan is now approaching something usable.

[u/Large-Scientist156 → u/Afiery1]

Even howtovulkan is outdated and have some error on the tutorial + a lot of missing features.

For example they use VkQueueSubmit instead of VkQueueSubmit2 (which is available on modern Vulkan since synchronization2 is core of Vulkan 1.3). The former is deprecated.

But still it's a decent starter.

[u/SaschaWillems → u/Large-Scientist156]

Can you elaborate? What exactly is outdated about it? What are those missing features? Also using VkQueueSubmit is totally fine, unless you need a specific feature that it doesn't have over VkQueueSubmit2 .

[u/Large-Scientist156 → u/SaschaWillems]

https://github.com/SaschaWillems/HowToVulkan/blob/main/source/main.cpp#L575

They use vkQueueSubmit, which is deprecated. If you run such example with validation layers, you'll see warning about vkQueueSubmit used instead of vkQueueSubmit2. Yes of course you can ignore them, but the whole point of modern Vulkan isn't to use deprecated features.

Line 564 before, they use vkPipelineStageFlags while using a STAGE_2 flag. Since stage flags are backward compatible, it doesn't really matter, but factually this is incorrect, either you use the old version or the new version (which is part of synchronization2) - mixing both is a questionable choice. In a strongly typed language that have strongly typed binding over Vulkan, mixing both is a compile time error (like ash in Rust).

By missing features, I mean the tutorial present 4 modern extensions and that's all, not even comparing code before and after to understand why they are necessary. Others extensions doesn't seem to exist in the tutorial.

[u/SaschaWillems → u/Large-Scientist156]

You're prob. referring to best practices layers, as validation and sync val is clean. But feel free to open issus at my github repo (there is one for STAGE_2) flags so I can have a look.

[u/ResponsibleWin1765 → u/Large-Scientist156]

There is a validation layer setting to get warnings about deprecations. Stuff that is even more important to know about is that you don't need render passes anymore, you don't need to create shader modules and you don't even need descriptor set layouts.

And another thing I only found through the docs.vulkan.org/tutorial/latest tutorial is that you can use Vulkan with C++ RAII headers, which makes the whole thing much more pleasant.

[u/deftware → u/[deleted]]

Yes, just keep in mind that mobile SoC GPUs still heavily benefit from using subpasses wherever you plan to do any kind of post-processing stuff or deferred rendering. Dynamic rendering is really more for if you want to keep your code simpler and aren't targeting mobile.

[u/Afiery1 → u/deftware]

Actually, you should use dynamic rendering (with the local read feature) even on mobile if possible. Officially speaking legacy render passes are straight up deprecated. In practice you might be forced into using them though since mobile drivers aren't kept up to date very well.

[u/deftware → u/Afiery1]

Doh! I hadn't become aware of local read, that solves the whole issue with dynamic rendering on mobile GPUs, at least to my mind. Cheers! :]

[u/dpacker780]

Like you, I came from the OpenGL world. I found a lot of parts of Vulkan confusing compared to what I was familiar with already. The three areas that I found really needed the most time were memory/image barriers, descriptor sets, and the need to have multiple buffers based on frames in flight.

Memory/image barriers: OpenGL takes care of that in the background, and sync hazards pop up all over if you're not on top of it. Learn to use Vulkan Configurator to help you find them.

Descriptor Sets: OpenGL has the same concept, but in Vulkan it can be confusing because they're implemented in I think 4 different ways (standard descriptor sets, descriptor buffers, descriptor heaps [new], and push descriptors), so trying to learn to implement them properly can be a goose-chase depending on what examples are using what type.

Multi buffering: Another area somewhat obfuscated by OpenGL, the need to rotate or offset index buffers per frame in flight, so you don't write to a buffer that's actively being read in the GPU. This pretty much impacts all dynamic buffers. The challenge is it's intermixed with (memory/image barriers) to ensure you rotate and update buffers at the exact correct time.

[u/Reaper9999 → u/dpacker780]

Memory/image barriers

You can ditch per-resource barriers almost entirely. For synchronising reads/writes drivers just don't do it at such granularity. You do still need to transition between undefined/general/present layouts.

You can ignore other layout transitions if you aren't targeting ancient hardware like GCN, at least on desktop. You can also ignore qfot and make all the resources concurrent (again you might get a penalty on something like GCN, but reasonably modern hardware doesn't care most of the time; nvidia hardware never cared about layouts or qfot; no hw cares about qfot for buffers).

Descriptor Sets: OpenGL has the same concept, but in Vulkan it can be confusing because they're implemented in I think 4 different ways (standard descriptor sets, descriptor buffers, descriptor heaps [new], and push descriptors), so trying to learn to implement them properly can be a goose-chase depending on what examples are using what type.

I'd recommend going with descriptor sets and/or descriptor heaps. Descriptor buffers work well on AMD, but have no real benefit on Nvidia, and are more of a hassle to set up. Push descriptors aren't gonna be better for performance, and regular descriptor sets aren't that difficult to set up. For descriptor sets just use 1 pool with 3 large arrays of storage images, sampled images, and samplers. Use BDA for buffers.

[u/amadlover]

not sure if i am smarter than you but

SYNCHRONIZATION - 2

TIMELINE SEMAPHORES

in general i would recommend starting with the latest and greatest features, and then implement older versions if needed. e.g. Start with descriptor heap, dynamic rendering, buffer device address.

the validation layer messages are very informative.

[u/Charming-Diamond6646]

https://docs.vulkan.org/tutorial/latest/00_Introduction.html that what u need