[Mesa-dev] Rust drivers in Mesa

[Kristian Kristensen]

On Fri, Oct 2, 2020 at 8:14 AM Dave Airlie <airlied at gmail.com> wrote:

> On Fri, 2 Oct 2020 at 15:01, Jason Ekstrand <jason at jlekstrand.net> wrote:
> >
> > On Thu, Oct 1, 2020 at 10:56 PM Rob Clark <robdclark at gmail.com> wrote:
> > >
> > > On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig
> > > <alyssa.rosenzweig at collabora.com> wrote:
> > > >
> > > > 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].
> > > >
> > >
> > > drive-by comment: for something like a gl driver that a lot of other
> > > things depend on, making it harder for us to depend on other external
> > > things is actually a good thing
> >
> > Generally, I'm a fan in concept.  Generally, I feel like rust has most
> > of what I like from C++ without most of what I don't like.  I
> > particularly like it's error handling mechanism, for instance.  That
> > said, when it comes to things like the borrow checker, my little bit
> > of rust experience says that it doesn't actually remove bugs so much
> > as move them around.
> >
> > What's been stopping me is practicalities.  Not only build systems but
> > the way in which everything in mesa is interconnected.  Your
> > suggestion for building the entire back-end compiler with C-wrapped
> > helpers for NIR->compiler translation may be workable.  We might also
> > be able to write NIR wrappers sufficient for reading NIR.  It's not
> > actually that much API surface if all you want to do is read the data
> > structure.
> >
> > I've also thought of breaking off a component like ISL and converting
> > it.  However, all the nicely contained pieces are also the ones that
> > wouldn't benefit as much. :-/
> >
>
> 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.

Kristian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20201002/d057fe9e/attachment.htm>