[cogman10]

I don't think it's a mistake, I think it's targeted and leveraged poorly.

Vulkan is a great idea for a general game engine or backing something like OpenGL. It's a low-level abstraction that should allow you to do something like use OpenGL 8.0 on a GPU that has long lost support for from its manufacturer.

[jms55]

Exactly this. Vulkan, especially Vulkan 1.0, was never really meant directly for graphics developers. It was meant specifically for engine developers that didn't want to have to deal with buggy and inconsistent drivers, e.g. Nvidia vs AMD vs crappy Android phones.

The solution Vulkan came up with was "make everything as explicit and user-controlled as possible", and leave "implementing a more user friendly driver" up to user-space, so that it could be tweaked by users, wouldn't be tied to driver updates users would never do, would be consistent across platforms, etc.

Except that never really happened. There are some graphics-driver-as-a-library projects (daxa, nabla, etc), but none with a large amount of community support.

Meanwhile GPU's evolved over time (AMD RDNA1, Nvidia Turing, Intel Arc, Apple Silicon), and it turns out that some of the choices Vulkan 1.0 bet on weren't great (explicit extensive pipeline state, binding model, render passes).

Vulkan 1.2/1.3 cleaned up a lot of this (dynamic state, descriptor indexing, sync v2), which also happens to improve ergonomics a lot to the point that it's much less painful to use Vulkan directly nowadays, as long as you're ok dropping support for older platforms.

[johnnyanmac]

>There are some graphics-driver-as-a-library projects (daxa, nabla, etc), but none with a large amount of community support.

That's more on the community then, no? Same issue as OpenGL; most of the market is Windows or consoles, Windows/consoles have their own graphics api and professional suppport, the devs choose convinience over control and cross-compatibility.

Seems like a self-furfilling prophecy if devs relinquish their control to the corporations.

[nextaccountic]

What happened was wgpu, which runs on top of Vulkan and can also run on the web as web gpu

Many Rust programs are written against wgpu rather than Vulkan

[jms55]

I develop a lot of the more advanced features for Bevy, so I'm fully aware :)

The unfortunate reality is that wgpu does not have enough funding. Extremely valuable features like bindless, multi queue, and mesh shaders/raytracing are missing. CPU-overhead is fairly high. Things like debugging support are not great. Having to abstract over all of Vulkan/DX12/Metal brings difficulties.

I love wgpu, and don't begrudge the volunteer devs (they've done a lot of amazing work already), but I'm also frequently frustrated by its limitations.

[nextaccountic]

Oh nice!

Lots of people say that wgpu is lacking in comparison to vulkan (specially because it has gpu features from circa 2015), but how do you compare it to opengl?

[jms55]

It's better than OpenGL 3 in my opinion. It has a much saner API, is a lot more predictable, and API calls can be made from multiple CPU threads.

OpenGL 4 has some more advanced features like bindless that WebGPU lacks (and Vulkan has), but I wouldn't use OpenGL because of that.

My recommendation is start with WebGPU if you're new to graphics programming. Once you're at the end point where you have a bunch of working features and have optimized your engine as much as you can, and are starting to push against WebGPU limits, then I would think about switching to Vulkan 1.3 / DirectX 12.