[Mesa-dev] Rust drivers in Mesa

[Dave Airlie]

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.

Dave.