Hi, On Fri, 2 Oct 2020 at 08:31, Kristian Kristensen <hoegsb...@google.com> wrote: > On Fri, Oct 2, 2020 at 8:14 AM Dave Airlie <airl...@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. Cheers, Daniel _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev