https://howtovulkan.com/
haven't reviewed it in depth, but the author is credible
#Modern Vulkan tutorial
supple jungle
limpid dawn
Pleasantly compact at least
hollow lion
Credible author, Vulkan, and compact? Sounds awesome, thanks for sharing! I'll save it for my next Vulkan project; currently using wgpu
slim leaf
Had a quick scroll through, and it looks like it's using all the modern features you should use IMO:
- dynamic state for viewport and scissor
- dynamic_rendering
- slang
- VMA
Though it's still using vertex attributes instead of vertex polling, and I'd love to see a bridge from here to descriptor indexing / bindless
vague river
Lovely
Oh, it's Sascha! Excellent
tl;dr: Doing Vulkan in 2026 can be very different from doing Vulkan in 2016. That's what I hope to show with this.
🙏
supple jungle
Had a quick scroll through, and it looks like it's using all the modern features...
I stand by VMA being a big complex solution in search of a problem
cobalt meteor
Having read over the tutorial, I think there are some other things that are interresting:
- VK_EXT_swapchain_maintenance1: Enables you to defer swapchain re-creation when the windows has changed dimensions. This allows for smoother resizes (when the user is dragging the window size) and also only need you to re-create the swapchain image once (when the user finished the resize).
- VK_KHR_unified_image_layouts: This greatly simplifies image layout handling and removed also a lot of image barriers. In particular, it guarantees that using the VK_IMAGE_LAYOUT_GENERAL layout everywhere possible is just as efficient as using the other layouts.
- VK_EXT_shader_object: This was mentioned in the article as a side note, but I think this is essential feature, since it removed pipeline for all non raytracing stuff. It's the logical evolution to VK_KHR_dynamic_rendering.
- VK_KHR_push_descriptor: Like push constants, but for descriptors. Really helpful for cases where you dynamically need to bind something on the fly.
- VK_EXT_descriptor_buffer: This one is big and in my eyes essential to use for modern Vulkan renderers. It's used heavily for example in Proton. With this extension descriptors are just plain memory and updating them is a simple memcpy. This greatly simplified descriptor handling for me (This enables me to have a derive macro that implements all descritor code automatically for me).
I also want to throw in this thought: The article suggest using resources for each frame that would allow you to work on the N+1 frame while the GPU is rendering N. I don't like this pattern very much, since it complicates the code and also leads to resource bloat. I found the approach that WGPU uses much easier to reason and work with: Stage all changes to your resources in a linear staging buffer and use timeline semaphores to synchronize the access to the staging buffer. In my tests this was equally performant.
supple jungle
pretty sure shader_object is a legacy glism, would not recommend
swapchain_maintenance1 isn't implemented widely enough to be any use
bindless patterns render most of the more complex descriptor shenanigans moot and are more widely supported besides
huge fan of timeline ring buffers for transferring stuff though, those are a dream
cobalt meteor
pretty sure shader_object is a legacy glism, would not recommend
I do not think this is the case at all. When you read the Vulkan documentation‘s problem statement, they explain that the design rationale around pipelines have not been found realistic. They also explicitly state that the extension is not just for legacy applications.
hollow lion
Oh, it's Sascha! Excellent
Oh I didn't even notice. Damn. His name wasn't on any of the pages I checked, I didn't think? I had to open the repo. Him of all people creating something like this is an absolute godsend
hallow violet
Oh I didn't even notice. Damn. His name wasn't on any of the pages I checked, I ...
fwiw his name is in the footer in the copyright message, but yeah I think it could be more prominent, it's nice to know the who the author of stuff is generally
vague river
I stand by VMA being a big complex solution in search of a problem
ZING high five
vague river
I do not think this is the case at all. When you read the Vulkan documentation‘s...
Seconding that it's for legacy applications, after speaking with LunarG employees at Vulkanised about this last year!
vague river
ZING *high five*
The problem I think it solves is "I didn't have to think about this in OpenGL/DirectX 11"
slim leaf
I've just been using VMA / gpu-allocator crate so I never have to worry about my allocations. I feel like before considering implementing my own allocator, I should probably start using a per-frame bump allocator or ring buffers for uploading data 
vague river
I've just been using VMA / gpu-allocator crate so I never have to worry about my...
Ralith (obviously) has some really nice implementation of a staging ring and some other helpful Vulkan stuff over here. Really recommend checking it out for inspiration for writing your own:
supple jungle
I've just been using VMA / gpu-allocator crate so I never have to worry about my...
that's kind of the point -- once you've thrown together a few simple patterns that address your actual requirements, you'll suddenly find VMA isn't actually doing anything for you any more, and your code is simpler and faster besides!
a reasonable conventional renderer has little to no use for malloc style "allocate any amount of anything any time" behavior
hallow violet
fwiw I think part of the benefit of vma and gpu-allocator is simply determining and using the correct memory type. It's not hard code to write but, like other stuff in vulkan, its additional verbosity
supple jungle
it's like five lines that you write once!
a single VMA call is more code than that
hallow violet
yeah but doing any one thing in vulkan isn't really that many lines of code, it just adds up. I don't use those libraries, but I'm sympathetic to people learning vulkan for the first time who don't want to have to figure that out