Apple M1 Linux GPU DRM Driver Now Running GNOME, Various Apps

[phoronix]

Phoronix: Apple M1 Linux GPU DRM Driver Now Running GNOME, Various Apps

It was just yesterday that reverse-engineering, open-source driver developer Asahi Lina got the display output working and running Wayland's Weston. After a long day hacking away on this first Rust-written Direct Rendering Manager (DRM) driver, the GNOME desktop is even running off this Apple M1 graphics driver as well as applications like Firefox complete with YouTube...

https://www.phoronix.com/news/Apple-DRM-GNOME-And-Apps

[zcansi]

In the stream she does mention that it currently works this well due to a *giant* hack: basically turning the GPU off and on again after every frame, to bypass a caching issue which causes hangs. This does give decent frame rates but it's obviously not something which is acceptable for the final code.

This is mainly great because it unblocks Alyssa Rosenzweig, who can now start finding and squishing bugs in the userland OpenGL stack which only appear on X11 and various Linux applications (previously she was only able to run it either on OSX or via the super slow remote Python driver).

[rhysperry111]

EDIT: Seems zcansi beat me to it lol

She was having problems with some sort of cache yesterday which meant that apps couldn't be run. This morning she got all that stuff working by implementing a hack that just turns the GPU off and on after every render/frame(?), clearing the cache.

So, she still needs to work out a proper fix for the cache - which should perform a lot better than it does right now turning the GPU off after every frame/render - but today she's busy so I think she'll get to looking into that on Friday.

Well done Lina :3

[silmeth]

She added some context to the hacks used and how writing the driver in Rust felt in a tweet:

On the Rust side, I have to say I'm super pleased with my experience writing a driver like this in Rust! I've had zero concurrency issues (and the driver uses fine-grained locking, there's no big driver lock) - once single processes worked, running multiple apps concurrently just worked. Also zero memory leaks, dangling CPU or GPU pointers, use-after frees / free order mistakes, or anything like that! The only memory corruption issues I ran into were either fundamental mistakes in my unsafe DRM abstraction or core GPU memory management code, or happened from the GPU side (there's an issue with TLB invalidation, that's what the ugly workaround is for). I feel like Rust encourages good driver design and then the compiler goes a long way towards making the resulting code correct. All in all I didn't really have that many bugs to fix, mostly just logic issues (both because I'm new to DRM and because the GPU interface is all reverse engineered and we're still working out the details.

The workaround for the GPU-side TLB inval issue has a large performance hit, but without that, kmscube does run at 1000+ FPS, and that's with a lot of suboptimal components that will be improved over time (e.g. my current allocator allocates/maps/unmaps/frees tons of little GPU structures per frame), so I'm also very optimistic about the performance aspect!

The only major Rust issue I ran into is the lack of placement new, which I ended up working around with a very ugly place!() macro (it still has a soundness issue too, I need to fix it to drop things if initialization fails halfway through). Without that, I was quickly overflowing the kernel stacks (which is particularly ugly to debug without CONFIG_VMAP_STACK, which I didn't have set at first...). With the macro though, the stack frames are under control enough that there's no issue, but I'd really love to see core language support for this. I think it's really necessary for kernel/embedded development.

[Anux]

This goes really fast forward, didn't expect such speed.

[gustavoar]

What are the legal implications of mainlining this? Reverse engineering to my knowledge is a breach of IP.
Apple can sue cause of this, I doubt that they would do this to the open source community, but they could.

[JPFSanders]

What are the legal implications of mainlining this? Reverse engineering to my knowledge is a breach of IP.
Apple can sue cause of this, I doubt that they would do this to the open source community, but they could.

No it is not. Only in the case that is used for nefarious purposes like "copyright infringement". Reverse engineer for the sake of making software for a device you own is not and has never been illegal.

[EvilHowl]

No it is not. Only in the case that is used for nefarious purposes like "copyright infringement". Reverse engineer for the sake of making software for a device you own is not and has never been illegal.

You're right.

As a side note, It would probably be illegal if she reversed engineered the GPU interface using knowledge directly gathered from some kind of leak or data breach. This is where clean-room designs come into play, like we have seen in the emulation scene.

Of course, this is not the case, so this should be absolutely legal.

[gustavoar]

No it is not. Only in the case that is used for nefarious purposes like "copyright infringement". Reverse engineer for the sake of making software for a device you own is not and has never been illegal.

Awesome, I was just asking because Apple tends to be very protective of their products.

[anarki2]

Awesome, I was just asking because Apple tends to be very protective of their products.

Not really, Linux has been running on Macbooks since forever and there were no lawsuits because of that.