Conformant OpenGL 4.6 on the M1

Quake is just (a probably small (not wanting to dimish it, of course)) part of the history. SGI and the enormous effort to get compliant implementations on many different systems and architectures are what made OpenGL what it eventually became.

And yet it still got its ass kicked by Direct3D because Microsoft made better stuff. Better API, better tooling, better debuggability.

Honestly, it would've been better to leave OpenGL to the legacy CAD vendors and standardize on Direct3D roundabout 1997 or so.

I don’t know that it was the only reason, but Carmack’s push for OpenGL certainly helped. A lot of things related to 3D games are thanks to doom and Quake.

John Carmack a couple of years later, back in 2011:

Speaking to bit-tech for a forthcoming Custom PC feature about the future of OpenGL in PC gaming, Carmack said 'I actually think that Direct3D is a rather better API today.' He also added that 'Microsoft had the courage to continue making significant incompatible changes to improve the API, while OpenGL has been held back by compatibility concerns. Direct3D handles multi-threading better, and newer versions manage state better.'

It is really just inertia that keeps us on OpenGL at this point,' Carmack told us. He also explained that the developer has no plans to move over to Direct3D, despite its advantages.

From https://www.bit-tech.net/news/gaming/pc/carmack-directx-bett...

Back then OpenGL was objectively a much better API than Direct3D. A few years later it was the other way around though (thanks to D3D's radical approach to create a completely new API with each major version).

Fun fact: the earliest archived OpenGL site was a big "FAST GAMES GRAPHICS" banner with an animated Quake 1 graphic and a menu for other stuff :-P

https://web.archive.org/web/19970707113513/http://www.opengl...

For context https://www.chrishecker.com/OpenGL/Press_Release

I've read that generally opengl is just easier to use than vulkan

[here's](https://learnopengl.com/code_viewer_gh.php?code=src/1.gettin...) an opengl triangle rendering example code (~200 LOC)

[here's](https://vulkan-tutorial.com/code/17_swap_chain_recreation.cp...) a vulkan triangle rendering example code (~1000 LOC)

ye it's fair to say opengl is a bit easier to use ijbol

OpenGL is not deprecated, it is simpler and continues to be used where Vulkan is overkill. Using it for greenfields is a good choice if it covers all your needs (and if you don't mind the stateful render pipeline).

FWIW Metal is actually easier to use than Vulkan in my opinion, as Vulkan is kind of designed to be super flexible and doesn't have as much niceties in it. Either way, OpenGL was simply too high level to be exposed as the direct API of the drivers. It's much better to have a lower level API like Vulkan as the base layer, and then build something like OpenGL on top of Vulkan instead. It maps much better to how GPU hardware works this way. There's a reason why we have a concept of software layers.

It's also not quite true that everyone uses Unity and Unreal. Just look at the Game of the Year nominees from The Game Award 2023. All 6 of them were built using in-house game engines. Among indies there are also still some amount of developers who develop their own engines (e.g. Hades), but it's true that the majority of them will just use an off-the-shelf one.

WGPU is kinda supposed to solve the problem by making a cross platform API more user friendly than Vulkan. The problem with OpenGL is that it is too far from how GPUs work and it's hard to get good performance out of it.

My understanding is that one of the primary reasons Vulkan was developed was because OpenGL was not a good model for GPUs, and supporting it prevented people from taking advantage of the hardware in many cases.

It's because Vulkan is designed for driver developers and (to a lesser degree) for middleware engine developers. As far as APIs go, it's pretty much awful. I was very pumped for Vulkan when it was initially announced, but seeing the monstrosity the committee has produced has cooled down my enthusiasm very quickly.

One day, Apple will deprecate opengl 3.3 core, and I guess everybody might end up deprecating it.

And here I am, recalling all the games and programs that failed once OpenGL 2.0 was implemented because they required OpenGL 1.1 or 1.2 but just checked the minor version number... time flies!

One day, Apple will deprecate opengl 3.3 core

OpenGL is already deprecated on macOS and iOS for a couple of years. It still works (nowadays running as layer on top of Metal), but when building GL code for macOS or iOS you're spammed with deprecation warnings (can be turned off with a define though).

I've read that generally OpenGL is just easier to use than Vulkan.

OpenGL mostly only makes sense if you followed its progress from the late 90's and understand the reasons behind all the accumulated design warts, sediment layers and just plain weird design decisions. For newcomers, OpenGL is just one weirdness after another.

Unfortunately Vulkan seems to be on the same track, which makes me think that the underlying problem is organisational, not technical, e.g. both APIs are lead by Khronos, resulting in the same 'API design and maintenance philosophy' - and frankly, the approach to API design was OpenGL's main problem, not that it didn't map to modern GPU architectures (which could have been fixed with a different API design approach without throwing the baby out with the bath water).

But on Mac, what matters more is how OpenGL compares to Metal, and the answer is much simpler: Metal both has a cleaner design, and is easier to use than OpenGL.

I would love for my employer to support that config at work. We have quite lovely Linux dev laptops, but the battery life of the M1/M2 machines in the IT shop is definitely enticing, and Asahi Linux gets closer to MacOS in that regard than you might think given the relative maturity and optimization.

Looks like apple silicon are currently the best hardware for running linux

I wonder if this effort to run Linux on apple silicon will continue if snapdragon X laptops become mainstream.

Strange the article doesn't use the word "Apple" once, and instead awkwardly uses "the vendor" to refer to Apple.

Looks like apple silicon are currently the best hardware for running linux and linux is the best OS for apple silicon machines

Blender has Metal support for Apple Silicon macs. The Metal API is better architected (largely due to being more modern and being developed with benefit of hindsight) so all things equal I'd pick the Metal version on Mac.

In case you missed it in the article, the M1 GPU does not natively support OpenGL 4.6. They had to emulate certain features. The blog post goes into some of the performance compromises that were necessary to make the full OpenGL emulation work properly. Absolutely a good compromise if you're on Linux and need to run a modern OpenGL app, but if your only goal is to run Blender as well as possible then you'd want to stick to macOS.

Ryujinx is a Nintendo Switch emulator. They added support for Apple Silicon Macs a couple years ago and have been improving since then: https://blog.ryujinx.org/the-impossible-port-macos/

Linux on Apple hardware has come a long way due to some incredible feats of engineering, but it's far from perfect. Calling it the "best OS for Apple Silicon" is a huuuuge reach.

It's great if you need to run Linux for day to day operations, though.

apparently a lot of hardware is still not properly supported, like speakers, microphones and energy saving

Still waiting for some hardware support and hardware video decoding.

...and you came to that conclusion because of OpenGL 4.6 - something that several other platforms enjoyed under GNU/Linux with FLOSS drivers for more than half a decade now?

And Sodium! (For minecraft)

Perhaps already possible via MoltenVK -> Vulkan -> Zink?

According to the devs, it isn't really possible due to Apple not having a stable public kernel API: https://social.treehouse.systems/@AsahiLinux/111930744188229...

I think Apple bans third party kernel drivers? To write a proper Vulkan or OpenGL implementation you need a kernel counterpart for handling the GPU if I understand correctly. That's probably the reason no one bothers implementing native Vulkan for macOS.

But if it's doable with Apple's driver - then not sure.

You can implement an OpenGL driver on top of Metal. But why bother dedicating so many resources for the sake of a suboptimal legacy API?

Ultimately they build command buffers and send them to the GPU. You'd need a way to do that from macOS.

The original Mesa drivers for the M1 GPU were bootstrapped by doing just that, sending command buffers to the AGX driver in macOS using IOKit.

https://rosenzweig.io/blog/asahi-gpu-part-2.html

https://github.com/AsahiLinux/gpu/blob/main/demo/iokit.c

So you'd need a bit more glue in Mesa to get the surfaces from the GPU into something you can composite onto the screen in macOS.

They started with targeting older OpenGL to get a basic feature set working first. I guess from there, getting up to a more recent OpenGL was less work than doing a complete Vulkan implementation, and they probably learned a lot about what they'll need to do for Vulkan.

I thought something similar, but from their comments, to support OpenGL over Vulkan you need higher versions of Vulkan anyway and it's still a big effort. So they decided to go with (lower versions of) OpenGL first to get something functional sooner.

OpenGL-on-Vulkan compat layers aren't magic. For them to support a given OpenGL feature, an equivalent feature must be supported by the Vulkan driver (often as an extension). That means you can't just implement a baseline Vulkan driver and get OGL 4.6 support for free, you must put in the work to implement all the OGL 4.6 features in your Vulkan driver if you want MESA to translate OGL 4.6 to Vulkan for you.

Plus, this isn't Alyssa's first reverse engineering + OpenGL driver project. I don't know the details but I'd imagine it's much easier and quicker to implement a driver for an API you're used to making drivers for, than to implement a driver for an API you aren't.

It makes sense from the perspective of writing graphics drivers, and aligns with Postel's law (also called the robustness principle). GPU drivers are all about making broken applications run, or run faster. Making your GPU drivers strict by default won't fix the systemic problems with the video game industry shipping broken code, it'll just drive away all of your users.

And on hardware where branches are generally painfully expensive, it sounds really useful to have a flag to tell the system to quietly handle edge cases in whatever way is most efficient. I suspect there are a lot of valid use cases for such a mode where the programmer can be reasonably sure that those edge cases will have little or no impact on what the user ends up seeing in the final rendered frame.

This is one of the reasons why C and C++ have a rosy life ahead of themselves on graphics, HPC, HEP, HFT domains.

In domains where "performance trumps safety" culture reigns, talking about other programing languages is like talking to a wall.

The out of bounds accesses don't necessarily trap without the robustness checks, so the robustness is about delivering known results under those goofy cases. So it makes sense when you combine that with the fact that GPUs are pretty against traps in general. Carmack remarked once that it's was a pain to get manufacturers to be into the idea of virtual memory when he was designing megatexture.

Same, I wish I knew more about graphics programming. It seems like such a steep learning curve though so I get discouraged.

Alyssa chooses some very odd language here, it seems to me. Yes, Apple GPUs do not support geometry shaders natively because geometry shaders are a bad design and do not map well to GPU hardware (geometry shaders are known to be slow even on hardware that allegedly supports it — there is a reason why Nvidia went ahead to design mesh shading). Transform feedback (ability to write transformed vertex data back to memory) is another feature that is often brought up in these discussions, but Apple GPUs can write to arbitrary memory locations from any shader stage, which makes transform feedback entirely superfluous.

The core of the issue is that Apple chose to implement a streamlined compute architecture, and they have cut a lot of legacy cruft and things that were known not to work well in the process. I don't think that the rhetorics of "M1 getting stuck at OpenGL 4.1" is appropriate. I stopped following OpenGL many years ago, so I don't know specifically which features past 4.1 she might refer to. What I can say is that I'd be very surprised if there is something that OpenGL offers that cannot be done in Metal, but there are plenty of things possible in Metal that cannot be done at all in OpenGL (starting with a fact that Metal shading language has fully featured pointers).

There isn't necessarily much difference between implementing features in driver compute code versus GPU hardware support. Even the "hardware support" is usually implemented in GPU microcode. It often goes through the same silicon. Any feature could hit a performance bottleneck and it's hard to know which feature will bottleneck until you try.

More generally, you could execute complex OpenGL or Vulkan on some more-or-less arbitrary combination of CPU soft-rendering and hardware-specific native acceleration support. It would just be a matter of doing the work, and it could be reused across a wide variety of hardware - including perhaps older hardware that may be quite well understood but not usable on its own for modern workloads.