Yes. WGPU is often being used as a common layer to abstract Vulkan, Apple's Metal, and Microsoft's DX12, which do pretty much the same thing.

Modern 3D graphics programming mostly abstracts to:

- Load standard gLTF shaders into GPU.

- Create mesh objects. Send to GPU.

- Create texture maps. Send to GPU.

- Create light objects. Send to GPU.

- Create 4x4 transform matrices. Send to GPU.

- Create objects referencing meshes, textures, and transforms. Send to GPU.

- Create camera transform matrix. Send to GPU.

- Tell GPU "Go!".

Beyond that, it's mostly special effects, such as atmosphere, lens flare, etc.

Most of the headaches today involve managing the memory in the GPU, for which there are libraries.

Small nitpick: 'WGPU' is somewhat ambiguous because it could refer to either WebGPU itself, or wgpu[1] which is a library implementing a derivative of the WebGPU API that can be used by native code.

[1]: https://docs.rs/wgpu

I'm thinking mostly of the latter, which is useful for cross-platform work.

Khronos keeps not having an idea how to make APIs not full of extensions and low level SDK tooling.

Big players have always used their own 3D APIs since the dawn of 3D graphics.

I don't think it's entirely khronos support as basically each vendor what's to embrace, extend and extinguish it constantly.

CUDA is kind of winning it for nvidea.

Sure it is, not even LunarG's SDK is at the same level as proprietary API SDKs in frameworks, debugging, IDE integration, beyond the basics.

CUDA is winning on compute exactly because of that as well.

You think the big players don’t (didn’t) use OpenGL, Vulkan, DX, etc?

Sony definitely not, Nintendo to some extent after GX, Apple only after adopting NeXTSTEP (QuickDraw 3D was their thing), Microsoft alongside NVidia and AMD design first for DX, then the features get ported into GL/Vulkan as extensions,...

I’m not sure what you mean but big players typically means AAA studios and they don’t create their own graphics drivers and their engines are build on top of the aforementioned systems.

When you look at how much nicer the programming experience is for something like Metal it’s hard to blame them.

Think I’d prefer to write 3 backends for Metal level complexity APIs than a single one targeting Vulkan.

Yes, so much this. It’s like someone looked at OpenGL and said, “Hey, how can we take all the hard, ugly, terrible parts of OpenGL and throw out all the nice, useful parts?” And that became Vulkan. I’ve written code for OpenGL since the 1.0 days. These days I do Metal. I wanted to check out what it would take to port something to Vulkan. I couldn’t make it through the basic Vulkan tutorial of putting a single triangle on the screen. It was too long, and required too many really low-level things. It felt almost like you needed to write your own memory allocator to use it properly. It was nuts.

Worse part is that Khronos doesn't seem to get it, as with OpenGL, they expect the community to come up with ways to fix it.

There are some steps into that direction with LunarG SDK efforts, NVidia was the one coming up with C++ bindings, but that is mostly it.

Nothing as nice out of the box as the proprietary APIs.

A guy from a studio I know has best described it, as one needs to be a graphics developer and a device driver expert to properly code against Vulkan.