Exploring Rust for Vulkan drivers, part 1
collabora.com
collabora.com
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)
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.
> 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.
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.
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.
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.
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.
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.
How well does Rust inter operate with C or C++ code? When you interoperate, do the security issues persist or do they disappear automagically?
So if you have a Rust function that receives a pointer and a length representing the array, it will translate that into a Rust slice by trusting the pointer and length. Of course if the C caller gave a garbage pointer or a length that's bigger than the actual C array, then the "safe" Rust code that uses that slice will still be illegal.
C++ interop has some additional complexity because of templates, methods, inheritance, etc, that's handled by the cxx Rust library. I don't know much about it.
As to the security issues persisting, yes, the C security issues will persist. But, what’s nice is that the Rust code is safe and you just need to attest to the compiler that the usage of those C APIs is safe. Essentially the Rust code is safe, but it’s still your responsibility to prove that the C code is safe.
This is for the NVK project, which is creating an open source GPU driver for NVIDIA GPUs. The project has a number of considerations that are not in the blog post:
> The unfortunate reality is that, while the original nouveau drivers were written by some amazing engineers and were state-of-the-art a decade ago, they have fallen behind in the last several years. The few developer hours it gets are mostly spent on basic hardware enablement and trying to get new OpenGL versions, leaving the systemic and architectural issues unaddressed.
You can find more complete rationale in their announcement blog post, and it seems very thoughtful: https://www.collabora.com/news-and-blog/news-and-events/intr...
If you want Yet Another Example of using Rust to write GPU drivers, you can look at the other Mesa driver in development (for the Apple AGX GPUs): https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ (see "Rust is magical!")
One thing you're missing is that "comb[ing] through the currently existing code manually" doesn't help you in the future. Unless you have an absolute code freeze new code keeps getting written which can (depending on the language) affect the correctness of distant already reviewed code. So even if you can absolutely ensure that the code as it exists today is perfect (which is already an exceedingly thing to do), you need to keep that effort up continuously, lest a code change causes prior invariants to no longer be met.
A ton of data about software bugs and vulnerabilities, as well as history, seems to disagree with you here.
I suppose in the most permissive use of the term "can", sure you "can" eliminate all those bugs in C/C++ code bases, but at what cost? Formal verification? A code review process that has requirements similar to those imposed on people working on spaceship and airliner avionics software? That's impractical for the vast majority of projects.
It just seems more sensible to use a language that eliminates certain classes of bugs entirely. Rust does that, at least for some classes of bugs. I'll grant you that maybe Rust isn't the correct answer here, but C (and even C++) IMO need to be relegated to the past.
I recently got re-involved in a C-based open source project that I used to work on ~15 years ago. In the intervening time, most of my work has been done using JVM languages, and, more recently, Rust. Going back to C has been tedious and error-prone. The language is awkward to use, and its type system is a joke. I would absolutely love to be able to work in Rust instead, or... really, anything else.
> 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?
Neither, and that's not what the article in question is proposing doing.