[Mesa-dev] Rust drivers in Mesa

Daniel Stone daniel at fooishbar.org
Fri Oct 2 09:41:59 UTC 2020


On Fri, 2 Oct 2020 at 08:31, Kristian Kristensen <hoegsberg at google.com> wrote:
> On Fri, Oct 2, 2020 at 8:14 AM Dave Airlie <airlied at gmail.com> wrote:
>> My feeling is the pieces that would benefit the most are the things
>> touch the real world, GLSL compiler, SPIR-V handling, maybe some of
>> the GL API space, but I also feel these are the messiest things to
>> move to rust. I'm not sure you'd get much benefit from vulkan API
>> space or touching kernel interfaces as much. Granted a backend
>> compiler might be the easiest place to experiment.
>> I think the problem is you really want to justify that whatever you
>> introduce using rust is sufficiently better along any axis than c/c++
>> to justify the enhanced build time requirements and maintenance,
>> otherwise someone will just rewrite it in C/C++ to avoid having to
>> pull a rust compiler into their distro requires.
> Just as a data point, in ChromeOS we already build core parts of the OS with rust. Our hypervisor (crosvm) is written in rust and using rust is generally encouraged. That's just one distro, of course, but my sense is that rust isn't going away - parts of GNOME are moving to rust as well - and it's a good fit for a project like mesa. If we could agree that a rust dependency in a gallium backend isn't any worse than a C++ backend (not talking about subjective qualities of the languages, just build time deps), then it's not so much a matter of "justifying" the use of rust, but a developer preference. When we write a new compiler backend in modern C++, I don't think that there's unanimous agreement that that's better than C along all axises, so it's a bit of a high bar to raise for rust.
> I would also worry less about which components supposedly would theoretically benefit the most from being written in rust. The GLSL front might be better in rust, but rewriting it is a big investment and will introduce more bugs and regressions before it gets to that hypothetical ideal state, for a codebase that's otherwise in stasis. I think it makes more sense to apply the benefits of rust to live code - code that we work on and write every day, since that way we get to actually benefit from the features of the language. I'm in favor of figuring out how to integrate rust code in mesa and maybe rewrite a small helper library or binary to rust or incrementally start converting a compiler backend or driver.

Yep. Before we can land a single bit of code, we need to do a bunch of
annoying things like build-system integration, FFI bridging, agreeing
on conventions and style, etc etc. Trying to do that whilst also
replacing the GLSL compiler or vtn is way too much; it's 100% doomed
to failure, even if they're the highest-value targets on some axes.

If you start with a leaf node somewhere greenfield (like a new Vulkan
driver, or a new experimental backend), it makes it much easier to
approach, because you've cut down on the number of moving parts (e.g.
maintaining APIs in two directions), you don't have to replace
something which already exists and people don't want to regress, and
it also allows people who don't really care about it to ignore it
until you've got all the impedance mismatches and teething pain
figured out. After that you'll have a reasonable template for how you
bridge the two language worlds and how you handle particular patterns,
which others can replicate and improve on, than having to bridge the
entire codebase in one go just to get anything working.

But even then, there's a lot more to Rust than 'woo now everything is
secure'. Complex state trackers like the GL API implementation could
get a bunch of help from the type system; things like backends can get
a lot smaller as collect/iterate/match/transform is much better
supported by the language than it is in C. So the benefit in that
case, apart from developer ergonomy of not having to write the same
trivial patterns over and over again, is that the important parts of
code becomes a lot easier to reason about.


More information about the mesa-dev mailing list