Asahi Linux May Pursue Writing Apple Silicon GPU Driver In Rust

[Developer12]

Then someone will have to rewrite it in C, I guess...

Lol. I could see Asahi shipping an out-of-tree module written in rust, should official rust support ever get backed out. That would kill any such effort.

[oleid]

Python -> Rust -> C. This is why we typically avoid web developers writing kernel modules. It has to keep getting rewritten from whatever popular prototyping language they chose.

Which web developer are you talking about?

[mdedetrich]

Hah, Indeed. At this point, the Rust code will likely all be in an unsafe{} block anyway and twiddling raw bytes like drivers typically do will pretty much resemble C, so hopefully won't be hard to clean up into a proper implementation language.

Python -> Rust -> C. This is why we typically avoid web developers writing kernel modules. It has to keep getting rewritten from whatever popular prototyping language they chose.

Another example of a person that clearly didn't read the Phoronix article. It was already stated that writing a modern day GPU driver requires a huge amount of concurrent/multithreaded data structures/logic where Rust excels and this is not code that will be in an unsafe block. The only thing that will be in unsafe is mapped registers/pointers and last time I checked that doesn't make a modern GPU driver.

[Developer12]

Hah, Indeed. At this point, the Rust code will likely all be in an unsafe{} block anyway and twiddling raw bytes like drivers typically do will pretty much resemble C, so hopefully won't be hard to clean up into a proper implementation language.

Thanks for demonstrating to everyone that you have absolutely no idea how to program in rust. Sure, you could do that, but nobody actually actually does.
See: the rust for linux project, RedoxOS, hubris, or any library written for rust support on an embedded platform like AVR, STM32, etc.

There are a few wrappers written using unsafe{} to handle the important bits (in this case calling C functions, living in the patches rust-for-linux is trying to get merged) so that the drivers themselves can be 100% safe rust. The rust driver needs to talk to the GPU? great, it can call the wrapper for PCIe access and thus use the underlying kernel PCIe infrastructure like any other driver written in C.

Python -> Rust -> C. This is why we typically avoid web developers writing kernel modules. It has to keep getting rewritten from whatever popular prototyping language they chose.

Not a single web developer has been involved.

[kpedersen]

a modern day GPU driver requires a huge amount of concurrent/multithreaded data structures/logic where Rust excels and this is not code that will be in an unsafe block.

Sure, you say that Rust excels in this but lets wait and see them actually implement this whilst being able to access the required data without resorting to unsafe. This will be the only evidence.

The rust driver needs to talk to the GPU? great, it can call the wrapper for PCIe access and thus use the underlying kernel PCIe infrastructure like any other driver written in C..

And you don't think that will undermine Rusts safety accessing the C infrastructure directly like that? Just gonna be a bunch of binding layers gluing the unsafe API. I am going to assume very heavily that you personally have never accessed any kernel infrastructure safely in Rust before and can only really talk about it rather than doing it?

But again, lets wait and see. Success or failure will be fairly obvious as to the answer and whatever happens the developer does sound capable.

[dkasak]

Then someone will have to rewrite it in C, I guess...

LOL whatever. At least you got the 1st post.

[silmeth]

And you don't think that will undermine Rusts safety accessing the C infrastructure directly like that? Just gonna be a bunch of binding layers gluing the unsafe API.

The whole (regular, userspace) Rust standard library is “just a bunch of bindings layers” gluing pretty unsafe libc and direct syscalls. Everything in it somewhere boils down to some unsafe code calling into generally unsafe C or doing some direct pointer manipulation. And yet it allows you to write userspace programs proven to be memory safe.

Because the Rust APIs provided by those bindings encode the invariants¹ required to safely call the C functions and syscalls directly in the signatures and are enforced by the compiler. That’s the same idea of hiding the unsafety behind safe abstractions in Rust-For-Linux bindings and in any embedded Rust project.

¹stuff like “the returned pointer is valid no longer than any of the input pointers A or B live”, “this pointer cannot be mutated in another thread”, “to call this function on this object you must be holding a valid guard obtained first by that call”, “this needs to be freed using that function”, “this function cannot be called twice on the same object”, “this has to contain valid unicode characters”, etc.

[brad0]

Then someone will have to rewrite it in C, I guess...

Exactly.

[Dukenukemx]

The investigation already happened. An apple M1 openGL driver already exists in python. The answer is basically zero, not that it even matters because asahi didn't use anything from powervr either way.

So does that mean OpenGL is working on the M1 on Linux?

[Brook-trout]

I started out in Slackware. Still use it. But I understand that in a production environment it is not the best of choices. So having a kernel with rust compiled into it is whizbang. But rolling back or upgrading the kernel entails make config.. then compiling and subsequent testing. To make sure all of the module options were properly configured into the kernel. For child programmers who have nothing more to do with their lives. That is fine. But if this is for real work purposes. With real users. You are in for some serious debugging, module configuration, compiling the kernel and testing. Then there are the reports you need to file explaining what the problem was and how you fixed it. Without admitting to the fact that you broke it in the first place.

Then it dawns on you maybe this was not such a great idea afterall.

it takes some real coding experts In kernel building to get this right. But you can not tell a kid that.