Perhaps that is the problem, for any new general GPU API to get industry traction, driver, and os + tool support -takes a lot of time, and it feels obsolete by the time it is put to practical use.
Perhaps that is the problem, for any new general GPU API to get industry traction, driver, and os + tool support -takes a lot of time, and it feels obsolete by the time it is put to practical use.
- it inherited the 'vendor extension mess' of GL, e.g. the development process of Vulkan is to let GPU vendors write extensions which are eventually declared as 'core', this sort of 'design by committee^H^H^Hvendor' approach will ineviatably result in a hot mess of an API after a couple of years
- it tried to cover the whole range between low-end mobile and high-end desktop GPUs with the same API, pretty much all design warts of Vulkan exists because it had to cover mobile GPU architectures that were already outdated with Vulkan 1.0
At least Khronos is aware now about the issues, question is whether it will result in any actual improvements, and how long that will take:
Additionally yes, traction has been pretty weak too. It's still a wrapper on iOS/Mac and slower than DX12 on Windows. When you want something easy and crossplatform use OpenGL, and if you're really going to max out perf, then you use DX12 and Metal(which tbh might be easier than Vulkan too), so Vulkan's in a kinda awkward place.
With Vulcan, with what I've seen, this would have been a major endeavor just to get to the point where you can get a canvas so you can put some pixels on the screen as you have to do a whole lot of state setup and bookkeeping. Not really something you can wrap as a relatively simple python API for someone to do quick experiments with.
I did some other completely random, definitely not recommended, stuff in Blender like this camera motion tracking thing which would rotate the viewport as the camera moved and have the camera video as the background (also using the python GL module) to reproduce this paper I found on the interwebs. I also found the Clippy sprite sheet but decided that was probably a bridge too far even though it wouldn't have been too hard.
So, yeah, if you want your program to be crazy extensible a simple API is probably the best. Might not matter too much these days as you can just get the robots to do the hard work.
[0] I heard they were going to rip it out but haven't checked if they ever did
Yes, it takes way more code to start from scratch on vulkan, but that's a trade-off against being able to better optimize exactly to your use case, if you need to.
I understand there are situations where more performance is desirable and that vulkan fills that niche. However if you are building simpler games, are you really going to need it? If I am building say a puzzle game, do I really need maximum 3D graphics fidelity and performance? I would argue probably not.
I am using OpenGL in my projects for now and if I feel the need to learn Vulkan I will. Almost all the materials online for OpenGL 3.3 are still relevant and unlike web world (where things are depreciated every 6 months) the code still works fine. The C++ linter / analysis tools I am using with CLion throw up warnings but these are normally fairly easily to fix.