[pjmlp]

Yes they are.

HN folk doesn't like to hear it, but that is how the game industry has worked since the early 80's where each gaming platform was a special snowflake.

There is a thriving industry of game engines and middleware that grew from there and the majority of game studios doesn't spend more than the time required to select which middleware they want to use.

Even for those that build their own engines, the graphics abstraction layer is a tiny portion of the engine, versus everything else that isn't covered by Khronos standards. Meaning GUI support, font, texture and shaders loading, mesh rendering, scene descriptions, game editors,....

Usually adding a new rendering backend to an engine doesn't take more than around one month, the biggest time slice being consumed by time to first triangle.

Given that Vulkan specification already has 74 extensions and is only at version 1.0.42, already bringing up the fun of "write once, port multiple times" from OpenGL, I am not confident this is going anywhere.

https://www.khronos.org/registry/vulkan/specs/1.0-extensions...

[exDM69]

> Given that Vulkan specification already has 74 extensions and is only at version 1.0.42, already bringing up the fun of "write once, port multiple times" from OpenGL

This is a dishonest and decieving way of putting things.

The difference between Vulkan and OpenGL here is that most of the functionality extensions are software only additions and are available everywhere with up-to-date drivers.

Mobile is a bit of a pain point because they don't get driver updates as nicely.

If you look at Vulkan extensions qualitatively (not just the numbers) you'll see that it's nothing at all like the OpenGL extension mess. The vast majority is window system integration (WSI) and extenral memory and multi device stuff. Platform specific stuff which would exist in WGL/GLX/EGL for OpenGL and can't reasonably be put in "core" (because everyone must support all of core).

It was perhaps a mistake to attempt to release Vulkan 1.0 as early as they did, it might have been a better idea to put out 0.9 beta version and accept that there will be API changes.

However, very few changes have been made to the core apis.

[pjmlp]

It is not being dishonest as alternative APIs don't suffer from extension explosion.

Also I don't believe that by following this path Vulkan will be any better than OpenGL, ES, WebGL.

Let's see how many Vulkan 2.0 will have and of what kind.

[exDM69]

Yes, yes it is. If the extensions would be anything like the OpenGL extensions which make changes to the core api functionality, you'd be right. But take a look at the extensions and tell which one(s) would cause a "write once, port everywhere" situation.

I can't name a single extension that would be causing any friction in Vulkan, unlike OpenGL where there's lots of code paths that need to be implemented to do even basic stuff (and all the core/ARB/EXT variations).

Yeah, Vulkan has some extra complexity stemming from being cross-vendor and designed by a commitee. But it's nowhere nearly as bad as you imply.

In my experience with Vulkan, it's all the optional features and device capabilities that need to be queried at runtime and decisions made based on that that's causing complexity with portability (you don't need to care about most of the extensions, and the ones you do have to care about are simpler than their OpenGL counterparts, ie. WSI vs. GLX/WGL/EGL). And apart from a few pain points (like numbers of queues exposed), it's relatively straightforward and comparable to D3D or Metal in complexity.