> Now we can run Xonotic at over 800 FPS, which is faster than macOS on the same hardware (M2 MacBook Air) at around 600*! This proves that open source reverse engineered GPU drivers really have the power to beat Apple’s drivers in real-world scenarios!
> Not only that, our driver passes 100% of the dEQP-GLES2 and dEQP-EGL conformance tests, which is better OpenGL conformance than macOS for that version. But we’re not stopping there of course, with full GLES 3.0 and 3.1 support well underway thanks to Alyssa’s tireless efforts!
That's very impressive work. Congrats to Asahi and Alyssa.
Now that we can see Vulkan is around 4/3 more power efficient than Metal on the same hardware, I wonder if Apple will budge on their not-invented-here syndrome and allow for a real vulkan.kext on upcoming macOS versions. That would solidify it as not only the best graphical workstation OS, but also the best gaming OS, in my opinion. Part of me thinks they're avoiding this in worry of stepping on Microsoft's toes.
Not that they can't, it would be nice. When they capitulated and came out with the intel macs around 2007ish, it became sort of a golden era. You could run macos and windows on their machines, and the smart computer folks started getting and usefully using macs.
But now apple is years into a disappointing inward looking phase.
What a decent future would be like...
- vulcan/x
- take back xquartz into the fold
- actively pursue other linux graphics apis
- apple does virtualization
- maybe like rosetta but for all their software
- run macos9 in a window
- apple does containers
- what if there was something like docker for macos natively?
FROM macos:10.3
- apple actively supports open source projects
- open up ios
- let me see the filesystem
- let me run a firewall (true privacy?)
The move to MacOS by development and sysadmin types started long before Intel Macs with the release of OSX, when it was finally possible to get a laptop with a 5+ hour battery life that ran a Unix-like OS.
Edit: The latest macOS has a great virtualization system built in, that many of the container platforms have already switched to.
Mine managed 6-8 without too much problem throughout the time I was in university. And they had removable batteries so you could just switch them out if you ever needed to (I had two for my Powerbook, and that would do a full day on campus without ever having to go near a power outlet).
* Please don’t take the exact number too seriously, as there are other differences too (Xonotic runs under Rosetta on macOS, but it was also rendering at a lower resolution there due to being a non-Retina app).
It's a known issue blocked on bureaucracy/politics with the kernel, so you just have to wait. Sorry.
ARM64 Linux does not want hardware-specific cpuidle drivers, instead relying on the PSCI firmware standard, but that standard is designed to rely on optional ARM features that Apple Silicon does not implement, so we can't implement it. Basically, PSCI assumes you have a "super-hypervisor" running the platform (TrustZone/EL3 on most Androids, but also somewhat similar to SMM mode on Intel), which is something Apple very deliberately stripped out of their CPUs very quickly because they don't need it and their security model relies on better solutions. Linux on AS truly runs on bare metal at the highest privilege, unlike the vast majority of other ARM64 platforms.
The current thinking is we need to make a new standard, either a new PSCI transport that does work on AS or something simpler/ad-hoc. We haven't had time to start that long conversation formally yet. I could write a hardware-specific cpuidle driver in a day, but of course they'd reject it upstream.
Doesn't seem like this is going to be fixed anytime soon. :(
Native Vulkan support could also pave the way for a proper Mac version of DXVK. That could make Macs a lot more viable as gaming machines than they are now, even with the Rosetta 2 overhead.
As much as I like the idea of Linux being in a special position w/r/t emulation layers for Windows games, this makes a lot of sense to me as something that would be desirable to Valve, and might, like the Steam Deck, help bootstrap Proton+DXVK as a worthy target platform for game developers/publishers.
Valve supports Steam Deck/Proton that much because they are afraid of being killed by windows locking itself down, it's a live line for them, but not a supper profitable business.
A Steam for iOS & Android might be worth it for Valve, but for Mac it's like not worth the money it costs.
Additionally Apple is one of the main offenders pushing for a lockdown of PC platforms and one of the main lobbyist trying to prevent regulation requiring the possibility of (well working) 3rd party app stores. Which means not only would good Mac support be costly it also is constantly at risk of "defacto" being killed off. (Yes there are currently regulations for requiring 3rd party app stores, but it being theoretical possible and it being practically viable for a business are not the same.)
I'm not sure the original proposition was that Valve focus on making that happen:
> > I wonder if Apple will budge on their not-invented-here syndrome and allow for a real vulkan.kext on upcoming macOS versions
> Native Vulkan support could also pave the way for a proper Mac version of DXVK
I think the proposition was that if Valve lets it happen, other interested developers might be inclined to improve the situation enough that it's not so much extra work for Valve to add Mac support to Proton.
I'm not sure who all would be interested, but I imagine the motivation would be similar to whatever is keeping the MoltenVK developers going.
You're right that Apple provides an a hostile and precarious platform compared to Linux, of course.
Metal was rendering in a lower resolution, but metal the game was also running through rosetta (x86 emulation) on Mac which is fast but has some overhead.
_Hence why she claims that it is in a similar performance range._
(instead of saying it's way fast, which is a result from taking sentences out of context and not fully reading the article)
Maybe, but it seems bizarre that open source developers go so far to contribute to a closed source proprietary ecosystem when the manufacturer doesn't only make it difficult but they at times actually intentionally impede their work. That is a lot of time and effort of someone doing something for free that the manufacturer should be paying them to do and assist with.
I’m pretty sure the asahi developers themselves would totally disagree with you there. Apple themselves have confirmed with them they have no plans to lock their boot loader out from folks like them. This project is no different than Linux in the old days: it’s just a piece of good hardware that kernel devs have reversed to run an alternate OS on and they’ve become quite good at it.
I don’t see people making the same statements about work on the nouveau driver or on the Broadcom opensource wifi drivers. But somehow because the hardware was built by apple folks seem to think it’s more proprietary than anything else linux has run on.
> Apple themselves have confirmed with them they have no plans to lock their boot loader out from folks like them.
Didn't they make an undocumented change to the boot loader that serves literally no purpose other than to give Asahi a somewhat stable target than what they were using before?
Yeah something like that. While I’m sure they don’t like folks reversing their hardware I doubt they care to stop this if they know there’s nothing that can be done to prevent it. I think it’s more likely they become consumers of asahi Linux’ work than it is for them to actively take measures to break them.
> Apple themselves have confirmed with them they have no plans to lock their boot loader out from folks like them
No, a person who used to work on the bootloader at Apple said on Twitter they did it because they wanted to enable different OSes. That's not an "Apple confirmed", that's "employee X said".
Regardless of all the points the siblings make, first and foremost this is fun. It's fun to reverse engineer stuff. It's fun to get things working that were previously not working.
A lot of peoples careers start this way. A lot of the hacking and the cracking scene was born this way. There is a certain kind of pleasure and satisfaction involved when you get a device that was previously not designed to do a certain thing behave in that way.
I think that's not an unreasonable point, but, well:
1. I try not to tell people what to do with their free time. While you may think it's "bizarre", this use of their time has value to them, not only in the hopeful end result (fully-functional Linux on ARM Macs), but also in the satisfaction of the technical challenge, bragging rights, and general reputation. I'm sure there are some people who might look at what you do with your spare time and think you're "wasting" it sometimes. But that's in the eye of the beholder, and at any rate, that's your prerogative, as this is theirs.
2. I used to run Linux on Mac laptops (gave up around 2016 or so, tried again in 2018, gave up again shortly after), and I get the appeal: the hardware is really nice. And by all accounts, the ARM Macs are even nicer than the Intel Macs. Sure, they're not perfect (lack of upgradeability/repairability, etc.), but running Linux on them can be great, if the hardware support is there. "I like this hardware and I want to run Linux on/with it, so I'll figure it out myself" seems like a perfectly reasonable thing to do. Many of the drivers in the Linux kernel for various bits of hardware only exist because someone adopted this attitude.
I also just think your premise is a bit flawed:
> open source developers go so far to contribute to a closed source proprietary ecosystem
This is a little bit of a weird statement, because these developers aren't doing that. The "closed source proprietary ecosystem" is macOS and its app store. The hardware itself is more or less just as open (or closed) as most non-Apple hardware. I mean, I can't rewrite the BIOS in my Framework Laptop, nor can I make heads or tails of any of the binary firmware blobs Linux loads into the WiFi chipset, graphics chipset, etc. Apple's hardware is undocumented, certainly, but that's pretty common when it comes to Linux hardware support.
> but they at times actually intentionally impede their work
Do they, though? From what I've read of the Asahi project's progress, they didn't run into cases where Apple intentionally tried to make things harder on them. Sure, some things were harder, but I don't think we can ascribe a malicious motive to Apple. The most likely explanation is that they just decided to design things in a particular way because they felt it would be best for their own purposes, and didn't really care to think about anything else.
They could have decided to actively cryptographically lock down the boot process to prohibit other OSes from running, but they didn't do that.
> That is a lot of time and effort of someone doing something for free that the manufacturer should be paying them to do and assist with.
Why "should" they? All hardware manufacturers decide what software to write, and what platforms to support. If they don't think the cost of writing and supporting drivers for Linux is worth what they'll get in return, they'll make the logical choice to just... not do that. We've seen plenty of vendors over the 30-odd-year lifetime of Linux do that math and decide Linux support wasn't worth it to them. It's a shame, but I don't think it's fair to come down on them hard for that. Certainly some vendors (nvidia comes to mind) have been actively hostile toward the Linux community at times, but I don't think we can say the same of Apple.
In fact Asahi team have argued before that Apple has actually gone to great lengths to provide documentation and tools to enable the development of third party OS kernels.
MacOS has been put on the back burner for Apple. It's all iPhone and iOS. It's clear that these scrappy hackers are going to fully utilize the hardware, clearly Apple doesn't care.
Off-topic: FreeBSD had an early version of Grand Central Dispatch ported to it, I wonder if Linux could benefit from that maybe with some io-uring goodness.
That ... really doesn't seem like the case. The macOS world has seen soo many big changes recently, with the complete visual overhaul of everything with Big Sur and then Ventura (whether you like that or not), the rewriting of a whole lot of applications and system stuff from AppKit to SwiftUI (again, whether you like that or not), porting the entire operating system to ARM, inventing an excellent x86_64 virtualization layer, overhauling everything related to booting and system upgrades (even if it's just taking what's already built for iOS and heavily modifying it to work for Macs), new window management features, etc etc. That's a lot of engineering resources invested.
The sorry state of Apple's OpenGL drivers is a part of their strategy. They're choosing to not invest in OpenGL, and have even officially deprecated it. They want you to use Metal instead.
I’m not sure what you’re on about. Vulakn’s story is about translating DX12 calls to Vulkan. That’s how it works on Linux and Linux gaming is so amazing because of it. I see Vulkan as the replacement for OpenGL and am excited for its future.
MacOS is a joke for gaming. iOS though of course is all metal. If you wanna target that platform then that’s all you got. But translating or porting to other platforms DX12 on Windows Vulkan is the answer.
It would make perfect sense if macOS was already the go-to platform for 3D apps and games. Third-party developers would then have to port to Metal in order to keep their customer base, and their OpenGL backend would be abandoned or at least a second-class citizen. That could be a competitive advantage for Apple.
But macOS is not the go-to platform for this sort of thing, especially when it comes to games. This does seem like a strategic mistake. Maybe they just don't care, for whatever reason. I mean, it doesn't seem like Metal has been catastrophic for Apple, has it?
Then again, OpenGL is probably still good enough on macOS for most 3D apps, deprecated or not. And if Apple does decide to actually remove it, I believe there are projects that implement the OpenGL API on top of Metal (certainly with performance impact). And third-party developers certainly have the option to wait to write a Metal backend only after Apple announces OpenGL is being dropped completely.
Yeah, there's ANGLE which implements OpenGL ES on top of Metal, and then there's MoltenVK which implements Vulkan on top of Metal, so you can get a program which uses the cross-platform APIs to run on macOS.
Maybe that's the whole strategy? To provide an API which exposes what's easy to do in a well-performing way on their hardware, and let the community worry about getting the standards to work? It certainly seems to be working, and it probably means they need to spend less resources on driver development than if they tried to stay current on OpenGL and Vulkan.
There are some historic reason why we end up with Apple, but additionally:
OpenGL is old, crufty and for modern standards sucks no matter how grate it once was.
Most new 3D software doesn't use OpenGL, a lot of new software which does use OpenGL limits itself to OpenGL ES (which is roughly a subset of OpenGL).
Apple always had issues with a "Not Invented Here" syndrome and an obsession to control every little bit. Apple always pushed that software should be explicitly written for Apple, or if not at least with an Apple focus. New GUIs "should" be written with SwiftUI, etc.
For apple having a different API means they don't have spent time with standards outside of things they want to pus beyond their ecosystem, this means they can just further develop Metal however they want, ignoring inputs from everyone else. This can remove friction, but also will remove valuable feedback and profiting from other peoples innovation.
Lastly Vulcan, DirectX12 and Metal aren't too different hence why thinks like MoltenVK (Vulkan API/emulation on top of Metal) or VKD3D (DirectX12 API/emulation on top of Vulcan) exists. (Through no surprise all three have their own edge cases which does make such cross libraries non trivial, still they are quite viable and most important performant as they don't have to do much emulation and mostly can just map functionality.)
Metal is widely used for game development due to iOS. This means there are plenty of game developers familiar with it, and lots of tools such as porting tools and game engines like Unity that support it very well. The main problem has been that Metal did not support a lot of advanced features used by AAA desktop games. This changed last year with a huge update to the high end rendering features in desktop Metal, so Apple does seem serious about this. They’ve always been weak on game tech on the desktop though, so we’ll see.
> Not only that, our driver passes 100% of the dEQP-GLES2 and dEQP-EGL conformance tests, which is better OpenGL conformance than macOS for that version. But we’re not stopping there of course, with full GLES 3.0 and 3.1 support well underway thanks to Alyssa’s tireless efforts!
That's very impressive work. Congrats to Asahi and Alyssa.