Hacker News new | ask | show | jobs
by anvuong 213 days ago
Vulkan was one of the hardest thing I've ever tried to learn. It's so unintuitive and tedious that seemingly drains the joy out of programming. Tiny brain =(
5 comments

You don't have a tiny brain. Vulkan is a low-level chip abstraction API, and is about as joyful to use as a low-level USB API. For a more fun experience with very small amounts of source code needed to get started, I'd recommend trying OpenGL (especially pre-2.0 when they introduced shaders and started down the GPU-programming path), but the industry is dead-set on killing OpenGL for some reason.
> I'd recommend trying OpenGL

Tbh, OpenGL sucks just as much as Vulkan, just in different ways. It's time to admit that Khronos is simply terrible at designing 3D APIs ;) (probably because there are too many cooks involved)

Vulkan is definitely a major pain and very difficult to learn... But once you've created an init function, a create buffer function, a create material function etc which you do once you can largely then just ignore it and write at a higher level.

I don't like Vulkan. I keep thinking did nobody look at this and think 'there must be a better way' but it's what we've got and mostly it's just learn it and write the code once

Does anyone know why the industry is killing OpenGL?
People wanted more direct control over the GPU and memory, instead of having the drivers do that hard work.

To fix this AMD developed Mantle in 2013. This inspired others: Apple released Metal in 2014, Microsoft released DX12 in 2015, and Khronos released Vulkan in 2016 based on Mantle. They're all kind of similar (some APIs better than others IMO).

OpenGL did get some extensions to improve it too but in the end all the big engines just use the other 3.

OpenGL cannot achieve the control over modern hardware necessary to get competitive performance. Even in terms of CPU overhead it’s very limiting.

Direct3D (and Mantle) had been offering lower level access for years, Vulkan was absolutely necessary.

It’s like assembly. Most of us don’t have to bother.

When I first tried to learn Vulkan, I felt the exact same way. As I was following the various Vulkan tutorials online, I felt that I was just copying the code, without understanding any of it and internalizing the concepts. So, I decided to learn WebGPU (via the Google Dawn implementation), which has a similar "modern" API to Vulkan, but much more simplified.

The commonalities to both are:

- Instances and devices

- Shaders and programs

- Pipelines

- Bind groups (in WebGPU) and descriptor sets (in Vulkan)

- GPU memory (textures, texture views, and buffers)

- Command buffers

Once I was comfortable with WebGPU, I eventually felt restrained by its limited feature set. The restrictions of WebGPU gave me the motivation to go back to Vulkan. Now, I'm learning Vulkan again, and this time, the high-level concepts are familiar to me from WebGPU.

Some limitations of WebGPU are its lack of push constants, and the "pipeline explosion" problem (which Vulkan tries to solve with the pipeline library, dynamic state, and shader object extensions). Meanwhile, Vulkan requires you to manage synchronization explicitly with fences and semaphores, which required an additional learning curve for me, coming from WebGPU. Vulkan also does not provide an allocator (most people use the VMA library).

SDL_GPU is another API at a similar abstraction level to WebGPU, and could also be another easier choice for learning than Vulkan, to get started. Therefore, if you're still interested in learning graphics programming, WebGPU or SDL_GPU could be good to check out.

You don't have a tiny brain--programming Vulkan/DX12 sucks.

The question you need to ask is: "Do I need my graphics to be multithreaded?"

If the answer is "No"--don't use Vulkan/DX12! You wind up with all the complexity and absolutely zero of the benefits.

If performance isn't a problem, using anything else--OpenGL, DirectX 11, game engines, etc.

Once performance becomes the problem, then you can think about Vulkan/DX12.

What about new features? There are many small features that can't be used via older APIs and bigger ones like accelerated ray tracing.
Sure, but then you've already thrown away the possibility of using "simpler" APIs that everybody is whining that DX12/Vulkan is more complicated than.

Programmers should absolutely not be using DX12/Vulkan unless they understand exactly why they should be using it.

Exactly the reason why I haven't switched from OpenGL to Vulkan. Vulkan is just ridiculously overengineered. Cuda shows that allocation of GPU memory and copy from host to device can be one-liners, yet in Vulkan it's an incredible amount of boilerplate to go through. Modern Vulkan fixes a lot of issues, like getting rid of pipelines, render passes, bindings, etc., but there is still much more to fix before it's usable.
I think anyone who ever looked at typical Vulcan code examples would reach the same conclusion: it's not for application/game developers.

I really hope SDL3 or wgpu could be the abstraction layer that settles all these down. I personally bet on SDL3 just because they have support from Valve, a company that has reasons to care about cross platform gaming. But I would look into wgpu too (...if I were better at rust, sigh)

Yep. Most of the engine and "game from scratch" tutorials on Youtube, etc, use this style of having OpenGL code strewn around the app.

With Vulkan this is borderline impossible and it becomes messy quite quickly. It's very low level. Unlike OpenGL, one really needs an abstraction layer on top, so you either gotta use a library or write your own in the end.

For wgpu, someone else mentionned in another comment that there are bindings for other languages, maybe your favorite too!