[tombert]

I tried learning Vulkan a little more than a year ago and I have no desire to ever touch it again. It really bothers me that we're deprecating OpenGL and replacing it with something that's ridiculously hard to do anything simple (e.g. doing a spinning cube takes several hundred lines of code).

OpenGL was never "easy" but it was at least something a regular person could learn the basics of in a fairly short amount of time. You could go to any big book store, buy some intro to graphics programming book, and get some basic stuff rendering in an afternoon or two. I'm sure Vulkan is better in some regards but is simply not feasible to expect someone to learn it quickly.

Like, imagine the newest Intel/ARM/AMD chips came along and instead of being able to write C or C++, you're being told "We are dropping support for higher level languages so you can only write assembly on this now and it'll be faster because you have more control!" It would be correctly labeled as ridiculous.

[SubjectToChange]

It really bothers me that we're deprecating OpenGL and replacing it with something that's ridiculously hard to do anything simple

OpenGL is only deprecated on MacOS, AFAIK, it will exist for many years to come.

I'm sure Vulkan is better in some regards but is simply not feasible to expect someone to learn it quickly.

Vulkan is often said to be more of a “GPU API” than a high level graphics API. With that in mind, the complexity of Vulkan is not surprising. It’s just a difficult domain.

Like, imagine the newest Intel/ARM/AMD chips came along and instead of being able to write C or C++, you're being told "We are dropping support for higher level languages so you can only write assembly on this now and it'll be faster because you have more control!" It would be correctly labeled as ridiculous.

IMO, it’s more like single threaded C/C++ vs multithreaded C/C++ programming. There is a massive increase in complexity and if you don’t know what you are doing, it’ll blow up in your face and/or give you worse performance. However, it’s the only practical path forward.

Anyway, OpenGL can basically be implemented on top of Vulkan. Perhaps it is regrettable that the OpenGL standard is no longer being actively developed, but nothing lasts forever.

[flohofwoe]

> OpenGL is only deprecated on MacOS, AFAIK, it will exist for many years to come.

It's abandondend by Khronos and GPU vendors, which is pretty much the same thing as deprecated unfortunately.

[eliasdaler]

By the way, here's an interesting post by Mike Blumenkrantz (Valve): https://www.supergoodcode.com/manifesto/

Most of it is satire, but it's interesting that the position of "Chair of OpenGL" still exists to this day and a new person was assigned to it in 2024.

[tombert]

Everything you said is fine, and I'm ok with OpenGL being killed/downplayed/deprecated.

What I would have really preferred is Apple releasing Metal as a standard that anyone could use. Metal is a pretty nice API that's fairly fun and easy to use. I feel like if we need a "next gen" version of a graphics API, I would have had Vulkan for super low-level stuff, and Metal or DirectX for higher-level stuff.

[flohofwoe]

WebGPU is mostly very similar to Metal (except for a couple of overly 'rigid' parts which are mostly inherited from Vulkan - most importantly the resource binding via BindGroups and all-in-one PSOs).

Also, Metal isn't generally a high-level API, it has low-level features which are pretty much like Vulkan or D3D12, you just don't need to use those low level features if not needed.

[account42]

> e.g. doing a spinning cube takes several hundred lines of code

This really doesn't mean much. The second cube (or another shape) isn't going to double the line count.

> OpenGL was never "easy" but it was at least something a regular person could learn the basics of in a fairly short amount of time.

The problem is that OpenGL no longer matches current hardware so the naive way to use it is very much suboptimal for performance. Once you move to zero driver overhead techniques for OpenGL then Vulkan is not that much harder.

> Like, imagine the newest Intel/ARM/AMD chips came along and instead of being able to write C or C++, you're being told "We are dropping support for higher level languages so you can only write assembly on this now and it'll be faster because you have more control!" It would be correctly labeled as ridiculous.

Except current Intel/ARM/AMD chips don't support C or C++ and you already have to write assembly ... or use a third-party tool to do the translation from C or C++ for you. That's also the goal for Vulkan - to provide a low level standard interface for GPUs on top of which more user friendly abstractions can be layered.

[foldr]

>This really doesn't mean much. The second cube (or another shape) isn't going to double the line count.

It's like the difference between "Hello World" in Python and "Hello World" in Java. Doesn't matter in the context of a serious software engineering project, but it's a significant barrier for beginners.

[account42]

I agree with your analogy. It just so happens that Java is commonly taught as a first programming language and most people manage just fine with the class boilerplate even if they don't really understand it yet.

[pjmlp]

Yet the burden in C# and Java was consider enough of an issue versus languages like Python, JavaScript, Go, that both platforms are reducing the hello world boilerplate.

[troad]

> This really doesn't mean much. The second cube (or another shape) isn't going to double the line count.

That's an absurd standard. "Writing an OS is easy, because once you've written enough code to get Doom to run, firing up a second copy of Doom is relatively straight-forward!"

It's those first 600 lines that are the problem. There's now a steep learning curve and lots of boilerplate required for even trivial use cases, where there wasn't before. That's a loss.

> The problem is that OpenGL no longer matches current hardware so the naive way to use it is very much suboptimal for performance. Once you move to zero driver overhead techniques for OpenGL then Vulkan is not that much harder.

Again, mad standard. "Writing Vulkan shouldn't be a problem for people who write complex zero driver overhead code for OpenGL." Great. What about the other 99% of people?

I'm not against Vulkan for those applications that truly do need it, but - frankly - most graphics programming does not need it. In giving up OpenGL we're giving up a sane, standard way to do graphics programming, and exchanging it for a choice between (i) making everyone write mad Vulkan boilerplate for control they don't need, or (ii) choosing between a bewildering array of engines and frameworks and libraries, none of which work at all similarly, many of which are still very immature.

And it's obvious which one will win - whichever proprietary, SaaS monolith emerges to clean up the mess. Losing OpenGL is a huge set back for open standards, honestly. The principal beneficiaries of depreciating OpenGL will be the shareholders of Unity, in the end.

[account42]

> That's an absurd standard. "Writing an OS is easy, because once you've written enough code to get Doom to run, firing up a second copy of Doom is relatively straight-forward!"

If you can write that OS in anything close to 600 lines then yes, it is easy.

The point is that more realistic OpenGL and Vulkan projects will have a much smaller relative size difference.

> Great. What about the other 99% of people?

They can use higher-level abstractions built on top of Vulkan. Or spend some time learning to use Vulkan directly.

> I'm not against Vulkan for those applications that truly do need it, but - frankly - most graphics programming does not need it.

Disagree.

> In giving up OpenGL we're giving up a sane, standard way to do graphics programming

Sane is not a word I would use to describe OpenGL. It has managed to collect many warts over the years and as I have already mentioned, what performs well is not at all intuitive.

> (i) making everyone write mad Vulkan boilerplate for control they don't need, or (ii) choosing between a bewildering array of engines and frameworks and libraries, none of which work at all similarly, many of which are still very immature.

"Oh no, so many options". A nice problem to have.

> And it's obvious which one will win - whichever proprietary, SaaS monolith emerges to clean up the mess. Losing OpenGL is a huge set back for open standards, honestly. The principal beneficiaries of depreciating OpenGL will be the shareholders of Unity, in the end.

Wild and unfounded speculation. You can already use ANGLE, which is open source, as your middleware today if you like the OpenGL API so much.

[HelloNurse]

> I'm not against Vulkan for those applications that truly do need it, but - frankly - most graphics programming does not need it. In giving up OpenGL we're giving up a sane, standard way to do graphics programming

I cannot avoid thinking that this sort of argument was made for countless technological innovations, from steam engines vs. draft animals to boats vs. swimming.

[troad]

Haha, that's an interesting thought. Not to play devil's advocate, but can you honestly tell me the average American's weekly car need couldn't be met by a horse? (Mostly kidding.)

I think the distinguishing thing here is that those technological innovations were all adopted voluntarily by people setting aside the previous technologies, for the advantages of the new technology were obvious. Here, people are clinging to the old tech despite being threatened with its constant depreciation (already done on Apple systems), for the simple reason that using the new tech is more work for no more gain. For the average use case, Vulkan feels more like a technological regression than an advance.

[edflsafoiewq]

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.

[tombert]

No, I don't think that that's good reasoning. They could, if nothing else, make first-party libraries that have a high-level DSL or something that makes it less horrible to use. As it stands it creates a bunch of crappy libraries on top instead of an officially supported API that could also be standardized across operating systems and platforms.

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

[exDM69]

Please try again with Vulkan 1.3 and reassess how "terrible" the API is.

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).

[pjmlp]

It has happened on Android, version 15 is now making ANGLE the official way to still have OpenGL, given the sore state of Vulkan drivers, it is a yet another move to force OEMs to improve their story.

[edflsafoiewq]

It doesn't really make sense to have Khronos maintain nice high-level libraries. 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. Their commitee/standard-based process works for specs, but I don't think it will work very well for the needs of day-to-day application programmers.

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.

[tombert]

> It doesn't really make sense to have Khronos maintain nice high-level libraries.

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.

[johnnyanmac]

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

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.

[HelloNurse]

The "first party library" is OpenGL, or if you have special needs OpenGL ES, WebGPU, Metal, DirectX variants, implemented on top of Vulkan.

The "NO REPLACEMENT" is sidelining ugly OpenGL drivers and adopting leaner and more modern Vulkan drivers.

[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.

[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.

[nox101]

If you want OpenGL use ANGLE

https://github.com/google/angle

several phones now ship ANGLE as their only OpenGL support on top of their Vulkan drivers.

If you want a modern-ish API that's relatively easy and portable use WebGPU via wgpu (rust) or dawn (c++).

[debugnik]

It's not so much a modern API but a modern feature set. Most ANGLE backends give you an ES 3.0 context (except for 3.2 on Vulkan, so the problem is mostly Apple), and all of them lack some useful extensions to narrow the gap between ES and the desktop APIs.

[eXpl0it3r]

Which can be quite the pain, when the phone vendors just drop the support for OpenGL ES 1 from their ANGLE binaries, probably under the assumption that "nobody uses such old APIs".

[Narishma]

ANGLE is such a pain to build, I've never managed to do it.

[gyf304]

I usually copy the built library from a Chrome/Chromium installation, saves me from building the library myself.

[nmfisher]

Really? I did it recently (integrating an OpenGL texture render target into a D3D application) and it was pretty straightforward (on Windows, at least).