6 ms·

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 f

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 1y 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 1y ago
  The Asahi folks were probably first in this regard.
amiga386 1y ago
[flagged]
- UK-AL 1y ago
  Because rewriting the kernel from scratch would literally cost billions. That's why. Literally criticising them for not achieving an impossible goal.
- dralley 1y ago
  The Rust integration for Linux was invited and greenlit by Linus and Greg KH.
- Ar-Curunir 1y ago
  People are already trying to make their own kernels in Rust. You just don’t hear about those because it takes a fuckton of time to build a useful kernel
- perching_aix 1y ago
  There are several kernel and OS projects as well, they get posted here from time to time. Doesn't stop people from coming up with some other slander in those cases of course.
- timeon 1y ago
  As already stated, there are also Rust kernels being written - like they are in other languages as well. Interesting how Rust makes some people so insecure. Already 2 levels in this thread.
- nextaccountic 1y ago
  There is https://www.redox-os.org https://www.redox-os.org which is written from scratch in Rust
dralley 1y ago
It's somewhat relevant given that this is one of the first Rust-based GPU drivers for Linux.
- GeekyBear 1y ago
  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/ https://asahilinux.org/2023/03/road-to-vulkan/
  - dralley 1y ago
    I did say "one of"
CJefferson 1y ago
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 1y 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.)
  - shmerl 1y ago
    Why would Rust rendering be worse than any other rendering? Rust claims to be well suited for handling parallelism.
    - MindSpunk 1y ago
      It is fantastic for CPU parallelism. The problem is the CPU/GPU boundary is difficult to deal with and exposing an API that is both fast and safe and flexible is almost impossible. I don't believe it's possible to make an efficient API at a similar level of abstraction to Vulkan or D3D12 that is safe (as in, not marked unsafe in rust). To do so requires recreating all the complexity of D3D11 and OpenGL style APIs to handle resource access synchronization. The value proposition of D3D12 and Vulkan is that the guardrails are gone and it's up to the user to do the synchronization work themselves. The advantage is that you can make the synchronization decisions at a higher level of abstraction where more assumptions can be made and enforced by a higher-level API. Generally this is more efficient because you can use much simpler algorithms to decide when to emit your barriers, rather than having the driver reverse engineer that high-level knowledge from the low-level command stream. Rust is just not capable of representing the complex interwoven ownership and synchronization rules for using these APIs without mountains of runtime checks that suck away all the benefit of using these APIs. Lots of Vulkan map quite well to Rust's ownership rules, the memory allocation API surface maps very well. But anything that's happening on the GPU timeline is pretty much impossible to do safely. Rust's type system is not sufficiently capable of modeling this stuff without tons of runtime checks, or making the API so awful to use nobody will bother. I've seen GP around a lot and afaik they're using WGPU which is, among other things, Firefox's WebGPU implementation. The abstraction that WebGPU provides is entirely the wrong level to most efficiently use Vulkan and D3D12 style APIs. WebGPU must be safe because it's meant to get exposed to JS in a browser, so it spends a boat load of CPU time to do all the runtime checks and work out the synchronization requirements. Rust can be more challenging here because if you want a safe API you have to be very careful in where you set the boundary between the unsafe internals and the safe API. And Rust's safety rails will be of limited use for the real difficult parts. I'm writing my own abstraction over Vulkan/D3D12/Metal and I've intentionally decided not to make my API safe and to leave it to a higher layer to construct a safe API.

UK-AL 1y 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 1y ago
The Asahi folks were probably first in this regard.

amiga386 1y ago

[flagged]

UK-AL 1y ago
Because rewriting the kernel from scratch would literally cost billions. That's why. Literally criticising them for not achieving an impossible goal.
dralley 1y ago
The Rust integration for Linux was invited and greenlit by Linus and Greg KH.
Ar-Curunir 1y ago
People are already trying to make their own kernels in Rust. You just don’t hear about those because it takes a fuckton of time to build a useful kernel
perching_aix 1y ago
There are several kernel and OS projects as well, they get posted here from time to time. Doesn't stop people from coming up with some other slander in those cases of course.
timeon 1y ago
As already stated, there are also Rust kernels being written - like they are in other languages as well. Interesting how Rust makes some people so insecure. Already 2 levels in this thread.
nextaccountic 1y ago
There is https://www.redox-os.org https://www.redox-os.org which is written from scratch in Rust

dralley 1y ago

It's somewhat relevant given that this is one of the first Rust-based GPU drivers for Linux.

GeekyBear 1y ago
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/ https://asahilinux.org/2023/03/road-to-vulkan/
- dralley 1y ago
  I did say "one of"

CJefferson 1y ago

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 1y 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.)
- shmerl 1y ago
  Why would Rust rendering be worse than any other rendering? Rust claims to be well suited for handling parallelism.
  - MindSpunk 1y ago
    It is fantastic for CPU parallelism. The problem is the CPU/GPU boundary is difficult to deal with and exposing an API that is both fast and safe and flexible is almost impossible. I don't believe it's possible to make an efficient API at a similar level of abstraction to Vulkan or D3D12 that is safe (as in, not marked unsafe in rust). To do so requires recreating all the complexity of D3D11 and OpenGL style APIs to handle resource access synchronization. The value proposition of D3D12 and Vulkan is that the guardrails are gone and it's up to the user to do the synchronization work themselves. The advantage is that you can make the synchronization decisions at a higher level of abstraction where more assumptions can be made and enforced by a higher-level API. Generally this is more efficient because you can use much simpler algorithms to decide when to emit your barriers, rather than having the driver reverse engineer that high-level knowledge from the low-level command stream. Rust is just not capable of representing the complex interwoven ownership and synchronization rules for using these APIs without mountains of runtime checks that suck away all the benefit of using these APIs. Lots of Vulkan map quite well to Rust's ownership rules, the memory allocation API surface maps very well. But anything that's happening on the GPU timeline is pretty much impossible to do safely. Rust's type system is not sufficiently capable of modeling this stuff without tons of runtime checks, or making the API so awful to use nobody will bother. I've seen GP around a lot and afaik they're using WGPU which is, among other things, Firefox's WebGPU implementation. The abstraction that WebGPU provides is entirely the wrong level to most efficiently use Vulkan and D3D12 style APIs. WebGPU must be safe because it's meant to get exposed to JS in a browser, so it spends a boat load of CPU time to do all the runtime checks and work out the synchronization requirements. Rust can be more challenging here because if you want a safe API you have to be very careful in where you set the boundary between the unsafe internals and the safe API. And Rust's safety rails will be of limited use for the real difficult parts. I'm writing my own abstraction over Vulkan/D3D12/Metal and I've intentionally decided not to make my API safe and to leave it to a higher layer to construct a safe API.