[pjmlp]

I used to be big into Khronos API camp, even did my project thesis in OpenGL, up to the famous Long Peaks fail.

Vulkan ended up being the same extension spaghetti as its predecessor, and Khronos was only able to come up with something thanks to AMD offering Mantle, C++ bindings and a GLSL successor only came to be thanks to NVidia (Vulkan-hpp and Slang started at NVidia).

The "we build the specification", and then "the community builds the tools", leads to very poor experiences, and if it wasn't for LunarG own interests, there wouldn't even exist any kind of Vulkan SDK.

What they have going is naturally the vendor independence, however we can achieve the same with middleware with the benefit of much better developer experience.

[DiabloD3]

I love how people say things like "extension spaghetti", as if all other non-standard APIs have the same problem: hardware gets new features that people want to use from that API, API gains extension to use that hardware feature.

CUDA is no different, in fact, often worse. Nvidia is bad at documenting which hardware does what things, and CUDA users often have to use third party tables to figure out what hardware can't do what and disappoint customers who unwisely invested into it.

[pjmlp]

The other platforms have better ways to deal with progress instead of "here find entries on dynamic libraries by yourself", and good luck.

Profiles and API versions are much better approaches.

It is no accident than the ongoing efforts to make Vulkan more friendly are moving away from extension spaghetti into profiles.

[xyzsparetimexyz]

If you think that Vulkan is extension spaghetti you're clearly using it wrong. Set the API to 1.4 and many existing extensions get merged in.

[pjmlp]

If you think changing to Vulkan 1.4 solves all the problems, you clearly aren't writing cross platform code.

First of all, that isn't even a thing if you need to target Android, or embedded hardware, secondly there are other extensions on the horizon.

[xyzsparetimexyz]

The vast majority of vulkan usecases aren't android or embedded. I indeed wouldn't recommend it there.

[pjmlp]

Without Android and embedded, its market is mostly SteamaDeck and some universities for the most part.

Nintendo, PlayStation, Apple and Microsoft have their own APIs.

Visualisation industry is still largely on OpenGL, when not using middleware that uses each platform proprietary API, or moving into compute like CUDA as OTOY has done.

Khronos had to come up with ANARI, to convince them to even think about Vulkan in first place.

[xyzsparetimexyz]

Moving the goalposts much? Linux and Microsoft is still a huge market. Ii don't know about the switch 2 but the switch 1 had vulkan support. Apple as well if you count moltenvk

[pjmlp]

Not at all, I mentioned where Vulkan actually has a market, and why using Vulkan 1.4 is not the solution you think it is.

There is hardly any commercial Vulkan market on Windows, with exception of tools like Autodesk VRED or Disney Hyperion, hardly every man tools and the reason one might use desktop Linux for 3D rendering instead, with proprietary drivers anyway. As a user, not developer.

List of commercial games on Windows using Vulkan, without having a DirectX 12 backend as option is pretty thin.