OpenGL is going to live a long life simply because Vulkan is way more complex and overengineered than it needs to be.
It pretty much is by now if you can use Vulkan 1.4 (or even 1.3). It's a pretty lean and mean API once you've got it bootstrapped.
There's still a lot of setup code to get off the ground (device enumeration, extensions and features, swapchain setup, pipeline layouts), but beyond that Vulkan is much nicer to work with than OpenGL. Just gotta get past the initial hurdle.
Just directly talking to the C API in the tutorials/examples instead of custom wrapper code would be a lot more helpful since you'd don't need to sift through the custom abstraction layers (even if it would be slightly more code).
E.g. have a look at the code snippets in here and weep in despair ;)
https://docs.vulkan.org/tutorial/latest/03_Drawing_a_triangl...
Trying to obfuscate all the options goes against what Vulkan was created for. Use OpenGL 4.6/WebGPU if you want simplicity.
And the rest of the API is full of similar examples of wasting developer time for the common code path.
Metal is a great example of providing both: a convenient 'beaten path' for 90% of use cases but still offering more verbose fallbacks when flexibility is needed.
Arguably, the original idea to provide a low-level explicit API also didn't quite work. Since GPU architectures are still vastly different (especially across desktop and mobile GPUs), a slightly more abstract API would be able to provide more wiggle room for drivers to implement an API feature more efficiently under the hood, and without requiring users to write different code paths for each GPU vendor.
Also, CUDA is targeting a single vendor, whereas Vulkan is targeting as many platforms as possible.
Between OpenGL ES 3.1 and Vulkan 1.1, I would certainly go with OpenGL ES.
Vulkan is also trying to expose as many options as possible so as to be extensible on as many platforms as possible. Also, Vulkan isn't even trying to make it more complex than it need be--this is just how complex graphics programming is period. The only reasons people think Vulkan/DX12 are overly complicated is because they're used to using APIs where the majority of the heavy lifting comes from the drivers.
Tbf, the distinction between rendering and compute has been disappearing for quite a while now, apart from texture sampling there isn't much reason to have hardware that's dedicated for rendering tasks on GPUs, and when there's hardly any dedicated rendering hardware on GPUs, why still have dedicated rendering APIs?
More traditional rendering APIs can then be build on top of such a "compute-first-API", but that shouldn't be the job Khronos.
Note that it's not always better. The task shaders are quite hardware specific and it makes sense to ship defaults inside the driver.
Actually, it would be kinda neat to see an API that's fully designed assuming a coherent, cached, shared memory space between device and host. Metal I guess is closest.
Desktop GPUs. Tiling GPUs are still in use on mobile and you can't use the tiling hardware effectively without baking the description into pipelines.
> You could cut things down a ton with a new API.
VK_KHR_dynamic_rendering is what you are looking for
> Actually, it would be kinda neat to see an API that's fully designed assuming a coherent, cached, shared memory space between device and host.
You can just ask for exactly that--even on Vulkan. If you don't want to support computer systems that don't support RBAR, you can do that.
Have you used Vulkan? Specifying required hardware support for your physical device is literally one of the first thing you do when setting up Vulkan.