[HN Gopher] AAA Gaming on Asahi Linux
___________________________________________________________________
AAA Gaming on Asahi Linux
Author : 6a74
Score : 340 points
Date : 2024-10-10 14:16 UTC (8 hours ago)
(HTM) web link (rosenzweig.io)
(TXT) w3m dump (rosenzweig.io)
| psanford wrote:
| I'm a little sad that this has seemingly taken precedence over
| all other hardware support. M3 support, dp-alt mode, making the
| microphone work are all things that I was hoping were going to
| land in the past year.
| floydnoel wrote:
| I'm aware of no better way to see your desired features land in
| open source than to build them yourself. That is the power of
| open source, nobody can stop you!
| zarathustreal wrote:
| I hate to be the one to tell you Santa Claus isn't real but
| most people do not have the required skills and context to
| exercise that option. It's not incorrect, it's just not
| likely to be an option
| floydnoel wrote:
| i don't hate to be the one to tell you, but skills and
| context can be learnt. personally, i have found no better
| way to learn skills than to work on something i care about.
| kergonath wrote:
| Sure, and it's the same for quite a lot of people. It
| does not mean that anyone can do it, for a whole lot of
| reasons.
| kelnos wrote:
| Perhaps the people who aren't willing or able to learn
| those skills shouldn't complain about what the people who
| do have decided to focus on.
| pbasista wrote:
| I understand the sentiment. But the people who could work on
| the Asahi Linux graphics stack are generally not the same as
| the people who could e.g. bring up Asahi Linux on M3 chips.
|
| I would not consider the lack of activity in some Asahi Linux
| areas to be a conflict of priorities. It is in my opinion
| mostly a result of these lacking areas naturally attracting
| less developers capable of moving them forward.
| talldayo wrote:
| It's an Apple chip with no documentation and zero existent
| driver code to reference. You _have_ to set realistic
| expectations here, and acknowledge that not every contributor
| is going to have the domain-specific knowledge required to make
| everything work. It 's nothing short of a divine miracle that
| it has working Vulkan drivers you can download within a half-
| decade of it's release.
|
| If you want more, you'll have to take it up with Tim Cook or
| God (both have a nasty habit of ignoring us little guys). Also
| an option: not using a laptop that treats Linux as a threat to
| it's business model.
| dadoum wrote:
| Alyssa Rosenzweig already talked a bit about that on her
| Mastodon. She said that after having worked to implement a GPU
| drivers, it was annoying that she never had the time to quite
| finish them. On each device release, she had to support the new
| device instead of polishing what she got.
| anotherhue wrote:
| 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.
| bee_rider wrote:
| 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.
| captn3m0 wrote:
| Rosetta 2:
| https://en.wikipedia.org/wiki/Rosetta_(software)#Rosetta_2
| vyskocilm wrote:
| I believe libkrun is the tech behind.
|
| https://fosstodon.org/@slp/113283657607783321
|
| Sergio Lopez 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-...
| saagarjha wrote:
| No reason they can't.
| bee_rider wrote:
| 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.
| dontdoxxme wrote:
| 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.
| rowanG077 wrote:
| Why not? In fact they are using it right now.
| bee_rider wrote:
| 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.
| sumuyuda wrote:
| 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-...
| spease wrote:
| This is super cool.
|
| So, wait, does this mean that gaming is _better_ on Linux, on a
| Mac?
| ojdon wrote:
| 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.
| brookman64k wrote:
| Proton, not Photon. ;-) Here is a list with games and their
| support status: https://www.protondb.com/
| zdragnar wrote:
| 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.
| spease wrote:
| > 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).
| theLiminator wrote:
| Better on Linux on mac (as compared to macos) maybe?
| hu3 wrote:
| 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."
| Wowfunhappy wrote:
| 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!
| GeekyBear wrote:
| Game emulation isn't a Linux only thing.
| talldayo wrote:
| But if anyone can name a non-Windows platform that does
| it better, I'll wait!
| Wowfunhappy wrote:
| Is there a way to run Control or Cyberpunk on macOS?
| GeekyBear wrote:
| 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.
| m463 wrote:
| If you mean "I have a mac, is it better to run linux to game?"
|
| Then there's a case for it, since you can run AAA games that
| apple + macos doesn't support / allow.
| GeekyBear wrote:
| Nothing prevents you from running games under emulation on
| MacOS.
|
| Apple and Wine provide the tools, and apps like Whisky make
| them easy to use.
|
| > Essentially, this app combines multiple translation layers
| into a single translation tool. It uses Wine, a translation
| layer that allows Windows apps and games to run on POSIX-
| based operating systems, like macOS and Linux. It also uses
| Rosetta and the Game Porting Toolkit, which are two official
| Apple tools that allow x86 programs to run on Apple Silicon
| and serve as a framework for porting Windows games to macOS,
| respectively.
|
| Normally, this sort of process would require users to
| manually port games to Mac. But by combining Wine, Rosetta,
| and the Game Porting Toolkit, this can all happen
| automatically.
|
| https://www.xda-developers.com/hands-on-whisky-macos-gaming/
|
| However, as aleays, running games under emulation has a
| performance cost.
| kergonath wrote:
| You'd need to compare with what can be done on macOS
| including with things like crossover and the GPT. AFAICT, the
| Linux side is making progress, but still more games can be
| run from macOS.
| talldayo wrote:
| > AFAICT, the Linux side is making progress, but still more
| games can be run from macOS.
|
| I don't believe that's true. According to ProtonDB, 80% of
| the top-1000 most-played games on Steam are confirmed
| working on Linux: https://www.protondb.com/dashboard
|
| I haven't seen any source documenting nearly similar
| success rates with Mac but I also haven't seriously tried
| gaming on Apple Silicon.
| whimsicalism wrote:
| I will have to check this newest development out, but as
| someone who dual boots Asahi and MacOS - up until now MacOS
| with Crossover has definitely been the best experience, if you
| are willing to pay
| mikhael28 wrote:
| 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.
| cherryteastain wrote:
| You can hook up a monitor, mouse and keyboard to your Steam
| Deck to be fair.
| zaptrem wrote:
| 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.
| dcchambers wrote:
| 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.
| duskwuff wrote:
| I wouldn't hold my breath. Valve is still bitter about Apple
| deprecating i386 support back in 2019.
| jsheard wrote:
| 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
| wtallis wrote:
| Apple already provides their Game Porting Toolkit which
| includes a D3D12 to Metal translation later for Wine, and
| it has been integrated into user-friendly Wine
| distributions like Crossover since last year. There's not
| much Proton has to offer over what's already available.
| dcchambers wrote:
| My understanding about the game porting toolkit is that
| it requires developers to specifically modify their game
| in order to make their game compatible.
|
| The magic of Proton from a consumer point of view is that
| it _just works_ for basically every game, sans those with
| Kernel-level anticheat stuff. This means thousands of old
| games that haven 't been updated in years will work.any
| games that don't have active developers.
|
| So Apples solution works for new games but isn't a
| practical option for compatibility for existing games.
| andrewmcwatters wrote:
| 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 .
| JeffeFawkes wrote:
| I've been having good luck on my M1 Max MBP with Whisky, which
| uses Apple's game porting toolkit: https://getwhisky.app/
| whimsicalism wrote:
| I've been able to play a few games with crossover (like
| overwatch 2) fine. Whisky also works for some stuff.
|
| I also run Asahi so will have to check this out to compare
| dcchambers wrote:
| 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.
| tapoxi wrote:
| https://www.pcworld.com/article/2465907/arm-version-of-steam...
| dcchambers wrote:
| That's awesome news!
| rowanG077 wrote:
| 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.
| dcchambers wrote:
| 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.
| inputError wrote:
| Alyssa rules. We all love Alyssa.
| bmicraft wrote:
| An ARM CPU only emulating x86 isn't going to be more efficient
| than straight x86. ARM is barely more efficient as it is at
| those performance levels.
|
| The real reason Apple is ahead is because they're paying for
| more expensive more advanced nodes for their CPUs. I you
| compare CPUs on similar node sizes, you'll see that AMD and
| Intel are basically caught up architecturally in perf/W
| metrics.
| hentrep wrote:
| 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
| ginko wrote:
| How can the site even detect where a user is coming from?
| Browsers leaking this information seems like a huge privacy
| issue to me.
| robin_reala wrote:
| Referer (misspelled in the spec) has been a part of HTTP from
| day 1.
| ginko wrote:
| Feels crazy this isn't disabled by default
| paraboul wrote:
| This is part of the web DNA. Pages linking pages and
| being aware about it. Origin can still disable it.
| Smar wrote:
| 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.
| jsheard wrote:
| 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...
| mananaysiempre wrote:
| 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/110503331622
| 393719
| miki123211 wrote:
| > 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.
| mananaysiempre wrote:
| Ah. Ahhh[1]. I see. <!doctype html>
| <style>a { color: white; background-color: white; }
| a:visited { color: black; }</style> <body><a
| href="https://example.com/abracadabra" onclick="return
| false">you are a bad person</a>
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/CSS/:visited#pr...
| Wowfunhappy wrote:
| > 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.
|
| How do they stop you from using Canvas to see the output
| and send it back?
| zamadatix wrote:
| Canvas can't "see the output", it only sees what is drawn
| in it (which is not a set of HTML tags, it's JS
| commands).
|
| The screen recording/screen sharing API can be used for
| this but security is the reason you have to give explicit
| permission to the site before it can do this.
| bigstrat2003 wrote:
| 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.
| dylan604 wrote:
| It's only slightly less childish than the current WP
| drama.
| npteljes wrote:
| There's a handy addon for Firefox called Privacy Settings
| that can take care of that. Explicitly adds and option to
| have the referers be not sent, and a quick way of re-
| enabling it, in case it breaks a website. Because of
| course that happens too.
| stepupmakeup wrote:
| The manifesto is longer than the content...
| fullstop wrote:
| It's almost as bad as jzw's website:
| https://cdn.jwz.org/images/2016/hn.png (nsfw)
| hentrep wrote:
| He does the same redirect whenever someone links to his DNA
| Lounge: https://dnalounge.com (NSFW)
| justin66 wrote:
| It's completely different. Jwz's is funny.
| dang wrote:
| The URL wasn't updated. You're thinking of
| https://news.ycombinator.com/item?id=41799011, which was a
| separate post.
| hentrep wrote:
| Ah, thanks for clarifying!
| dancemethis wrote:
| Where's the real inspiration for Asahi, Fandaniel in FFXIV?
| rowanG077 wrote:
| > Asahi means "rising sun" in Japanese, and it is also the name
| of an apple cultivar. Xu ringo (asahi ringo) is what we know as
| the McIntosh Apple, the apple variety that gave the Mac its
| name.
| Wowfunhappy wrote:
| > 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!)
| mandarax8 wrote:
| Geometry shaders are not part of base Vulkan. They're an
| extension.
| ornitorrincos wrote:
| they are not an extension, they are part of core 1.0 vulkan.
|
| Although its true that they are an optional feature (as is
| tessellation).
| VHRanger wrote:
| > 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!
| miohtama wrote:
| Why Apple does not just implement it? They have more
| resources than anyone in the world. Patents?
| kelnos wrote:
| Because they don't care. They've decided that Metal is The
| One True Way to write 3D-accelerated apps on macOS, so they
| only implement the things in hardware that Metal requires.
| Wowfunhappy wrote:
| In hardware? I would assume because it takes up space on
| the die, right? It's not free.
| xbar wrote:
| Thank you Alyssa Rosenzweig Asahi Lina
| chaos_princess Davide Cavalca Dougall Johnson
| Ella Stanforth Faith Ekstrand Janne Grunau
| Karol Herbst marcan Mary Guillemard Neal
| Gompa Sergio Lopez TellowKrinkle Teoh Han
| Hui Rob Clark Ryan Houdek
| gertop wrote:
| Marcan and asahi Lina are the same person.
| preisschild wrote:
| Is there actually any proof of that?
| neoromantique wrote:
| And we would care because...?
| ashirviskas wrote:
| Because they were mentioned twice..?
| dyingkneepad wrote:
| Thank not only these people but also their employers for
| funding the work.
| lynguist wrote:
| May I use this space to ask the question: is the M3 substantially
| different from the M1 and M2 that it is not supported?
| gilgoomesh wrote:
| I don't know how different but it apparently has dramatically
| improved hardware shaders compared to earlier M chips so I'm
| guessing that a lot of this might be different, there.
| wmf wrote:
| The M3 GPU added a bunch of features including ray tracing. The
| "dynamic caching" sounds like a big change to local memory
| which could require serious driver changes.
|
| https://www.theverge.com/2023/10/30/23938676/apple-m3-chip-g...
| Thaxll wrote:
| I see that they're using FEX, what about box86? Is it comparable
| in term of performance?
| 58028641 wrote:
| box86 does ARM32 which isn't supported by Apple Silicon
| Thaxll wrote:
| box64 if you prefer.
|
| https://box86.org/2022/03/box86-box64-vs-qemu-vs-fex-vs-
| rose...
| paulryanrogers wrote:
| It is shocking the effort required to have a good gaming
| experience on Apple computers (excluding iOS). They always struck
| me as agnostic to games, yet in recent years it appears to border
| on open hostility.
___________________________________________________________________
(page generated 2024-10-10 23:00 UTC)