Home > Linux > Tales of the M1 GPU

Tales of the M1 GPU

Linux 3 Comments

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. The current UAPI also has performance limitations… it can’t even run GPU rendering concurrently with CPU processing yet!

And of course there is still a lot of work to do on the userspace side, improving conformance and performance and adding support for more GL extensions and features! Some features like tesselation and geometry shaders are very tricky to implement (since they need to be partially or fully emulated), so don’t expect full OpenGL 3.2+ for quite a long time.

This article is a detailed look at the work done by Asahi Lina to create a Linux GPU driver for Apple’s M1, after Alyssa Rosenzweig reverse engineered the M1 GPU on macOS. This is a tour de force of excellence, and every current and future M1/M2 Linux user should be thankful for the amazing work these people are doing.

About The Author

Thom Holwerda

Follow me on Twitter @thomholwerda

3 Comments

  1. 2022-11-30 12:38 am
    Alfman

    Thom, you didn’t mention something that stuck out to me…the author is going to use rust instead of C…

    … I started to have a better idea of how the eventual kernel driver had to work and what it had to do. And it had to do a lot! There’s no way around having to juggle the more than 100 data structures involved… and if anything goes wrong, everything can break! The firmware doesn’t sanity check anything (probably for performance), and if it runs into any bad pointers or data, it just crashes or blindly overwrites data! Even worse, if the firmware crashes, the only way to recover is to fully reboot the machine!

    Linux kernel DRM drivers are written in C, and C is not the nicest language to write complicated data structure management in. I’d have to manually track the lifetime of every GPU object, and if I got anything wrong, it could cause random crashes or even security vulnerabilities. How was I going to pull this off? There are too many things to get wrong, and C doesn’t help you out at all!

    On top of that, I also had to support multiple firmware versions, and Apple doesn’t keep the firmware structure definitions stable from version to version! I had already added support for a second version as an experiment, and I ended up having to make over 100 changes to the data structures. On the Python demo, I could do that with some fancy metaprogramming to make structure fields conditional on a version number… but C doesn’t have anything like that. You have to use hacks like compiling the entire driver multiple times with different #defines!
    …
    It would be a gamble… but the more I thought about it, the more my heart told me Rust was the way to go. I had a chat with the Linux DRM maintainers and other folks about this, and they seemed enthusiastic or at least receptive to the idea, so…

    I decided to go for it!
    Rust beginnings

    Since this was going to be the first Linux Rust GPU kernel driver, I had a lot of work ahead! Not only did I have to write the driver itself, but I also had to write the Rust abstractions for the Linux DRM graphics subsystem.

    This is notable and I agree with him about C. That apple’s GPU firmware structures are not stable makes me wonder if these drivers are going to be fragile across apple updates. If they are, it will be ironic that linux could be victim to someone else’s unstable ABIs, haha.

    He points out something else we’ve talked about before…

    While Rust can directly call into C functions, doing that doesn’t have any of Rust’s safety guarantees. So in order to use C code safely from Rust, first you have to write wrappers that give you a safe Rust-like API. I ended up writing almost 1500 lines of code just for the abstractions, and coming up with a good and safe design took a lot of thinking and rewriting!

    This is why it’s so difficult to simply add rust code next to C code in the linux kernel. Naturally safety is one of the main benefits rust brings to the table, yet it becomes less effective when resorting to unsafe C APIs, they are a limiting factor and tons of wrappers are needed. I’m happy to see a significant driver like this testing the waters, although I’m not sure that linux’s traditional C developers are going to be happy to see these kinds of changes.

    Support for vulkan will be pretty neat especially since apple decided not to offer it to their own users.
    https://arstechnica.com/gadgets/2018/02/vulkan-is-coming-to-macos-ios-but-no-thanks-to-apple/