<div dir="ltr"><div dir="ltr">On Fri, Oct 2, 2020 at 8:14 AM Dave Airlie <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2 Oct 2020 at 15:01, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> wrote:<br>
><br>
> On Thu, Oct 1, 2020 at 10:56 PM Rob Clark <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> wrote:<br>
> ><br>
> > On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig<br>
> > <<a href="mailto:alyssa.rosenzweig@collabora.com" target="_blank">alyssa.rosenzweig@collabora.com</a>> wrote:<br>
> > ><br>
> > > Implications for the build system vary. Rust prefers to be built by its<br>
> > > own package manager, Cargo, which is tricky to integrate with other<br>
> > > build systems. Actually, Meson has native support for Rust, invoking the<br>
> > > compiler directly and skipping Cargo, as if it were C code. This support<br>
> > > is not widely adopted as it prevents linking with external libraries<br>
> > > ("crates", in Rust parlance), with discussions between Rust and Meson<br>
> > > developers ending in a stand-still [1]. For Mesa, this might be just<br>
> > > fine. Our out-of-tree run-time dependencies are minimal for the C code,<br>
> > > and Rust's standard library largely avoids the need for us to maintain a<br>
> > > Rust version of util/ in-tree. If this proves impractical in the<br>
> > > long-term, it is possible to integrate Cargo with Meson on our end [2].<br>
> > ><br>
> ><br>
> > drive-by comment: for something like a gl driver that a lot of other<br>
> > things depend on, making it harder for us to depend on other external<br>
> > things is actually a good thing<br>
><br>
> Generally, I'm a fan in concept.  Generally, I feel like rust has most<br>
> of what I like from C++ without most of what I don't like.  I<br>
> particularly like it's error handling mechanism, for instance.  That<br>
> said, when it comes to things like the borrow checker, my little bit<br>
> of rust experience says that it doesn't actually remove bugs so much<br>
> as move them around.<br>
><br>
> What's been stopping me is practicalities.  Not only build systems but<br>
> the way in which everything in mesa is interconnected.  Your<br>
> suggestion for building the entire back-end compiler with C-wrapped<br>
> helpers for NIR->compiler translation may be workable.  We might also<br>
> be able to write NIR wrappers sufficient for reading NIR.  It's not<br>
> actually that much API surface if all you want to do is read the data<br>
> structure.<br>
><br>
> I've also thought of breaking off a component like ISL and converting<br>
> it.  However, all the nicely contained pieces are also the ones that<br>
> wouldn't benefit as much. :-/<br>
><br>
<br>
My feeling is the pieces that would benefit the most are the things<br>
touch the real world, GLSL compiler, SPIR-V handling, maybe some of<br>
the GL API space, but I also feel these are the messiest things to<br>
move to rust. I'm not sure you'd get much benefit from vulkan API<br>
space or touching kernel interfaces as much. Granted a backend<br>
compiler might be the easiest place to experiment.<br>
<br>
I think the problem is you really want to justify that whatever you<br>
introduce using rust is sufficiently better along any axis than c/c++<br>
to justify the enhanced build time requirements and maintenance,<br>
otherwise someone will just rewrite it in C/C++ to avoid having to<br>
pull a rust compiler into their distro requires.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Kristian</div></div></div>