The important part to note is that the M1 hardware doesn't map well to newer OpenGL standards because Apple deprecated OpenGL in 2018:
> Regrettably, the M1 doesn’t map well to any graphics standard newer than OpenGL ES 3.1. While Vulkan makes some of these features optional, the missing features are required to layer DirectX and OpenGL on top. No existing solution on M1 gets past the OpenGL 4.1 feature set.
> How do we break the 4.1 barrier? Without hardware support, new features need new tricks. Geometry shaders, tessellation, and transform feedback become compute shaders. Cull distance becomes a transformed interpolated value. Clip control becomes a vertex shader epilogue. The list goes on.
OpenGL has been officially deprecated since macOS Mojave (2018), so it shouldn't come as a surprise to anyone that in 2024 the hardware doesn't map well to newer OpenGL features. The media narrative is trying to push this as an "outdoing Apple at their own game" thing, but Apple very clearly stopped supporting OpenGL and did so with advance warning years ago.
That said, it's an impressive accomplishment that they managed to translate the newer calls into compute shaders and other tricks. It's very impressive work.
They shouldn't have deprecated OpenGL though. It's really important for desktop software. Several games have lost Mac support due to this like elite dangerous.
Of course they push metal but that's not interesting to desktop developers.
One of the coolest things (IMO) about the entire Asahi effort, and why I'm not at all surprised that they surpassed Apple, was the dedicated effort to build bespoke developer-friendly Python tooling early in the reverse engineering process.
> Since the hypervisor is built on m1n1, it works together with Python code running on a separate host machine. Effectively, the Python host can “puppeteer” the M1 and its guest OS remotely. The hypervisor itself is partially written in Python! This allows us to have a very fast test cycle, and we can even update parts of the hypervisor itself live during guest execution, without a reboot.
> We then started building a Python implementation of this RPC protocol and marshaling system. This implementation serves a triple purpose: it allows us to parse the DCP logs from the hypervisor to understand what macOS does, it allows us to build a prototype DCP driver entirely in Python, and it will in the future be used to automatically generate marshaling code for the Linux kernel DCP driver.
If you watch any of Asahi Lina's streams from the time before they had their full drivers implemented in Rust, she's able to weave together complex bitflag-manipulating pipelines at the speed of thought with self-documenting code, all in Python running on the host machine, all while joking with viewers via her adorable avatar. I've never seen anything like it before. The whole workflow is a tremendous and unprecedented accomplishment by the entire Asahi team.
I completely agree, this is a great talk. I can listen to Bryan and friends speak for hours. I'm not sure if he's a natural story teller or if he's learned over time, but that combined with his experience just makes for a treat.
Knowing how to build effective scaffolding, in the right sequence, that continuously enables tighter and faster iteration loops on a project is a huge meta-skill that contributes to why the high end of experienced engineers are orders of magnitude more effective than others.
I was wondering if it is possible to formalise this and cast it into a book or lecture so that new devs don‘t have to grind out ten years of hard-gained experience. But at this point I think the only real way to really learn this is to go e.g. through dependency hell yourself at least once.
Mmh, is that a similarity with postmarketos? I have a fuzzy memory that pmbootstrap or some other tool was kind of important to start porting to new devices?
6 years ago I said I'd never give apple another cent, but the Asahi Linux project, and especially their efforts around OpenGL, or more specifically their ES 3 support, finally convinced me to pick up a secondhand M1 last month. Amazing work by the team!
I wonder if one day the USB4 ports will be able to fully support USB3, so confusing.
Anyway I haven't felt the need to boot macos so far :) and the installation was a breeze, big thanks to the team.
As a bonus the unified memory allowed me to get an LLM running locally, but I suspect it is CPU bound and probably not using the new GPU driver.
I love this work, but I will point out that the Asahi GPU driver still struggles on certain real world workloads.
The one I run into quite often is that Google Maps will hang for long periods of time. This is a known issue and they are working on it, so I'm sure it will be fixed sometime this year.
> For a bit of context -- Google Maps loads images to the GPU at.. inopportune times. While games would typically load their images during a load screen (so slow image loading just means longer loading screens), Google Maps loads when scrolling around I think (so slow image loading means the whole map stutters). I don't think there's a fundamental driver bug we can fix here, but we can make image loading a lot faster which makes the symptoms go away.
like it uses mesa and similar parts of the normal GPU support stack
and also involved some kernel patches outside of the rust kernel module as far as I vaguely remember
really a grate achievement where in the end rust was like a tool to make certain parts easier but all the hard parts are in the end unrelated to rust (like reverse engineering, coming up with solutions for the many issues of mapping GPU APIs Apple doesn't care much about to hardware mainly focused on on just Metal etc.)
Just the thought of how to prioritize things in all of the reversing is enough to make me overwhelmed. Have they talked about how they prioritize?
"Asahi's most recent update blog post, published in mid-January, highlighted HDMI support, support for DRM-protected websites via Google's proprietary Widevine package, Touchbar support for the handful of Apple Silicon Macs that use one, and more."
Seems odd to me that a Linux open source focused something would spend so much effort on supporting DRM over USB3 functionality. So for them to go that direction implies to me they have good reasons. Are they trying to satisfy users? My knee jerk reaction would be the users willing to use this would be accepting of not supporting DRM.
The Asahi team isn't some monolithic corporation with a prioritised backlog.
The skillsets and amount of work involved in getting Widevine working (quickly porting the binary from ARM64 ChromeOS) vs USB 3 (reverse engineer Apple's unique undocumented implementation and write a Linux kernel driver for it) are completely different.
It's open source, if someone volunteers a Widevine implementation for Asahi then the maintainers aren't going to say no.
Generally speaking Alyssa does GPU reverse engineering, Marcan does the other hardware reverse engineering, Asahi Lina writes the GPU driver and everyone else does various miscellaneous bits (like userspace binaries).
> The skillsets and amount of work involved in getting Widevine working (quickly porting the binary from ARM64 ChromeOS) vs USB 3 (reverse engineer Apple's unique undocumented implementation and write a Linux kernel driver for it) are completely different.
for one data point, I'd much rather have DRM supported than USB 3 support- one lets me do casual things and use my machine while I relax or do whatever, and for most USB 3 devices I can just suck it up and wait for a file transfer, or do what I normally do and work off of my NAS.
> Rosenzweig's blog post didn't give any specific updates on Vulkan except to say that the team was "well on the road" to supporting it. In addition to supporting native Linux apps, supporting more graphics APIs in Asahi will allow the operating system to take better advantage of software like Valve's Proton, which already has a few games written for x86-based Windows PCs running on Arm-based Apple hardware.
Does anyone know whether these improvements will also help with gaming on macOS? I assume that Mac ships its own driver without these APIs, but e.g. will Proton for Mac or Whisky (Wine for Mac) be able to make use of them?
Readit News
https://news.ycombinator.com/item?id=39371669 (100+ comments)
Conformant OpenGL 4.6 on the M1 (rosenzweig.io)
The important part to note is that the M1 hardware doesn't map well to newer OpenGL standards because Apple deprecated OpenGL in 2018:
> Regrettably, the M1 doesn’t map well to any graphics standard newer than OpenGL ES 3.1. While Vulkan makes some of these features optional, the missing features are required to layer DirectX and OpenGL on top. No existing solution on M1 gets past the OpenGL 4.1 feature set.
> How do we break the 4.1 barrier? Without hardware support, new features need new tricks. Geometry shaders, tessellation, and transform feedback become compute shaders. Cull distance becomes a transformed interpolated value. Clip control becomes a vertex shader epilogue. The list goes on.
OpenGL has been officially deprecated since macOS Mojave (2018), so it shouldn't come as a surprise to anyone that in 2024 the hardware doesn't map well to newer OpenGL features. The media narrative is trying to push this as an "outdoing Apple at their own game" thing, but Apple very clearly stopped supporting OpenGL and did so with advance warning years ago.
That said, it's an impressive accomplishment that they managed to translate the newer calls into compute shaders and other tricks. It's very impressive work.
Conformant OpenGL 4.6 on the M1 - https://news.ycombinator.com/item?id=39371669 - Feb 2024 (103 comments)
Of course they push metal but that's not interesting to desktop developers.
Big Linux at it again, eh?!
Deleted Comment
https://asahilinux.org/2021/08/progress-report-august-2021/
> Since the hypervisor is built on m1n1, it works together with Python code running on a separate host machine. Effectively, the Python host can “puppeteer” the M1 and its guest OS remotely. The hypervisor itself is partially written in Python! This allows us to have a very fast test cycle, and we can even update parts of the hypervisor itself live during guest execution, without a reboot.
> We then started building a Python implementation of this RPC protocol and marshaling system. This implementation serves a triple purpose: it allows us to parse the DCP logs from the hypervisor to understand what macOS does, it allows us to build a prototype DCP driver entirely in Python, and it will in the future be used to automatically generate marshaling code for the Linux kernel DCP driver.
Code here: https://github.com/AsahiLinux/m1n1/blob/main/proxyclient/m1n...
If you watch any of Asahi Lina's streams from the time before they had their full drivers implemented in Rust, she's able to weave together complex bitflag-manipulating pipelines at the speed of thought with self-documenting code, all in Python running on the host machine, all while joking with viewers via her adorable avatar. I've never seen anything like it before. The whole workflow is a tremendous and unprecedented accomplishment by the entire Asahi team.
https://www.p99conf.io/session/sharpening-the-axe-the-primac...
I wonder if one day the USB4 ports will be able to fully support USB3, so confusing.
Anyway I haven't felt the need to boot macos so far :) and the installation was a breeze, big thanks to the team.
As a bonus the unified memory allowed me to get an LLM running locally, but I suspect it is CPU bound and probably not using the new GPU driver.
The one I run into quite often is that Google Maps will hang for long periods of time. This is a known issue and they are working on it, so I'm sure it will be fixed sometime this year.
> For a bit of context -- Google Maps loads images to the GPU at.. inopportune times. While games would typically load their images during a load screen (so slow image loading just means longer loading screens), Google Maps loads when scrolling around I think (so slow image loading means the whole map stutters). I don't think there's a fundamental driver bug we can fix here, but we can make image loading a lot faster which makes the symptoms go away.
[0]: https://github.com/AsahiLinux/linux/issues/72#issuecomment-1...
but also a bunch of other things
like it uses mesa and similar parts of the normal GPU support stack
and also involved some kernel patches outside of the rust kernel module as far as I vaguely remember
really a grate achievement where in the end rust was like a tool to make certain parts easier but all the hard parts are in the end unrelated to rust (like reverse engineering, coming up with solutions for the many issues of mapping GPU APIs Apple doesn't care much about to hardware mainly focused on on just Metal etc.)
"Asahi's most recent update blog post, published in mid-January, highlighted HDMI support, support for DRM-protected websites via Google's proprietary Widevine package, Touchbar support for the handful of Apple Silicon Macs that use one, and more."
Seems odd to me that a Linux open source focused something would spend so much effort on supporting DRM over USB3 functionality. So for them to go that direction implies to me they have good reasons. Are they trying to satisfy users? My knee jerk reaction would be the users willing to use this would be accepting of not supporting DRM.
The skillsets and amount of work involved in getting Widevine working (quickly porting the binary from ARM64 ChromeOS) vs USB 3 (reverse engineer Apple's unique undocumented implementation and write a Linux kernel driver for it) are completely different.
It's open source, if someone volunteers a Widevine implementation for Asahi then the maintainers aren't going to say no.
Generally speaking Alyssa does GPU reverse engineering, Marcan does the other hardware reverse engineering, Asahi Lina writes the GPU driver and everyone else does various miscellaneous bits (like userspace binaries).
They're not all that different to be honest
Does anyone know whether these improvements will also help with gaming on macOS? I assume that Mac ships its own driver without these APIs, but e.g. will Proton for Mac or Whisky (Wine for Mac) be able to make use of them?