On Fri, 2 Oct 2020 at 15:01, Jason Ekstrand <ja...@jlekstrand.net> wrote:
>
> On Thu, Oct 1, 2020 at 10:56 PM Rob Clark <robdcl...@gmail.com> wrote:
> >
> > On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig
> > <alyssa.rosenzw...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
