The idea was probably "built it and they will come" (the library authors who provide the easier to use wrapper libraries). The problem is that these libraries are hobbyist/volunteer work (with the notable exception of native WebGPU implementations), which on its own isn't a bad thing, but hobbyist can't afford a testing lab running hundreds of GPU/driver/OS combinations to make sure that their libraries are as robust as expected.

The companies who have these resources (for instance the GPU vendors), chickened out by designing Vulkan and thus offloading those QA tasks to the API users (simplified, but that's what it is in the end).

Which leaves Unity, Epic, and a handful AAA game developers as potential Vulkan users, which in turn are not enough to test Vulkan implementations, because just a handful API users isn't enough to cover all the dusty corners (same situation as back in the bad old days with MiniGL).

> Which leaves Unity, Epic, and a handful AAA game developers as potential Vulkan users

??? For example, there are a substantial number of emulators that have already implemented or are in the middle of implementing a Vulkan backend: RPCS3, Dolphin, Yuzu, Cemu, Ryujinx, PPSSPP... these emulators are developed by small teams but often push the hardware hard, bringing bugs to light in the process.

Also DXVK and VK3D.

Yeah exactly. Vulkan is meant to be the lowest level interface possible to the hardware. It's for programmers who hitting a wall in terms of optimization because of the overhead imposed by OpenGL or DX11. It's not intended for everyday programmers, and it would not make sense to make concessions in performance to accommodate usability concerns.

But the thing is that Vulkan isn't the lowest possible hardware interface, it's still built on top of a virtual GPU abstraction which matches some GPUs better than others. There's a ton of compromises to accomodate mobile GPUs for instance. The only realistic way to achieve the goal of an actually low-level API is to have one API per major GPU architecture, and to create new APIs when new GPU architectures emerge. Attempts to abstract over radically different GPU architectures will never result in an actually explicit low-level API.

Ok yeah that's technically true, but there's always going to be a balance point. You can't expect graphics programmers to write a separate renderer for each possible hardware target. That kind of works in the console space, but in the PC space you have to account for a wide variety of hardware.

There's always going to be a balance point, and Vulkan's priority is much more about getting as low-level as possible within the constraints than it is about being approachable for developers.

> it's still built on top of a virtual GPU abstraction which matches some GPUs better than others.

Doesn't khronos contain people from a bunch of different corps (amd, nvidia, intel, qualcom) for this exact reason.

Yeah, but that doesn't seem to have helped much to keep the Vulkan API small and tidy, instead there are dozens (or maybe hundreds by now?) of vendor-specific extensions.

I think this is vastly overstated. I've done quite a bit of work for Vulkan, and have done just fine without reaching for extensions.

And how else do you propose accessing hardware features which are vendor specific?