Damn impressive if true, but I’ll be honest, I still don’t feel the need to replace my M1 iPad Pro or my M1 Pro Macbook Pro. They’re both more than amazing for my use cases - though if Apple suddenly took gaming seriously, like extending Rosetta to act as a translation layer for Windows games a la Proton, I’d gladly throw down for an M5 Ultra when it’s released.
> though if Apple suddenly took gaming seriously, like extending Rosetta to act as a translation layer for Windows games a la Proton, I’d gladly throw down for an M5 Ultra when it’s released
No joke, if I could run my Steam library on my phone, I'd probably buy a new phone every year (and might need to, given what the thermals and rapid charge/discharge cycles would do to battery longevity). But Apple's current strategy is to provide a tool, then let developers do the work themselves; compare to Valve's efforts (and occasionally stepping on rakes when games update themselves).
I completely agree. I've worked on the Whisky project and am fairly familiar with WINE, Proton, and CrossOver. Proton uses the underlying technology of WINE, which is largely supported by CodeWeavers, who mainly create CrossOver, essentially Proton for MacOS. CodeWeavers also supported the creation of GPTK, which uses WINE as well. CrossOver, considering it's live-translating Windows x86 calls to MacOS x86 calls, and then piping that through Rosetta, works INCREDIBLY well on my M1 Pro. Elden Ring was easily out-performing there than on my Steam Deck.
As far as I can tell, the main issue for putting CrossOver on iOS is a lack of API support and an inability for iOS software to start new processes. AltStore and emulators on iOS are exciting, and with iPadOS and MacOS becoming increasingly similar, I hope to see someone give WINE on iOS a shot.
I would love to see a world where I can play my Steam library on my iPad or my iPhone, considering the wild amount of performance they can output, but the limitations of iOS make it very difficult or likely impossible.
This is simply not true anymore. I really believe when the App Store started, they did not see it as a profit center, but in the last 10 years, the bean counters took over.
There have been credible rumors that Valve is experimenting with an ARM-based SteamOS for the next Steam Deck which would bring quite a lot of games to mobile.
You can already do this with tools like Winlator of course, but Valve's performance patches would probably make the whole process a lot easier to get working easily.
Any such feature would come to Apple hardware last because of Apple's arbitrary software limitations (maybe it'll work in the EU?), of course, but once Proton goes full ARM, it's only a matter of time.
So this doesn't help for iOS, but through the power of WINE and other cool tools, you actually can: https://gamehub.xiaoji.com/
These are especially great on the various Android based gaming handhelds that are out now with Snapdragon 8 Gen 3 and similar SoC's in them, but it works on a phone too
The problem is they don't "let the developers do the work themselves"
If only the platform was open enough that developers had real access, Apple might get away with like you say not providing first party support for gaming.
I mean it more as a counterpoint to what Valve is doing: games are automatically opted-in to working with Proton and pass through a Valve-operated certification program. Because developers aren't part of that loop, you see occasional cases where games issue updates that break compatibility, with users blaming developers based on an outdated, Valve-provided certification.
> To registered developers, with no upstream or downstream support whatsoever.
It's open source, you don't have to be registered with anything.
Wine already uses it.
Buy the commercial version of Wine for Mac, and you get end user support.
> It's quite exciting to have two competing standards like this,
Wine is the single open standard here.
> Being a fork of Wine, Proton maintains very similar compatibility with Windows applications as its upstream counterpart... Proton generally lags behind its upstream Wine base by several releases.
Apple and Valve are just providing layers that translate graphics API calls from the Windows standard DirectX API to Metal on Mac or Vulkan on Linux that Wine can use to support games on those platforms.
However, Proton lags behind on features available in the newer versions of upstream Wine.
In all honesty, I don't think cpu has ever been a huge limitation for me outside of gaming. The biggest bottlenecks for me have always been disk speed and memory. My soon-to-be decade old xps 13 gets on well enough, except it only has 8gb of soldered on ram. That absolutely is a bottle neck for me.
Bear in mind, my personal laptop rarely compiles massive projects. I think the last large thing I compiled by hand was wine, and it's been a while since I've done that. Most of the coding done on that laptop are small toy applications to test a language feature. It also helps that golang is lightning fast when it comes to compile times.
I know Asahi is in choppy waters this year, but it is a seriously impressive project in (imo) a good state. I was surprised that I could run a one-liner script and an hour later play a 32-bit windows x86 3D openGL game on an ARM apple machine with reasonable performance.
The new project leadership team made the decision to prioritize getting their existing work upstreamed into the Linux kernel, before working on supporting newer SOCs.
I agree with that somewhat. But they still lost their main GPU kernel driver developer AND Also their uber productive user space GPU driver developer. With especially the loss of Alyssa leaving a basically unfillable hole.
Alyssa's work was already upstreamed in May, and the driver is ready to go when the kernel is ready to accept Rust GPU drivers.
> We are pleased to announce that our graphics driver userspace API (uAPI) has been merged into the Linux kernel. This major milestone allows us to finally enable OpenGL, OpenCL and Vulkan support for Apple Silicon in upstream Mesa. This is the only time a graphics driver’s uAPI has been merged into the kernel independent of the driver itself, which was kindly allowed by the kernel graphics subsystem (DRM) maintainers to facilitate upstream Mesa enablement while the required Rust abstractions make their way upstream. We are grateful for this one-off exception, made possible with close collaboration with the kernel community.
Sure for M1/M2 it's somewhat correct that it is "completed". M3 and beyond have a lot of GPU differences though(A completely new microcode afaik), so the loss is still traumatic. I also don't think GPU perf is on the level of OSX though I did not do a recent one to one bench.
yes you said that. That doesn't mean losing two very important team members who both have unique skillset just doesn't have any impact. You really can't just waive that away with "New leadership has decided to upstream the existing work before moving on to work on supporting newer chips". That Alyssa is no longer involved definitely is a huge loss for Asahi, I'm very surprised you can even attempt to deny this.
> That Alyssa is no longer involved definitely is a huge loss for Asahi
Are you under the impression that Linux is about to abandon OpenGL and Vulkan in favor of a new graphics API that only Alyssa could possibly implement?
No. I am under the impression that there is no replacement on the horizon that could take on the challenge of further optimizing the GPU driver and work on M3/M4/M5 GPU support once upstreaming efforts have settled down.
Marcan already provided the tools needed to capture the data being passed back and forth between MacOS and the GPU, so you can see exactly what the newer versions of the SOC are doing that is different.
I think you are confused. There are two drivers here. The kernel space driver mostly developed by lina. And the user space driver developed by Alyssa. Both are drivers. And of the two the user space driver is an order of magnitude more complex.
Alyssa's userspace work that I've already mentioned has been completed and upstreamed?
> We are pleased to announce that our graphics driver userspace API (uAPI) has been merged into the Linux kernel. This major milestone allows us to finally enable OpenGL, OpenCL and Vulkan support for Apple Silicon in upstream Mesa.
Sure for M1/M2 it's somewhat correct that it is "completed". M3 and beyond have a lot of GPU differences though(A completely new microcode afaik), so the loss is still traumatic. I also don't think GPU perf is on the level of OSX though I did not do a recent one to one bench.
> With Linux 6.16 now out in the wild, it’s time for yet another progress report! As we mentioned last time, the Asahi and Honeykrisp Mesa drivers have finally found their way upstream. This has resulted in a flurry of GPU-related work, so let’s start there.
Seems that they are doing pretty well upstreaming their work.
Rust has been in the kernel for sometime now? With 6.18 to include significantly more including arguably the single most important component of Android, binder, entirely re-written in Rust.
Yes, it has. Marcan left Asahi and Linux after the DMA maintainer rejected their patch on non-technical grounds and labeled Rust as cancer for maintainers. So Linus supports Rust in the kernel, Rust patches come in, some maintainers reject them, there is no guidance on where or how Rust will or will not be accepted. Just do a bunch of free work and roll the gatekeeping dice. Very healthy and not abusive.
> there is no guidance on where or how Rust will or will not be accepted
Guidance was provided...
> Maintainers who want to be involved in the Rust side can be involved in it, and by being involved with it, they will have some say in what the Rust bindings look like. They basically become the maintainers of
the Rust interfaces too.
But maintainers who are taking the "I don't want to deal with Rust"
option also then basically will obviously not have to bother with the Rust bindings - but as a result they also won't have any say on what goes on on the Rust side.
So when you change the C interfaces, the Rust people will have to deal
with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C
developers that don't want to deal with Rust issues in the promise
that they don't have to deal with Rust.
But that "wall of protection" basically goes both ways. If you don't want to deal with the Rust code, you get no say on the Rust code.
Put another way: the "nobody is forced to deal with Rust" does not
imply "everybody is allowed to veto any Rust code".
Why should you need to replace your M1 machine? Quality products tend to stay with us for a longer time. Apple still has billions of people without any of their devices to sell their new machines to.
Yup. I've got an M1 Pro from work, and while I'm looking forward to hopefully getting an M5 in December, I really don't know if it will be a significant increase in my daily tasks or enjoyment. I do have an M4 Pro Mini that's a bit snappier, but it isn't night and day difference.
I use my M1 Max MacBook Pro for pretty serious CFD with OpenFoam. It’s astonishing how good it is… but a newer machine would be nearly 2x faster, which matters when single runs can take 1-3 hours.
