Great article. But too short. I was just getting excited about it and it ended. I look forward reading the other parts.
Animats · 3h ago
Tune in next week for the next exciting episode, where we will see a command taken off the queue and executed in the GPU!
The abstraction level discussed here is just where data gets passed across the user/kernel boundary. It's mostly queue and buffer management, which is why there are so few operations. The real action happens as queued commands are executed.
There's another stream of command completions coming back from the GPU. Looking forward to seeing how that works. All this asynchrony is mostly not the driver's problem. That's kicked up to the user code level, as the driver delivers completions.
Muromec · 6h ago
Oh, that's cool. I use one of the rk3588 things with panfrost as a desktop and it sometimes bugs out with black or transparent patches in firefox. Weird thing.
rjsw · 4h ago
The RK3588 uses the panthor driver that is the subject of the article, not panfrost.
skavi · 3h ago
Curious as to whether uring_cmd was considered instead of ioctls since this looks green field. Would the benefits have been negligible to nonexistent? If so, why?
rjsw · 3h ago
The driver described in the article uses the API that the userspace Mesa libraries expect.
skavi · 1h ago
ah thanks for the clarification. should have read more carefully.
taminka · 4h ago
very interesting, is there a second part to this? or logical continuation...
steveklabnik · 4h ago
It came out today, so I am assuming more will come later.
TZubiri · 6h ago
I know that "Rust GPU driver" on the titles gets you more clicks than "Arm Mali CSF Based GPU Driver". But isn't this a Arm Mali CSF-based GPU driver?
I hate focusing on the metatools (tools for building tools). It really sounds like the objective here was to build something in Rust. In the article it is even described as "a gpu driver kernel supporting arm mali.." instead of just an arm mali driver
It is a misunderstanding of what the job of writing a driver is, you are connecting some wires between the OS api and the manufacturer api, you are not to build a framework that adds an additional layer of abstraction, sorry to put it so bluntly, but you are not that guy.
Sorry for being rough.
dralley · 5h ago
It's somewhat relevant given that this is one of the first Rust-based GPU drivers for Linux.
GeekyBear · 5h ago
The Asahi Linux team has previously blogged pretty extensively about developing the GPU driver for the Apple M series SOCs in Rust.
I'm not sorry for being rough, you sound like someone who has no idea what a modern GPU driver is like. I haven't written any in about 15 years, and I know it's only gotten worse since then.
Go look in the Linux kernel source code -- GPU drivers are, by lines of code, the single biggest component. Also, lots of drivers support multiple cards. Do you think it would be sensible to have a seperate driver, completely independant, for every single GPU card?
GPU drivers aren't about "connecting some wires" between two APIs, because those two APIs turn out to be quite different.
Of course, feel free to prove me wrong. Show me a GPU driver you've written, go link some wires together.
Cieric · 1h ago
While I won't endorse what the GP said, I wouldn't say that it's only gotten worse. I work for a modern gpu company (you can probably figure out which one from my comment history) on one of the modern apis and they much more closely represent what the gpu does. It's not like how opengl use to be as the gpus hold much less state for you than they use to. However with the new features being added now it is starting to drift apart again and once again become more complex.
CJefferson · 1h ago
That's interesting to know! I keep meaning to try fixing into the AMD stuff (mainly as it seems like the more open source one), but need to find the time to deep dive!
Cieric · 18m ago
Yeah, we also have a gaming and a developer discord where I hang around. So feel free to join and ask questions there.
Animats · 3h ago
> it's only gotten worse since then.
It's worse all the way up. Modern GPUs support a huge amount of asynchronous operations. Applications put commands on queues, and completions come back later. The driver and Vulkan mostly pass those completions upward, until they reach the renderer, which has to figure out what it's allowed to do next.
How well that's done has a huge impact on performance.
(See my previous grumbling about the Rust renderer performance situation. All the great things Vulkan can do for performance are thrown away, because the easy way to do this doesn't scale.)
UK-AL · 6h ago
Rust is important here because it's one of the first(if not the first) to use the rust infrastructure for a GPU.
monocasa · 5h ago
The Asahi folks were probably first in this regard.
The abstraction level discussed here is just where data gets passed across the user/kernel boundary. It's mostly queue and buffer management, which is why there are so few operations. The real action happens as queued commands are executed.
There's another stream of command completions coming back from the GPU. Looking forward to seeing how that works. All this asynchrony is mostly not the driver's problem. That's kicked up to the user code level, as the driver delivers completions.
I hate focusing on the metatools (tools for building tools). It really sounds like the objective here was to build something in Rust. In the article it is even described as "a gpu driver kernel supporting arm mali.." instead of just an arm mali driver
It is a misunderstanding of what the job of writing a driver is, you are connecting some wires between the OS api and the manufacturer api, you are not to build a framework that adds an additional layer of abstraction, sorry to put it so bluntly, but you are not that guy.
Sorry for being rough.
It's also an informative read.
> Paving the Road to Vulkan on Asahi Linux
https://asahilinux.org/2023/03/road-to-vulkan/
Go look in the Linux kernel source code -- GPU drivers are, by lines of code, the single biggest component. Also, lots of drivers support multiple cards. Do you think it would be sensible to have a seperate driver, completely independant, for every single GPU card?
GPU drivers aren't about "connecting some wires" between two APIs, because those two APIs turn out to be quite different.
Of course, feel free to prove me wrong. Show me a GPU driver you've written, go link some wires together.
It's worse all the way up. Modern GPUs support a huge amount of asynchronous operations. Applications put commands on queues, and completions come back later. The driver and Vulkan mostly pass those completions upward, until they reach the renderer, which has to figure out what it's allowed to do next. How well that's done has a huge impact on performance.
(See my previous grumbling about the Rust renderer performance situation. All the great things Vulkan can do for performance are thrown away, because the easy way to do this doesn't scale.)