Vulkan Tutorial | Hacker News Reader

Vulkan Tutorial

vulkan-tutorial.com

47 pointsColinWright14 comments

I recommend https://vkguide.dev instead. It's opinionated towards modern rendering techniques, provides code for all chapters and after you complete it, you feel prepared to continue working on your own.

Having zero experience with Vulkan, and having touched OpenGL 15 years ago, I had to check out the "Hello World" aka draw a triangle on the screen.

What a doozy.

I'm wondering, with all boilerplate / config code that's needed to do something as trivial as drawing a triangle, how will this inspire beginners to get into this kind of development?

EDIT: I understand that ideally, Vulkan should work as middleware - abstracted away from the application layer devs.

Are there any good higher-level APIs for Vulkan, or game engines that use Vulkan? Or must everyone "roll out" their own?

godot is one

In a recent discussion (https://news.ycombinator.com/item?id=40595741) there were several pointers to libs that help reducing the boilerplate, namely vk-bootstrap, volk and vma.

If you've never done graphics programming before, I wouldn't recommend starting with Vulkan. I would start with WebGPU via either wgpu (Rust + various bindings), dawn (C++), or the browser (JS). Or do raytracing on the CPU.

Once you've made a fairly capable engine, have rewritten it 1-3 times and are very comfortable with it, and are looking at profiles and going "hmm I wish I could do X to optimize this but WebGPU lacks support for it", then I would learn Vulkan.

Vulkan (and DirectX12) are targeted at existing engine developers who want to optimize every aspect of the rendering engine. It's not a very forgiving API, and learning the API (and how to use it optimally) is just one aspect of graphics programming. There's also linear algebra and coordinate spaces, PBR rendering theory, etc. It's a very involved field that's quite different from other programming fields.

RE: Vulkan requiring thousands of lines of setup, I think some of it is fair and some of it is not. Extension handling is definitely fairly cursed imo compared to how DirectX12 handles it. Memory allocation is rarely something that needs manually writing, using VMA is plenty good for 99% of use cases. On the other hand, device, queue, and swapchain selection and synchronization are all important. Sure there's a "simple" path where you just select the first device, the main queue, and use the default swapchain choice, but it can get complicated. Transfer and compute queues are important, and are a bit involved in requesting. Swapchain pacing is complex to get right, and you may want to support HDR/WCG displays. Vulkan gives you a lot of control, which is overwhelming at first, but useful for a lot of people.

https://sotrh.github.io/learn-wgpu/

Wgpu is a Rust-based library that takes a similiar general API shape as Vulkan but is simplified. When I first tried to learn Vulkan I found the complication to be overwhelming (primarily because there are no defaults for ANYTHING) but once I learned wgpu it was substantially less so. It is still quite complicated though.

Wgpu is aiming to be almost as powerful as Vulkan, but it's not there yet because the features that are needed to do the modern techniques that make Vulkan really good (as compared to opengl) either aren't there yet or are so bug-ridden as to not be usable in practice yet.

It has some ability to run in a web browser, probably with JS, too, but I'm unfamiliar with the details there.

But then you have to fight with Rust.

WGPU, like Vulkan 1.0, requires setting up RenderPasses up front, which is verbose and laborious.

That is no longer needed in Vulkan 1.2 or newer, making it considerably simpler.

That eliminates some of its advantage over Vulkan in terms of simplicity.

It also lacks latest graphics features like mesh shaders and ray tracing.

Vulkan 1.0 expects you to configure render passes ahead of time because that’s the best way to get optimal performance on all hw. This especially matters for tiling architectures on mobile. It’s supposed to be a low-level API after all. The engine devs wanted no hand-holding and that’s what they got.

Now they find that’s too hard for them after all so dynamic rendering it is..

RenderPasses can give some perf gain on mobile tiler hardware, but they don't really help on desktop hardware.

A lot of content is ported from other APIs, and retrofitting render passes to an existing engine is not easy.

I'm hoping that accessing tile memory from compute shaders (like Metal's tile shaders) comes to Vulkan soon. That, together with the new pipeline barriers, will give all the benefits of render passes on mobile, but gets rid of the verbose up front setup of RenderPass.

The problem with Vulkan and the similar APIs is that the authors of the specification attempted to make an industry standard that would be easier to implement by the GPU manufacturers, but at the same time it would still be quite high level and abstract so that the end users could use it without care of how the devices work in too much detail.

The issue here is that if the users chose Vulkan, they probably do care about these details, but the API makes it totally obscure for them if they don't have prior experience with the GPU architectures.

At the same time the API is too low level for other users who want to just start drawing polygons on the screen here and now like they did with OpenGL.

Uncanny timing.. I was just looking into Vulkan and finished the first couple tutorials on here.

The tutorials are missing quite a bit of information if you're following them on Linux (seem to refer to files/includes that don't exist). Be prepared to do digging on your own...

I've been debating between using opengl or vulkan for some simple games I have been thinking about making.

I followed this. And would recommend vkguide.dev for several reasons. The code here is "clean code" pointlessly abstract void fin(void) so each call is a mystery as to what it does. I came away from it asking, why do I do these things?

Reply on news.ycombinator.com