Vulkan is for writing OpenGL-type libraries against. It's advantage is largely that much of the library-level code is moved out of opaque and buggy device drivers and into user-space libraries.
The terrible terrible Vulkan API just kind of feels gatekeepey. They got rid of the only open easy-to-use graphics standard, made NO REPLACEMENT, and then said "oh you should just use this impossible API or let the outside world come up with a fix around it".
And use some high level library like vk-bootstrap to do the boring init work.
Because once it's set up, Vulkan 1.3 is about as easy as OpenGL (if you stick with OpenGL-level stuff).
It is easier than WGPU because the RenderPass stuff required in Vulkan 1.0 (and hence WGPU) is gone, removing a lot of boilerplate code.
Pipeline barriers are the only "complex" thing remaining but even they are somewhat simplified with the right defaults (sharing mode) and simplifications (set stage masks to all commands, overhead is negligible on desktop devices).
Use push descriptors for "bindful" textures, set all your pipelines states dynamic (except blending), and timeline semaphores for sync.
For simple stuff (OpenGL level) it's a pleasure to work with, and you get rid of all the OpenGL quirks.
Complex stuff like bindless texturing and GPU driven rendering is still complex, but that's the same in all APIs.
It can still be a bit verbose and the init code is too much work (but you do it only once), but after it is set up it's quite okay.
And if you want OpenGL, use OpenGL. Zink (OpenGL on Vulkan) guarantees that it will be supported, even if GPU vendors stop keeping their GL drivers up to date (has not happened yet).
Why do you need Khronos to "bless" a particular library anyway?
Also they didn't get rid of OpenGL. You can still use it. It will probably be the most widely supported graphics API for a long time.
I guess we'll have to agree to disagree on that.
> There's no evidence they'd be good at it and if you look at their GitHub, they're not particularly good at maintaining actual codebases in the first place.
Well that's another complaint then, but it doesn't detract away from my initial complaints.
> Why do you need Khronos to "bless" a particular library anyway?
Because now we're going to have a million different wrapper libraries to do everything, or you're going to be stuck with the absurd Vulkan API. It was already annoying enough that you had to have different wrappers to abstract the GUI components, now people have to have another mediocre abstraction in addition to the GUI crap.
I suppose you could argue "that's fine", and you're free to have that opinion, but I think it's worse
> Also they didn't get rid of OpenGL. You can still use it. It will probably be the most widely supported graphics API for a long time.
They're not doing new versions of OpenGL. Yes, the drivers will support them for the foreseeable future but they will get increasingly out of date.
The more things change...
Fact is that most people will never directly touch such things unless they are a) a graphics programmer at a handful of companies or b) someone like this author doing something more for education than to produce raw business value. our "high level libraries" are Unity and Unreal if you're makinig a game (and some smaller engines), and BGFX et al. if you're making your own small engine. The work is already done without Khronos lifting a finger for implementation.
the recipients of a) are the ones who asked for more control. They are paid pretty well so they have plenty of time to grok the specs compared to a small time creator, so rapid prototyping isn't prioritized.
The "NO REPLACEMENT" is sidelining ugly OpenGL drivers and adopting leaner and more modern Vulkan drivers.
I don't know how this lie caught on so well, but it doesn't pass the smell test.
_Vendors_ did it poorly, which is why everyone wanted to get away from them. You could argue they over-corrected and left _too_ much to the user, but better safe than sorry.
Sure users can write bad code as well, but at least it's _consistently_ bad, and fully under their control. There are so many fewer problems nowadays like "oh it works on my desktop, but on this older intel GPU for a user with outdated drivers it segfaults in the driver, and there's nothing we can do to fix it ourselves".
Implying that up to date Intel drivers don't segfault on perfectly valid OpenGL use.
We don’t need to speculate whether hardware vendors can ship bullet proof drivers and API implementations, they have already proven they can’t. Vulkan was built based on industry experience from organisations big enough to sit at the Khronos table. They were trying to give the vendors as little rope to hang themselves on by reducing the complexity of driver implementation because these stakeholders (large AAA studios) were collectively expending massive resources working around vendors inability to ship good quality drivers. This problem is still ongoing even with Vulkan.
Vulkan drivers on Android are a complete joke. They barely work and I’m debugging and working around a new driver bug or performance trap every few weeks at this rate. If we can’t rely on quality Vulkan drivers, an API designed to make drivers easier to implement, how will vendors fare with a much more complex to implement API like OpenGL? (poorly, look up the history of OpenGLES3).
Desktop PC is the exception because it’s the only GPU market where hardware vendors have real market pressure to deliver working drivers. Just look at Intel’s Arc launch, a product where it’s single biggest criticism and flaw citied universally is driver issues. There is no other market where this same pressure has been applied. Nobody bought a phone specifically because it had “good GPU drivers”. Unless the hardware market a vendor is selling to cares garbage drivers are the default. Qualcomm and Arm provide more than enough proof for that.
I don't know about any conspiring, but I've thought about that comment often, because the result appears the same: The barrier to in-house game engine development has been risen further.
Not really a conspiracy so much as the fact that Unity/Epic have much more opinions on what a graphics library can/should be than a small engine developer. The former don't care if it takes longer to release games, they have staff around the clock working on the engine.