[HN Gopher] Writing a Rust GPU kernel driver: a brief introducti...
___________________________________________________________________
Writing a Rust GPU kernel driver: a brief introduction on how GPU
drivers work
Author : losgehts
Score : 179 points
Date : 2025-08-06 16:00 UTC (6 hours ago)
(HTM) web link (www.collabora.com)
(TXT) w3m dump (www.collabora.com)
| Muromec wrote:
| 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 wrote:
| The RK3588 uses the panthor driver that is the subject of the
| article, not panfrost.
| fabiensanglard wrote:
| Great article. But too short. I was just getting excited about it
| and it ended. I look forward reading the other parts.
| Animats wrote:
| 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.
| TZubiri wrote:
| 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.
| UK-AL wrote:
| Rust is important here because it's one of the first(if not the
| first) to use the rust infrastructure for a GPU.
| monocasa wrote:
| The Asahi folks were probably first in this regard.
| dralley wrote:
| It's somewhat relevant given that this is one of the first
| Rust-based GPU drivers for Linux.
| GeekyBear wrote:
| The Asahi Linux team has previously blogged pretty
| extensively about developing the GPU driver for the Apple M
| series SOCs in Rust.
|
| It's also an informative read.
|
| > Paving the Road to Vulkan on Asahi Linux
|
| https://asahilinux.org/2023/03/road-to-vulkan/
| dralley wrote:
| I did say "one of"
| CJefferson wrote:
| 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.
| Animats wrote:
| > 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.)
| Cieric wrote:
| 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 wrote:
| 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!
| taminka wrote:
| very interesting, is there a second part to this? or logical
| continuation...
| steveklabnik wrote:
| It came out today, so I am assuming more will come later.
| skavi wrote:
| 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 wrote:
| The driver described in the article uses the API that the
| userspace Mesa libraries expect.
| skavi wrote:
| ah thanks for the clarification. should have read more
| carefully.
___________________________________________________________________
(page generated 2025-08-06 23:00 UTC)