> Tessellation enables games like The Witcher 3 to generate geometry. The M1 has hardware tessellation, but it is too limited for DirectX, Vulkan, or OpenGL. We must instead tessellate with arcane compute shaders
> Geometry shaders are an older, cruder method to generate geometry. Like tessellation, the M1 lacks geometry shader hardware so we emulate with compute.
Is this potentially a part of why Apple doesn't want to support Vulkan themselves? Because they don't want to implement common Vulkan features in hardware, which leads to less than ideal performance?
(I realize performance is still relatively fast in practice, which is awesome!)
> Is this potentially a part of why Apple doesn't want to support Vulkan? Because they don't want to implement common Vulkan features in hardware, which leads to less than ideal performance?
Yes, it's a big reason.
I tried to port the yuzu switch emulator to macos a few years ago, and you end up having to write compute shaders that emulate the geometry shaders to make that work.
Even fairly modern games like Mario Odyssey use geometry shaders.
Needless to say, I was not enough of a wizard to make this happen!
From a performance and technical perspective this is incredible. Well done!
It will never happen, but my dream is for the Asahi devs, Valve, and Apple to all get together to build out a cross-platform Proton to emulate and play games built for Windows on both x86 and ARM hardware running Linux.
A Steam Deck with the performance and power efficiency of an M-series ARM chip and the entire library of games that run on Proton is just...dreamy.
Alyssa Rosenzweig
Asahi Lina
chaos_princess
Davide Cavalca
Dougall Johnson
Ella Stanforth
Faith Ekstrand
Janne Grunau
Karol Herbst
marcan
Mary Guillemard
Neal Gompa
Sergio López
TellowKrinkle
Teoh Han Hui
Rob Clark
Ryan Houdek
Fantastic! A great proof of concept on Linux - lots of AAA gaming is already possible on Mac with Crossover and/or Parallels or VMWare Personal, which is free! While I have a Steam Deck, gaming on Mac works for me - I refuse to play Baldurs Gate 3 on a controller.
I know it's an extremely un-Apple-like thing to do, but I really wish Apple would team up with Valve to work on Proton, and bring full Proton support to MacOS.
Bringing Proton to Mac would involve either Apple making amends with Khronos and supporting Vulkan, or Valve making the substantial effort to port Proton to Metal natively, or doing DirectX-to-Vulkan-to-Metal translation with MoltenVK. None of those sound very likely or optimal to me.
Besides, the main reason Valve is investing so heavily in Linux and Proton is so their destiny isn't tied to someone else's platform. MacOS is just another someone else's platform like Windows is, with the same threat of getting rug-pulled by a first-party app store that spooked Gabe Newell[1] into investing in Linux in the first place.
Don’t forget Apple’s GamePortingToolkit based on Crossover/Wine and the open source client for it Whisky. I think it supports most games Linux Proton does now.
The M-series chips from Apple have some special hardware to help emulate x86 with near-native performance, right? I wonder if they take advantage of those features (actually I forget exactly what the features were).
I mean this is an incredible achievement either way. Everything is emulated, but they are still running AAA games. Wow.
Other than the page size issue, FEX and Rosetta are comparable technologies (both are emulators, despite what Apple marketing might have you believe). Both FEX and Rosetta use the unique Apple Silicon CPU feature that is most important for x86/x86_64 emulation performance: TSO mode. Thanks to this feature, FEX can offer fast and accurate x86/x86_64 emulation on Apple Silicon systems.
If every layer of abstraction and emulation is set up to allow it to pass through. It still seems really impressive to me, like lining up a bunch of targets and shooting an arrow through to get multiple bullseyes or something, haha.
I think the comment was saying “there isn’t any reason they can’t.” Which is true in theory, but in the practice it seems to be a lot of stuff to line up.
I think at the moment, this is probably the only way to feasibly game on a Mac. Crossover and other Wine-based apps as well as Parallels are... not really truly possible. If you bought the top-of-the-line MacBook Pro 16-inch, 2021 with M1 Max and tried to play anything reasonably modern on it, you'd find the performance is basically not playable .
> Asahi means “rising sun” in Japanese, and it is also the name of an apple cultivar. 旭りんご (asahi ringo) is what we know as the McIntosh Apple, the apple variety that gave the Mac its name.
I noticed the URL was updated for this post. Previously it linked to asahilinux.org which showed an anti-HN manifesto from the HN referral. Curious as I haven’t seen this before. Seems it has been covered by previous commenters: https://news.ycombinator.com/item?id=36227103
Casual dismissal of their concerns by HN commenters kinda proves their point doesn't it? They took the time to explain how seriously bad the comments and moderation are on this site are for the mental health of Asahi contributors, about how this type of harassment has led to the death of other legendary software authors, and the only response is either curious neutrality or judgement about how it's distracting you from the content? It's a parasitic malicious apathy that is actually dangerous.
See[1] the Referrer-Policy header, <meta name="referrer">, <a referrerpolicy> and <a rel="noreferrer">.
But generally, webmasters have found it useful to know who caused their server to fall over^W^W^W^W^W^W is linking to their pages. This was even used as a predecessor to pingbacks once upon a time, but turned out to be too spammable (yes, even more so than pingbacks).
After the HN operators started adding rel=noreferrer to links to the Asahi Linux website, Marcan responded[2] by excluding anyone who has the HN submit form in their browser history, which feels like a legitimate attack on the browser’s security model—I don’t know how it’d be possible to do that. (Cross-origin isolation is supposed to prevent cross-site tracking of this exact kind, and concerns about such privacy violations are why SRI has not been turned into a caching mechanism along the lines of Want-Content-Digest, and so on and so forth.) ETA: This is no longer in place, it seems.
Visited links have always looked different from unvisited ones, and the moment you could customize how links looked via CSS, browsers also had to implement styling for visited links specifically.
Modern browsers put a lot of care into making the changes to those styles observable to the user, but not to Javascript.
This is an extremely hard problem, and browsers have had a lot of security issues related to this behavior. Nowadays, you can only apply a very limited subset of CSS properties to those styles, to avoid side-channel timing attacks and such.
This means you can display a banner to anybody who has a certain URL in their browser history, but you can't observe whether that banner actually shows up with JS or transmit that information to your server.
Referer does have legitimate uses. For example, back in the day people would use it to detect if someone embedded an image from their site on another site. SomethingAwful famously used to respond to any such requests with goatse, and forums I was on had very strict "don't link to SA images" rules as a result.
I think that using referer to try to deliver manifestos to users of another site is kinda childish, but so it goes. Every tool can be put to good or bad uses.
The Referrer-Policy header lets a server tell the browser how much referrer information to pass on when following links, all the way down to nothing at all if desired. Chrome does respect that, and they also followed other browsers in changing the default to "strict-origin-when-cross-origin" a few years ago which truncates the referrer path when leaving to a different domain, so they only see the domain the visitor came from rather than the specific page like they used to. Can't really fault Google in this case.
> Tessellation enables games like The Witcher 3 to generate geometry. The M1 has hardware tessellation, but it is too limited for DirectX, Vulkan, or OpenGL. We must instead tessellate with arcane compute shaders
> Geometry shaders are an older, cruder method to generate geometry. Like tessellation, the M1 lacks geometry shader hardware so we emulate with compute.
Is this potentially a part of why Apple doesn't want to support Vulkan themselves? Because they don't want to implement common Vulkan features in hardware, which leads to less than ideal performance?
(I realize performance is still relatively fast in practice, which is awesome!)
> Is this potentially a part of why Apple doesn't want to support Vulkan? Because they don't want to implement common Vulkan features in hardware, which leads to less than ideal performance?
Yes, it's a big reason.
I tried to port the yuzu switch emulator to macos a few years ago, and you end up having to write compute shaders that emulate the geometry shaders to make that work.
Even fairly modern games like Mario Odyssey use geometry shaders.
Needless to say, I was not enough of a wizard to make this happen!
Geometry shaders are not part of base Vulkan. They're an extension.
From a performance and technical perspective this is incredible. Well done!
It will never happen, but my dream is for the Asahi devs, Valve, and Apple to all get together to build out a cross-platform Proton to emulate and play games built for Windows on both x86 and ARM hardware running Linux.
A Steam Deck with the performance and power efficiency of an M-series ARM chip and the entire library of games that run on Proton is just...dreamy.
https://www.pcworld.com/article/2465907/arm-version-of-steam...
That's awesome news!
I'm not sure if you know. But Alyssa, the person who basically wrote almost the entire userspace opengl and vulkan driver, works at valve.
Wow! I wasn't aware, but that actually gives me a ton of confidence that Valve isn't ignoring ARM with all of their Linux + Proton work.
Her output is incredible.
Thank you
Thank not only these people but also their employers for funding the work.
Marcan and asahi Lina are the same person.
Is there actually any proof of that?
This is super cool.
So, wait, does this mean that gaming is better on Linux, on a Mac?
I've been gaming on Linux since Warcraft 3 days.
Wine is wonderful and with Valve's help it only got better.
But why would gaming on a mac be better? Maybe one day, but for now:
FTA: "While many games are playable, newer AAA titles don’t hit 60fps yet."
I read the GP differently. I think they meant: if you are on a Mac computer, is gaming better under Linux vs macOS?
I think the answer might be yes, because it's possible to play so many more titles!
Emulation has unavoidable overhead.
For instance, Alyssa mentions in this post that most emulated games will need at least 16 Gigs of RAM at minimum.
In addition, native ARM games on MacOS don't have the additional overhead of emulating a different CPU architecture and Graphics API.
However, that doesn't take away from this emulated support being an amazing achievement.
Yeah it has been for a while. The steam deck runs Linux out of the box.
Valve and open source devs have put a lot of effort over the years on projects like Photon which is a translation layer for Windows games.
The question was "better on Linux on a Mac", meaning specifically Asahi Linux.
The correct answer is no, not yet anyway.
Linux running on x86 with proton is still the bee's knees for most games though.
> on a Mac
Right. It sounds like the Asahi devs have implemented APIs which aren’t available under stock MacOS.
Back when I was actively developing for Freespace, we had a Linux port that had a better framerate than Windows (the game’s original platform).
Better on Linux on mac (as compared to macos) maybe?
Proton, not Photon. ;-) Here is a list with games and their support status: https://www.protondb.com/
Fantastic! A great proof of concept on Linux - lots of AAA gaming is already possible on Mac with Crossover and/or Parallels or VMWare Personal, which is free! While I have a Steam Deck, gaming on Mac works for me - I refuse to play Baldurs Gate 3 on a controller.
I know it's an extremely un-Apple-like thing to do, but I really wish Apple would team up with Valve to work on Proton, and bring full Proton support to MacOS.
Bringing Proton to Mac would involve either Apple making amends with Khronos and supporting Vulkan, or Valve making the substantial effort to port Proton to Metal natively, or doing DirectX-to-Vulkan-to-Metal translation with MoltenVK. None of those sound very likely or optimal to me.
Besides, the main reason Valve is investing so heavily in Linux and Proton is so their destiny isn't tied to someone else's platform. MacOS is just another someone else's platform like Windows is, with the same threat of getting rug-pulled by a first-party app store that spooked Gabe Newell[1] into investing in Linux in the first place.
[1] https://www.bbc.co.uk/news/technology-18996377
I wouldn't hold my breath. Valve is still bitter about Apple deprecating i386 support back in 2019.
You can hook up a monitor, mouse and keyboard to your Steam Deck to be fair.
Don’t forget Apple’s GamePortingToolkit based on Crossover/Wine and the open source client for it Whisky. I think it supports most games Linux Proton does now.
Incredible work. May I also interest you in retrowin32 https://github.com/evmar/retrowin32/blob/main/README.md
Which is an attempt to collapse the stack so that fewer translation and virtualisation stages are needed.
The M-series chips from Apple have some special hardware to help emulate x86 with near-native performance, right? I wonder if they take advantage of those features (actually I forget exactly what the features were).
I mean this is an incredible achievement either way. Everything is emulated, but they are still running AAA games. Wow.
They are using it:
Other than the page size issue, FEX and Rosetta are comparable technologies (both are emulators, despite what Apple marketing might have you believe). Both FEX and Rosetta use the unique Apple Silicon CPU feature that is most important for x86/x86_64 emulation performance: TSO mode. Thanks to this feature, FEX can offer fast and accurate x86/x86_64 emulation on Apple Silicon systems.
From: https://docs.fedoraproject.org/en-US/fedora-asahi-remix/x86-...
I believe libkrun is the tech behind.
https://fosstodon.org/@slp/113283657607783321
Sergio Lópéz has more info in his blog
https://sinrega.org/2024-03-06-enabling-containers-gpu-macos...
https://sinrega.org/2023-10-06-using-microvms-for-gaming-on-...
Rosetta 2: https://en.wikipedia.org/wiki/Rosetta_(software)#Rosetta_2
No reason they can’t.
If every layer of abstraction and emulation is set up to allow it to pass through. It still seems really impressive to me, like lining up a bunch of targets and shooting an arrow through to get multiple bullseyes or something, haha.
Hardly, the benefit of binary is if everything lines up once, it always will. It’s not an analog world with pesky things like wind resistance.
Why not? In fact they are using it right now.
I think the comment was saying “there isn’t any reason they can’t.” Which is true in theory, but in the practice it seems to be a lot of stuff to line up.
I think at the moment, this is probably the only way to feasibly game on a Mac. Crossover and other Wine-based apps as well as Parallels are... not really truly possible. If you bought the top-of-the-line MacBook Pro 16-inch, 2021 with M1 Max and tried to play anything reasonably modern on it, you'd find the performance is basically not playable .
Where's the real inspiration for Asahi, Fandaniel in FFXIV?
> Asahi means “rising sun” in Japanese, and it is also the name of an apple cultivar. 旭りんご (asahi ringo) is what we know as the McIntosh Apple, the apple variety that gave the Mac its name.
I noticed the URL was updated for this post. Previously it linked to asahilinux.org which showed an anti-HN manifesto from the HN referral. Curious as I haven’t seen this before. Seems it has been covered by previous commenters: https://news.ycombinator.com/item?id=36227103
It's almost as bad as jzw's website: https://cdn.jwz.org/images/2016/hn.png (nsfw)
He does the same redirect whenever someone links to his DNA Lounge: https://dnalounge.com (NSFW)
It’s completely different. Jwz’s is funny.
The URL wasn't updated. You're thinking of https://news.ycombinator.com/item?id=41799011, which was a separate post.
The manifesto is longer than the content...
Casual dismissal of their concerns by HN commenters kinda proves their point doesn't it? They took the time to explain how seriously bad the comments and moderation are on this site are for the mental health of Asahi contributors, about how this type of harassment has led to the death of other legendary software authors, and the only response is either curious neutrality or judgement about how it's distracting you from the content? It's a parasitic malicious apathy that is actually dangerous.
How can the site even detect where a user is coming from? Browsers leaking this information seems like a huge privacy issue to me.
Referer (misspelled in the spec) has been a part of HTTP from day 1.
Feels crazy this isn’t disabled by default
See[1] the Referrer-Policy header, <meta name="referrer">, <a referrerpolicy> and <a rel="noreferrer">.
But generally, webmasters have found it useful to know who caused their server to fall over^W^W^W^W^W^W is linking to their pages. This was even used as a predecessor to pingbacks once upon a time, but turned out to be too spammable (yes, even more so than pingbacks).
After the HN operators started adding rel=noreferrer to links to the Asahi Linux website, Marcan responded[2] by excluding anyone who has the HN submit form in their browser history, which feels like a legitimate attack on the browser’s security model—I don’t know how it’d be possible to do that. (Cross-origin isolation is supposed to prevent cross-site tracking of this exact kind, and concerns about such privacy violations are why SRI has not been turned into a caching mechanism along the lines of Want-Content-Digest, and so on and so forth.) ETA: This is no longer in place, it seems.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
[2] https://social.treehouse.systems/@marcan/110503331622393719
> I don’t know how it’d be possible to do that
It isn't, at least not in the way you think.
Visited links have always looked different from unvisited ones, and the moment you could customize how links looked via CSS, browsers also had to implement styling for visited links specifically.
Modern browsers put a lot of care into making the changes to those styles observable to the user, but not to Javascript.
This is an extremely hard problem, and browsers have had a lot of security issues related to this behavior. Nowadays, you can only apply a very limited subset of CSS properties to those styles, to avoid side-channel timing attacks and such.
This means you can display a banner to anybody who has a certain URL in their browser history, but you can't observe whether that banner actually shows up with JS or transmit that information to your server.
Ah. Ahhh[1]. I see.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/:visited#pr...Referer does have legitimate uses. For example, back in the day people would use it to detect if someone embedded an image from their site on another site. SomethingAwful famously used to respond to any such requests with goatse, and forums I was on had very strict "don't link to SA images" rules as a result.
I think that using referer to try to deliver manifestos to users of another site is kinda childish, but so it goes. Every tool can be put to good or bad uses.
It's only slightly less childish than the current WP drama.
This is part of the web DNA. Pages linking pages and being aware about it. Origin can still disable it.
There is little hope to get it disabled when an ad company is running running the most popular ad platf... Erm, the world wide web browser.
The Referrer-Policy header lets a server tell the browser how much referrer information to pass on when following links, all the way down to nothing at all if desired. Chrome does respect that, and they also followed other browsers in changing the default to "strict-origin-when-cross-origin" a few years ago which truncates the referrer path when leaving to a different domain, so they only see the domain the visitor came from rather than the specific page like they used to. Can't really fault Google in this case.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...