[andrewmcwatters]

Khronos keeps pushing this in their promotional materials for the standard, and it's not an advantage. Now instead of vendors writing this correctly once for everyone, everyone can do it poorly. Go read a few Vulkan initialization implementations across a few repositories. It's all the same code, and some people miss portions of it here and there.

I don't know how this lie caught on so well, but it doesn't pass the smell test.

[jms55]

> Now instead of vendors writing this correctly once for everyone, everyone can do it poorly.

_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".

[account42]

> but on this older intel GPU for a user with outdated drivers it segfaults in the driver

Implying that up to date Intel drivers don't segfault on perfectly valid OpenGL use.

[edflsafoiewq]

Pushing the code into a user-space library used by many programs means bugs can be fixed once in the library, instead of being at the mercy of every vendor fixing their driver blobs.

[andrewmcwatters]

Yeah, somehow I think putting this one on multi-million dollar companies with budgets to work on graphics work for products they sell and make actual money off of is better than having some podunkian whose popular graphics library gets consumed by a bunch of people while they make $5 each from less than 1% of their users off Patreon and GitHub Sponsors.

[MindSpunk]

Then you mustn’t have much experience working with the drivers those multi million dollar companies were (and still are) shipping to customers. They are full of bugs, quirks and performance traps. Vulkan wasn’t created because of some theoretical future problem, Vulkan was born from the real struggle of developers at the time. Problems were still struggling now.

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.

[jcelerier]

You don't know how incredibly, incredibly broken drivers are, especially on embedded.

[tadfisher]

Those multi-million dollar companies working on graphics libraries exist. Their names are Epic Games and Unity. Unfortunately, multi-million dollar companies want to make a profit, not give away their product for free.

[andrewmcwatters]

Those aren't graphics libraries.

[johnnyanmac]

They have a graphics library inside of a larger engine. And for 99% of devs they don't care about directly modifying such code, so they are fine with the stipulation of "use our tool to get graphics" approach.

[beautron]

Didn't Unity and Epic have people working directly on the Vulkan specification? I remember reading a comment (maybe here!), way back during Vulkan's original release, where someone was screaming about how Vulkan was a conspiracy to make us dependent on giant, multi million dollar game engines.

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.

[johnnyanmac]

I know Unity does, I forget if Epic does but I'd be surprised if they didn't.

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.

[torginus]

Honestly, this might be a bit of a conspiracy theory, but the practical use-case of Vulkan's low-level access isn't because of PCs and consoles - it's because of smartphone manufacturers that make absolutely abysmal mobile drivers.

[MindSpunk]

This isn’t a conspiracy it’s the reality we live in. That was one of the primary benefits sold to hardware vendors. “Easier to write a driver”. Whether that panned out though is another question. The drivers still suck on mobile.