4 ms·

Exploring Rust for Vulkan drivers, part 1

160 points by mfilion 4y ago

renox 4y ago
I agree that C/C++ implicit conversion rules are bad, but this is why you compile with '-Wconversion'..
the__alchemist 4y ago
I've been using Rust + WGPU using the Vulkan backend for some chemistry visualization and simulation. Working on using Vulkan compute shaders as well. Good experience overall, but it was tough to piece together the engine from the examples and Rust docs. Would have been untenable without a third-party tutorial. Maybe one of the direct Vulkan wrappers would be a better bet? Eg Ash. Seems like the article took a different approach; tough to understand without knowledge about Mesa. (I hadn't heard of it)
- maeln 4y ago
  If you already have some experience with graphics API, the Vulkan documentation/specification directly from Khronos is pretty well done and covers everything.
- monocasa 4y ago
  It's the other side of the equation, about writing a major piece of GPU driver itself in Rust.
- AgentME 4y ago
  I believe that using direct Vulkan wrappers in Rust has the downside that you'll have to write a lot of unsafe Rust code to use them, and that's part of the reason a WebGPU-style API around Vulkan like WGPU is popular in Rust.
- bsder 4y ago
  > it was tough to piece together the engine from the examples and Rust docs. Would have been untenable without a third-party tutorial. This is the problem with using a non C/C++ language for any high-end graphics programming--you step out of the mainline social ecosystem. Consequently, when you need help, you're hosed. As I much as I like Rust, Zig, etc., I would never recommend using them for modern graphics programming unless you have masochistic tendencies.
  - deleted 4y ago
    [deleted]
Slighted 4y ago
While C and C++ are languages that are permissive to the point that bugs can be introduced incredibly easily I don't think they need to be replaced in order to eliminate said bugs, and especially not with a language like Rust. Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them? Is it more efficient in the long run? Will the current people working on Mesa be able to adapt to such a change (Likely irrelevant since they'd probably be the ones leading such changes in the first place if they were to occur)? Are the benefits/improvements even worth the costs in the first place? Is it sustainable (C has been around since... well forever, and it has a very rich, mature ecosystem built around it. Rust on the other hand has been around for a fraction of the time, suffers from core team (corporate) drama, and doesn't have a "fixed" standard like C does with C89/90, C99, C11, etc. as far as I know (Things might've changed in the past few months/year))? I personally can't see it as being necessary for high code quality and safety.
- dcsommer 4y ago
  > Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code This is a false dichotomy. Bugs are concentrated in new code, so the biggest value for Rust is to use it going forward, interoperating with existing C and C++ code. Going backwards and rewriting low bug density code should not be a priority. Both of your alternatives only address existing code.
  - Slighted 4y ago
    Which is why I wrote "Is it more efficient in the long run?" Ideally there would be an open probe into the project as a whole decide whether or not the switch is a good idea, and whether or not such a change should be accomplished with Rust.
    - bluejekyll 4y ago
      This isn’t a simple thing to answer as it’s specific to any given project. If something is millions of lines of code, will anyone ever fund a full rewrite that could take years? In that case finding areas to plug-in Rust is probably the better strategy. See the Linux kernel and drivers being able to be in Rust. On the other hand, if something is only a few thousand lines of code, a rewrite wouldn’t take much time and might be worth it.
Veliladon 4y ago
I 100% support this endeavor and I'm fully down to RIIR for everything but wish to address one slight problem I have with the text: > Recently, we even had one bug which was caused by accidentally truncating a 64-bit unsigned integer to 32 bits deep inside the common Vulkan synchronization code. > It doesn't have implicit type casting so accidental sign promotion or integer truncation doesn't happen. It doesn't have implicit type casting but if you u64 as u32 inside a piece of Rust code it'll overflow panic in debug mode at best but happily wrap around when compiled in release mode at worst.
- heinrich5991 4y ago
  u64 as u32 is defined as wrapping (unfortunately, IMO), so it will never panic, not even in debug mode.
  - tialaramex 4y ago
    I would prefer that u64 as u32 and similar lossy conversions get deprecated in some future Edition encouraging people write try_into and thus take a moment to decide what happens when it won't fit. But yeah, meanwhile the only difference in Rust is that you did explicitly say you wanted the conversion. EtA: the pointer as usize conversions will presumably get deprecated once Aria's provenance experiment is solidified. So that's a precedent for deprecating something like this where the risk outweighs the convenience.
    - swsieber 4y ago
      IIRC they has been at least one proposal working towards that.
- wahern 4y ago
  For the curious (I was), I believe this is the associated commit: https://github.com/Mesa3D/mesa/commit/f2e535e4fed5bdc13e11a443316a4b77cd5eb81a https://github.com/Mesa3D/mesa/commit/f2e535e4fed5bdc13e11a4...
shaunsingh0207 4y ago
Asahi's linux GPU drivers (currently the OpenGL one, and the rust one in the future) are both being written in rust as well.
- 58028641 4y ago
  I think only the kernel side is in Rust. As far as I know the user space is not written in Rust.
fithisux 4y ago
Micro-kernel OSes are a better target for this kind of work.

160 points by mfilion 4y ago

I agree that C/C++ implicit conversion rules are bad, but this is why you compile with '-Wconversion'..

I've been using Rust + WGPU using the Vulkan backend for some chemistry visualization and simulation. Working on using Vulkan compute shaders as well. Good experience overall, but it was tough to piece together the engine from the examples and Rust docs. Would have been untenable without a third-party tutorial. Maybe one of the direct Vulkan wrappers would be a better bet? Eg Ash. Seems like the article took a different approach; tough to understand without knowledge about Mesa. (I hadn't heard of it)

maeln 4y ago
If you already have some experience with graphics API, the Vulkan documentation/specification directly from Khronos is pretty well done and covers everything.
monocasa 4y ago
It's the other side of the equation, about writing a major piece of GPU driver itself in Rust.
AgentME 4y ago
I believe that using direct Vulkan wrappers in Rust has the downside that you'll have to write a lot of unsafe Rust code to use them, and that's part of the reason a WebGPU-style API around Vulkan like WGPU is popular in Rust.
bsder 4y ago
> it was tough to piece together the engine from the examples and Rust docs. Would have been untenable without a third-party tutorial. This is the problem with using a non C/C++ language for any high-end graphics programming--you step out of the mainline social ecosystem. Consequently, when you need help, you're hosed. As I much as I like Rust, Zig, etc., I would never recommend using them for modern graphics programming unless you have masochistic tendencies.
- deleted 4y ago
  [deleted]

Slighted 4y ago

While C and C++ are languages that are permissive to the point that bugs can be introduced incredibly easily I don't think they need to be replaced in order to eliminate said bugs, and especially not with a language like Rust. Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them? Is it more efficient in the long run? Will the current people working on Mesa be able to adapt to such a change (Likely irrelevant since they'd probably be the ones leading such changes in the first place if they were to occur)? Are the benefits/improvements even worth the costs in the first place? Is it sustainable (C has been around since... well forever, and it has a very rich, mature ecosystem built around it. Rust on the other hand has been around for a fraction of the time, suffers from core team (corporate) drama, and doesn't have a "fixed" standard like C does with C89/90, C99, C11, etc. as far as I know (Things might've changed in the past few months/year))? I personally can't see it as being necessary for high code quality and safety.

dcsommer 4y ago
> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code This is a false dichotomy. Bugs are concentrated in new code, so the biggest value for Rust is to use it going forward, interoperating with existing C and C++ code. Going backwards and rewriting low bug density code should not be a priority. Both of your alternatives only address existing code.
- Slighted 4y ago
  Which is why I wrote "Is it more efficient in the long run?" Ideally there would be an open probe into the project as a whole decide whether or not the switch is a good idea, and whether or not such a change should be accomplished with Rust.
  - bluejekyll 4y ago
    This isn’t a simple thing to answer as it’s specific to any given project. If something is millions of lines of code, will anyone ever fund a full rewrite that could take years? In that case finding areas to plug-in Rust is probably the better strategy. See the Linux kernel and drivers being able to be in Rust. On the other hand, if something is only a few thousand lines of code, a rewrite wouldn’t take much time and might be worth it.

Veliladon 4y ago

I 100% support this endeavor and I'm fully down to RIIR for everything but wish to address one slight problem I have with the text: > Recently, we even had one bug which was caused by accidentally truncating a 64-bit unsigned integer to 32 bits deep inside the common Vulkan synchronization code. > It doesn't have implicit type casting so accidental sign promotion or integer truncation doesn't happen. It doesn't have implicit type casting but if you u64 as u32 inside a piece of Rust code it'll overflow panic in debug mode at best but happily wrap around when compiled in release mode at worst.

heinrich5991 4y ago
u64 as u32 is defined as wrapping (unfortunately, IMO), so it will never panic, not even in debug mode.
- tialaramex 4y ago
  I would prefer that u64 as u32 and similar lossy conversions get deprecated in some future Edition encouraging people write try_into and thus take a moment to decide what happens when it won't fit. But yeah, meanwhile the only difference in Rust is that you did explicitly say you wanted the conversion. EtA: the pointer as usize conversions will presumably get deprecated once Aria's provenance experiment is solidified. So that's a precedent for deprecating something like this where the risk outweighs the convenience.
  - swsieber 4y ago
    IIRC they has been at least one proposal working towards that.
wahern 4y ago
For the curious (I was), I believe this is the associated commit: https://github.com/Mesa3D/mesa/commit/f2e535e4fed5bdc13e11a443316a4b77cd5eb81a https://github.com/Mesa3D/mesa/commit/f2e535e4fed5bdc13e11a4...

shaunsingh0207 4y ago

Asahi's linux GPU drivers (currently the OpenGL one, and the rust one in the future) are both being written in rust as well.

58028641 4y ago
I think only the kernel side is in Rust. As far as I know the user space is not written in Rust.

fithisux 4y ago

Micro-kernel OSes are a better target for this kind of work.