[Mesa-dev] Rust drivers in Mesa

[Alyssa Rosenzweig]

Hi all,

Recently I've been thinking about the potential for the Rust programming
language in Mesa. Rust bills itself a safe system programming language
with comparable performance to C [0], which is a naturally fit for
graphics driver development.

Mesa today is written primarily in C, a notoriously low-level language,
with some components in C++. To handle the impedance mismatch, we've
built up a number of abstractions in-tree, including multiple ad hoc
code generators (GenXML, NIR algebraic passes, Bifrost disassembler). A
higher level language can help avoid the web of metaprogramming and
effect code that is simpler and easier to reason about. Similarly, a
better type system can aid static analysis.

Beyond abstraction, Rust's differentiating feature is the borrow checker
to guarantee memory safety. Historically, safety has not been a primary
concern of graphics drivers, since drivers are implemented as regular
userspace code running in the process of the application calling them.
Unfortunately, now that OpenGL is being exposed to untrusted code via
WebGL, the driver does become an attack vector.

For the time being, Mesa attempts to minimize memory bugs with defensive
programming, safe in-tree abstractions (including ralloc), and static
analysis via Coverity. Nevertheless, these are all heuristic solutions.
Static analysis is imperfect and in our case, proprietary software.
Ideally, the bugs we've been fixing via Coverity could be caught at
compile-time with a free and open source toolchain.

As Rust would allow exactly this, I see the primary benefit of Rust in
verifying correctness and robustness, rather than security concerns per
se.  Indeed, safety guarantees do translate well beyond WebGL.

Practically, how would Rust fit in with our existing C codebase?
Obviously I'm not suggesting a rewrite of Mesa's more than 15 million
lines of C. Instead, I see value in introducing Rust in targeted parts
of the tree. In particular, I envision backend compilers written in part
in Rust. While creating an idiomatic Rust wrapper for NIR or Gallium
would be prohibitively costly for now, a backend compiler could be
written in Rust with IR builders exported for use of the NIR -> backend
IR translator written in C.

This would have minimal impact on the tree. Users that are not building
such a driver would be unaffected. For those who _are_ building Rust
code, the Rust compiler would be added as a build-time dependency and
the (statically linked) Rust standard library would be added as a
runtime dependency. There is concern about the Rust compiler requiring
LLVM as a dependency, but again this is build-time, and no worse than
Mesa already requiring LLVM as a runtime dependency for llvmpipe and
clover. As for the standard library, it is possible to eliminate the
dependency as embedded Rust does, perhaps calling out to the C standard
library via the FFI, but this is likely quixotic. I do regret the binary
size increase, however.

Implications for the build system vary. Rust prefers to be built by its
own package manager, Cargo, which is tricky to integrate with other
build systems. Actually, Meson has native support for Rust, invoking the
compiler directly and skipping Cargo, as if it were C code. This support
is not widely adopted as it prevents linking with external libraries
("crates", in Rust parlance), with discussions between Rust and Meson
developers ending in a stand-still [1]. For Mesa, this might be just
fine. Our out-of-tree run-time dependencies are minimal for the C code,
and Rust's standard library largely avoids the need for us to maintain a
Rust version of util/ in-tree. If this proves impractical in the
long-term, it is possible to integrate Cargo with Meson on our end [2].

One outstanding concern is build-time, which has been a notorious
growing pain for Rust due to both language design and LLVM itself [3],
although there is active work to improve both fronts [4][5]. I build
Mesa on my Arm laptop, so I suppose I'd be hurt more than many of us.
There's also awkward bootstrapping questions, but there is work here too
[6].

If this is of interest, please discuss. It's clear to me Rust is not
going away any time soon, and I see value in Mesa embracing the new
technology. I'd like to hear other Mesa developers' thoughts.

Thanks,

Alyssa

[0] https://www.rust-lang.org/
[1] https://github.com/mesonbuild/meson/issues/2173
[2] https://gitlab.gnome.org/GNOME/fractal/-/blob/master/meson.build
[3] https://pingcap.com/blog/rust-compilation-model-calamity/
[4] https://blog.mozilla.org/nnethercote/2020/04/24/how-to-speed-up-the-rust-compiler-in-2020/
[5] https://github.com/bjorn3/rustc_codegen_cranelift
[6] https://github.com/thepowersgang/mrustc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20201001/a384a1b7/attachment.sig>