Vulkan Tutorial

by ColinWright • 2 years ago

47 14 2 years ago

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.

john01dav• 2 years ago

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.

adrift• 2 years ago

But then you have to fight with Rust.

exDM692• 2 years ago

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.

ginko• 2 years ago

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..

EvilLemon2• 2 years ago

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.

EvilLemon2• 2 years ago

TrackerFF• 2 years ago

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?

kragen• 2 years ago

godot is one

ofrzeta• 2 years ago

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.

whatsakandr• 2 years ago

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?

Eliah_Lakhin• 2 years ago

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.

jms55• 2 years ago

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.

Vulkan Tutorial

Related Stories