5 ms·

Asahi isn't in choppy waters. The new project leadership team made the decision to prioritize getting their existing work upstreamed into the Linux kernel, bef

Asahi isn't in choppy waters. 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. It's been going well.

rowanG077 1y ago
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.
- GeekyBear 1y ago
  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. https://asahilinux.org/2025/05/progress-report-6-15/ https://asahilinux.org/2025/05/progress-report-6-15/ Alyssa didn't abandon the project, she completed it.
  - rowanG077 1y ago
    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.
    - GeekyBear 1y ago
      Yes, and as I mentioned earlier, the new leadership team has decided to upstream the existing work before moving on to work on supporting newer chips.
      - rowanG077 1y ago
        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.
        GeekyBear 1y ago
        > 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?
        rowanG077 1y ago
        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.
        GeekyBear 1y ago
        Alyssa wasn't doing the GPU driver work. 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.
        rowanG077 1y ago
willis936 1y ago
Oh, has Linus clarified Linux's position on rust patches in the kernel? I hadn't heard.
- nixosbestos 1y ago
  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.
  - willis936 1y ago
    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.
    - GeekyBear 1y ago
      > 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". https://lore.kernel.org/lkml/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/ https://lore.kernel.org/lkml/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_...

rowanG077 1y ago

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.

GeekyBear 1y ago
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. https://asahilinux.org/2025/05/progress-report-6-15/ https://asahilinux.org/2025/05/progress-report-6-15/ Alyssa didn't abandon the project, she completed it.
- rowanG077 1y ago
  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.
  - GeekyBear 1y ago
    Yes, and as I mentioned earlier, the new leadership team has decided to upstream the existing work before moving on to work on supporting newer chips.
    - rowanG077 1y ago
      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.
      - GeekyBear 1y ago
        > 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?
        rowanG077 1y ago
        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.
        GeekyBear 1y ago
        Alyssa wasn't doing the GPU driver work. 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.
        rowanG077 1y ago

willis936 1y ago

Oh, has Linus clarified Linux's position on rust patches in the kernel? I hadn't heard.

nixosbestos 1y ago
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.
- willis936 1y ago
  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.
  - GeekyBear 1y ago
    > 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". https://lore.kernel.org/lkml/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/ https://lore.kernel.org/lkml/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_...