> Vulkan and OpenGL both already support mesh shaders, which is a compute-oriented alternative to the traditional rasterization pipeline.

Mesh shaders are a step in the right direction, but they are still embedded in all that unnecessary Vulkan fluff. I would want these things in CUDA because it does the opposite approach of Vulkan - it makes the common things easy, and the hard/powerful things optional. Just let me draw things directly in CUDA, and maybe give access to the hardware rasterizer via a CUDA call.

> CUDA [...] makes the common things easy

Only if the common thing does not include running on hardware of more than one vendor. Which is a pretty common requirement for any consumer software.

You're missing the point. CUDA is easy but also powerful, and it shows there is no reason that other APIs need to be hard and cumbersome.

> Overstatement of the year award candidate.

I think he meant development overhead, not performance overhead.

Yes, sorry for the confusion. I'd just rather have an API where the common things are easy, and the super powerful low-level optimizations are optional.

There were several pushes to produce a "sane defaults" library that made vulkan a lot less verbose.

OpenGL is exactly what you said, "an API where the common things are easy, and the super powerful low-level optimizations are optional."

except the easy common things are very slow, and the optimizations which are basically required become a careful dance of understanding the underlying hardware interface anyway (without any real documentation) and figuring out how to map that onto the high-level interface.

You could always just use a library that simplifies Vulkan or keep some skeleton apps around. When you're past all of the verbose set up, the actual meat of it isn't too bad.

What happened is that Khronos Group banked on third parties writing OpenGL-esque "middleware libraries" that bridged the gap between the hopelessly complex Vulkan API and people who want to write simple 3D graphics. Unfortunately, Khronos learnt the hard way that you can't just expect people to do work for you without a sufficient incentive, since after all, OpenGL still exists for anyone who wishes to have an easy API for graphics programming, and anyone who doesn't want to do that just uses an engine or high-level graphics API.

Of course I'm not saying that these libraries don't exist, but they haven't taken off in the way they expected

> who wishes to have an easy API for graphics programming, and anyone who doesn't want to do that just uses an engine or high-level graphics API.

I'm guessing this niche is just pretty small in commercial sense; most people probable end up just using UE/Unity/... as their graphics API.

I agree, so I think Khronos expected the open source community to fill in the gaps

* ... a compute-oriented continuation of the practice where they take the average of Nvidia and AMD's implementations, and then force the developer to deal with the overhead of harmonizing the details without going insane.

GPU compute is awful, almost as bad as GPU rendering.