Lina: Tales of the M1 GPU

[Posted November 29, 2022 by corbet]

Asahi Lina gives a detailed update on progress toward a graphics driver for Apple M1 hardware.

There is still a long road ahead! The UAPI that we are using right now is still a prototype, and there are a lot of new features that need to be added or redesigned in order to support a full Vulkan driver in the future. Since Linux mandates that the UAPI needs to remain stable and backwards compatible across versions (unlike macOS), that means that the kernel driver will not be heading upstream for many months, until we have a more complete understanding of the GPU rendering parameters and have implemented all the new design features needed by Vulkan.

Lina: Tales of the M1 GPU

Posted Nov 29, 2022 18:12 UTC (Tue) by nix (subscriber, #2304) [Link] (12 responses)

This is amazing! But the most amazing part to me is not the Rust part, but the idea of prototyping the driver in Python using drm-shim, and the result actually *working*.

Lina: Tales of the M1 GPU

Posted Nov 30, 2022 0:05 UTC (Wed) by acarno (subscriber, #123476) [Link]

Every time I read a blog post on the Asahi Linux site, I'm amazed at the sheer talent and passion of the folks on that team. I wish I could muster even a tenth of that in my day-to-day life.

Lina: Tales of the M1 GPU

Posted Nov 30, 2022 5:13 UTC (Wed) by rsidd (subscriber, #2582) [Link] (10 responses)

Yes the whole thing is amazing. And this sort of initiative is the best answer to naysayers like Drew DeVault who actually wrote in early October that Rust is "not likely to infuse Linux with a much-needed boost in its contributor base, because Linux has no such need" (among other negative comments).

If other developers too find that Rust is so much easier for driver development, its use could explode very rapidly.

Lina: Tales of the M1 GPU

Posted Nov 30, 2022 8:56 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (9 responses)

Yeah, I am skeptical about Linux developers migrating in flock to Rust for core code, but for drivers it's a slam dunk.

Lina: Tales of the M1 GPU

Posted Nov 30, 2022 10:57 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (8 responses)

You won't be allowed to write core Linux code in Rust so long as the set of architectures considered first class for Linux isn't a subset of the architectures which at least work in practice (lets say at least Tier 3 support) for Rust. This is because in effect such core code would mean now Linux doesn't run on affected architectures, a major decision. Whereas a new PCIe only SATA device driver in Rust doesn't matter if your Linux architecture doesn't have PCI anyway, you lost nothing.

The architectures which make the difference aren't exactly household names which want the latest GPU drivers, WiFi, etc. but for now there is more than just a hobbyist with a decaying machine in their back room running these systems and Linus shows no signs of wanting to consign them all to the dustbin, meanwhile the Rust teams are more future focused and there's not a lot of NetBSD-style "Hey I wonder if I could port Rust to this 35 year old machine" antics. Some, but not a lot.

I expect that this will change in one or both ways over the next decade, by which time as a result of Rust drivers more Linux developers will have practical kernel experience with Rust and so their views matter in a way that they do not today. "I think this is ugly and I don't understand it" vs "I think this is beautiful although I never tried to use it in the kernel" are opinions, and for your own project that might be enough, but it's not a compelling reason for the kernel. Whereas "The one Rust driver for my area is an endless shitshow, every release I get a dozen bug reports and two dozen patches and it never improves" vs "Literally all of the popular drivers in my area are now Rust, we got three new people who don't know any C writing drivers, I thought our bug email was broken but it turns out nobody reported any bugs for a month, cool." are _informed_ opinions that could influence such a decision once it's possible for core code.

Lina: Tales of the M1 GPU

Posted Dec 1, 2022 4:10 UTC (Thu) by docontra (guest, #153758) [Link]

You won't be allowed to write core Linux code in Rust so long as the set of architectures considered first class for Linux isn't a subset of the architectures which at least work in practice (lets say at least Tier 3 support) for Rust.

This is one of the big motivations for both gcc rust front-end projects 0:) (both for the kernel and for basic user space, specifically librsvg/future core-ish packages written in Rust, and firefox-esr dependencies)

PD: AFAIK, the big architecture support bottleneck for Rust is LLVM, and not things intrinsic to the language/implementation

Lina: Tales of the M1 GPU

Posted Dec 1, 2022 14:21 UTC (Thu) by moltonel (subscriber, #45207) [Link] (2 responses)

The "core Linux parts that can't be written in Rust yet" are probably less extensive than you think. For example, a new network QoS, filesystem, or LSM, basically anything new and optional would be fair game. That may not fit your definition of "core", but to many people it does, so it's worth noting that Rust isn't just for drivers.

On the other hand, any rewrite of existing C code will need a very strong justification, and will probably remain "just an alternate implementation" for a long time.

What will Rust actually be used for in mainline remains a wait-and-see affair. It's great to see enthusiastic reports like this one, but it'll also be interesting to read some neutral and maybe negative feedback.

It'll be a long time before there's a push for Rust in actual core irreplaceable Linux code. Plenty of time for rustc's gcc backend to mature and gcc's Rust frontend to become usable.

Lina: Tales of the M1 GPU

Posted Dec 2, 2022 12:43 UTC (Fri) by smurf (subscriber, #17840) [Link] (1 responses)

> It's great to see enthusiastic reports like this one, but it'll also be interesting
> to read some neutral and maybe negative feedback.

Well … given this kind of well-deserved, and (above all) justified-by-the-mind-boggling-results feedback (I would NOT have expected this level of success for M1/M2 graphics before spring 2023 or later, given the complexity of the task!) you can post all the negative feedback you want, it probably won't affect the eventual result much.

Given all the conventions and constraints you need to adhere to when writing kernel-style C code (with little to no support from the compiler), learning Rust on top of that appears to be a net time saver already.

Support for it will only get better. As a wild guess I'd say 5 years until Rust can be used everywhere in the kernel, 10 until new C code gets deprecated. IMHO we'll start getting patches that replace 100 lines of C with 20 of Rust a lot sooner than anybody had any right to expect a year ago.

Lina: Tales of the M1 GPU

Posted Dec 3, 2022 14:42 UTC (Sat) by scientes (guest, #83068) [Link]

> As a wild guess I'd say 5 years until Rust can be used everywhere in the kernel, 10 until new C code gets deprecated.

I like putting my predictions out 100 years. Then I have zero liability for them being correct.

Lina: Tales of the M1 GPU

Posted Dec 6, 2022 7:36 UTC (Tue) by ssmith32 (subscriber, #72404) [Link] (3 responses)

Yes, but soon, the core of Linux will just be a BPF interpreter, and little else ;)

But, more seriously, even if it's just drivers, that's still quite a bit of kernel code.

Lina: Tales of the M1 GPU

Posted Dec 6, 2022 7:43 UTC (Tue) by fenncruz (subscriber, #81417) [Link] (2 responses)

Then you just need the bpf interpreter written in bpf to complete the cycle.

Lina: Tales of the M1 GPU

Posted Dec 6, 2022 9:22 UTC (Tue) by smurf (subscriber, #17840) [Link]

So? the C compiler is written in C.

Lina: Tales of the M1 GPU

Posted Dec 6, 2022 19:23 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Not a problem. PyPy is written in Python.