Re: [Mesa-dev] Rust drivers in Mesa
Cc'd. On Sun, Oct 04, 2020 at 03:17:28PM +0300, Michael Shigorin wrote: > Hello, > regarding this proposal: > http://lists.freedesktop.org/archives/mesa-dev/2020-October/224639.html > > Alyssa, Rust is not "naturally fit for graphics driver > development" since it's not as universally available as > C/C++ in terms of mature compilers; you're basically > trying to put a cart before a horse, which will just > put more pressure on both Rust developers team *and* > on those of us working on non-x86 arches capable of > driving modern GPUs with Mesa. > > For one, I'm porting ALT Linux onto e2k platform > (there's only an early non-optimizing version of > Rust port there by now), and we're maintaining repos > for aarch64, armv7hf, ppc64el, mipsel, and riscv64 either > -- none of which seem to be described as better than > "experimental" at http://doc.rust-lang.org/core/arch page > in terms of Rust support. > > And there's another problem: no kind of tooling helps > careless developers avoid mistakes as many previous > silver bullet candidates have shown already; some of > those only made things actually worse. > > I am no Mesa developer, my closest contribution to it > is probably an LLVM patch proposal. But I've seen > enough deterioration brought with the best intents > of course -- both in free software during last ten > years or so and in real life (I used to live in Kiev > but not anymore, Denis can witness that if needed). > > PS: feel free to CC: mesa-dev@, of course. > > -- > WBR, Michael Shigorin / http://altlinux.org > -- http://opennet.ru / http://anna-news.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rust drivers in Mesa
On Sun, Oct 4, 2020, 08:19 Alyssa Rosenzweig < alyssa.rosenzw...@collabora.com> wrote: > Cc'd. > > On Sun, Oct 04, 2020 at 03:17:28PM +0300, Michael Shigorin wrote: > > Hello, > > regarding this proposal: > > http://lists.freedesktop.org/archives/mesa-dev/2020-October/224639.html > > > > Alyssa, Rust is not "naturally fit for graphics driver > > development" since it's not as universally available as > > C/C++ in terms of mature compilers; you're basically > > trying to put a cart before a horse, which will just > > put more pressure on both Rust developers team *and* > > on those of us working on non-x86 arches capable of > > driving modern GPUs with Mesa. > > > > For one, I'm porting ALT Linux onto e2k platform > > (there's only an early non-optimizing version of > > Rust port there by now), and we're maintaining repos > > for aarch64, armv7hf, ppc64el, mipsel, and riscv64 either > > -- none of which seem to be described as better than > > "experimental" at http://doc.rust-lang.org/core/arch page > > in terms of Rust support. > AArch64 with Linux is moving to tier 1 support with official support from ARM: https://github.com/rust-lang/rfcs/pull/2959 In my experience on armv7hf and powerpc64le with Linux and on aarch64 on Android (running rustc in termux), I've never had issues with Rust. Jacob Lifshay ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rust drivers in Mesa
On Sun, Oct 4, 2020, 10:13 Jacob Lifshay wrote: > On Sun, Oct 4, 2020, 08:19 Alyssa Rosenzweig < > alyssa.rosenzw...@collabora.com> wrote: > >> Cc'd. >> >> On Sun, Oct 04, 2020 at 03:17:28PM +0300, Michael Shigorin wrote: >> > Hello, >> > regarding this proposal: >> > http://lists.freedesktop.org/archives/mesa-dev/2020-October/224639.html >> > >> > Alyssa, Rust is not "naturally fit for graphics driver >> > development" since it's not as universally available as >> > C/C++ in terms of mature compilers; you're basically >> > trying to put a cart before a horse, which will just >> > put more pressure on both Rust developers team *and* >> > on those of us working on non-x86 arches capable of >> > driving modern GPUs with Mesa. >> > >> > For one, I'm porting ALT Linux onto e2k platform >> > (there's only an early non-optimizing version of >> > Rust port there by now), and we're maintaining repos >> > for aarch64, armv7hf, ppc64el, mipsel, and riscv64 either >> > -- none of which seem to be described as better than >> > "experimental" at http://doc.rust-lang.org/core/arch page >> > in terms of Rust support. >> > Those are the ISA-specific intrinsics, which aren't really necessary for almost all rust code. If your looking for the official support list, see: https://doc.rust-lang.org/nightly/rustc/platform-support.html You can also see the list of official binaries here: https://forge.rust-lang.org/infra/other-installation-methods.html Jacob > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rust drivers in Mesa
On 04.10.20 17:19, Alyssa Rosenzweig wrote: Cc'd. On Sun, Oct 04, 2020 at 03:17:28PM +0300, Michael Shigorin wrote: For one, I'm porting ALT Linux onto e2k platform (there's only an early non-optimizing version of Rust port there by now), and we're maintaining repos for aarch64, armv7hf, ppc64el, mipsel, and riscv64 either -- none of which seem to be described as better than "experimental" at http://doc.rust-lang.org/core/arch page in terms of Rust support. The correct page to check for platform support would be [1]. The page you linked is just about exposing vendor-specific intrinsics within Rust itself, not about what the rust compiler can target. From what I could find, both gcc and llvm appear to lack support for e2k, so that's indeed problematic for the time being. As for the other architectures you mentioned, those should correspond to: aarch64-unknown-linux-gnu armv7-unknown-linux-gnueabihf powerpc64le-unknown-linux-gnu mipsel-unknown-linux-gnu riscv64gc-unknown-linux-gnu All of which are tier 2 targets, can run cargo and rustc, and have full std support. As Jacob already mentioned, aarch64 has a clear path towards tier 1 which is officially driven by ARM. Platform support was also previously discussed at Linux Plumbers Conf back in August [2], [3] with the main takeaway having been IIRC that adding support to Rust isn't that hard once LLVM has support. [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html [2] https://linuxplumbersconf.org/event/7/contributions/804/ [3] https://www.youtube.com/watch?v=FFjV9f_Ub9o&t=2065s ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rust drivers in Mesa
I think it's just going to get more messy and complicated for people who
don't want to learn or use another language. Mesa already requires people
to know C, Python, and now newly Gitlab CI scripts just to get stuff done
and merged. Another language would only exacerbate the issue and steepen
the learning curve.
Marek
On Thu., Oct. 1, 2020, 21:36 Alyssa Rosenzweig, <
alyssa.rosenzw...@collabora.com> wrote:
> Hi all,
>
> Recently I've been thinking about the potential for the Rust programming
> language in Mesa. Rust bills itself a safe system programming language
> with comparable performance to C [0], which is a naturally fit for
> graphics driver development.
>
> Mesa today is written primarily in C, a notoriously low-level language,
> with some components in C++. To handle the impedance mismatch, we've
> built up a number of abstractions in-tree, including multiple ad hoc
> code generators (GenXML, NIR algebraic passes, Bifrost disassembler). A
> higher level language can help avoid the web of metaprogramming and
> effect code that is simpler and easier to reason about. Similarly, a
> better type system can aid static analysis.
>
> Beyond abstraction, Rust's differentiating feature is the borrow checker
> to guarantee memory safety. Historically, safety has not been a primary
> concern of graphics drivers, since drivers are implemented as regular
> userspace code running in the process of the application calling them.
> Unfortunately, now that OpenGL is being exposed to untrusted code via
> WebGL, the driver does become an attack vector.
>
> For the time being, Mesa attempts to minimize memory bugs with defensive
> programming, safe in-tree abstractions (including ralloc), and static
> analysis via Coverity. Nevertheless, these are all heuristic solutions.
> Static analysis is imperfect and in our case, proprietary software.
> Ideally, the bugs we've been fixing via Coverity could be caught at
> compile-time with a free and open source toolchain.
>
> As Rust would allow exactly this, I see the primary benefit of Rust in
> verifying correctness and robustness, rather than security concerns per
> se. Indeed, safety guarantees do translate well beyond WebGL.
>
> Practically, how would Rust fit in with our existing C codebase?
> Obviously I'm not suggesting a rewrite of Mesa's more than 15 million
> lines of C. Instead, I see value in introducing Rust in targeted parts
> of the tree. In particular, I envision backend compilers written in part
> in Rust. While creating an idiomatic Rust wrapper for NIR or Gallium
> would be prohibitively costly for now, a backend compiler could be
> written in Rust with IR builders exported for use of the NIR -> backend
> IR translator written in C.
>
> This would have minimal impact on the tree. Users that are not building
> such a driver would be unaffected. For those who _are_ building Rust
> code, the Rust compiler would be added as a build-time dependency and
> the (statically linked) Rust standard library would be added as a
> runtime dependency. There is concern about the Rust compiler requiring
> LLVM as a dependency, but again this is build-time, and no worse than
> Mesa already requiring LLVM as a runtime dependency for llvmpipe and
> clover. As for the standard library, it is possible to eliminate the
> dependency as embedded Rust does, perhaps calling out to the C standard
> library via the FFI, but this is likely quixotic. I do regret the binary
> size increase, however.
>
> 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].
>
> One outstanding concern is build-time, which has been a notorious
> growing pain for Rust due to both language design and LLVM itself [3],
> although there is active work to improve both fronts [4][5]. I build
> Mesa on my Arm laptop, so I suppose I'd be hurt more than many of us.
> There's also awkward bootstrapping questions, but there is work here too
> [6].
>
> If this is of interest, please discuss. It's clear to me Rust is not
> going away any time soon, and I see value in Mesa embracing the new
> technology. I'd like to hear other Mesa developers' thoughts.
>
> Thanks,
>
> Alyssa
>
> [0] https://www.rust-lang.org/
> [1] https://github.com/mesonbuild/meson/issues/2173
> [2] https://gitlab.gnome.or
Re: [Mesa-dev] Rust drivers in Mesa
The elbrus C/C++ compiler is largely gcc compatible asks supported in meson, so that really shouldn't be a problem. Dylan On Sun, Oct 4, 2020, at 11:24, Alexander Schlichte wrote: > On 04.10.20 17:19, Alyssa Rosenzweig wrote: > > Cc'd. > > > > On Sun, Oct 04, 2020 at 03:17:28PM +0300, Michael Shigorin wrote: > >> For one, I'm porting ALT Linux onto e2k platform > >> (there's only an early non-optimizing version of > >> Rust port there by now), and we're maintaining repos > >> for aarch64, armv7hf, ppc64el, mipsel, and riscv64 either > >> -- none of which seem to be described as better than > >> "experimental" at http://doc.rust-lang.org/core/arch page > >> in terms of Rust support. > The correct page to check for platform support would be [1]. The page you > linked is just about exposing vendor-specific intrinsics within Rust itself, > not about what the rust compiler can target. > > From what I could find, both gcc and llvm appear to lack support for e2k, so > that's indeed problematic for the time being. As for the other architectures > you mentioned, those should correspond to: > > aarch64-unknown-linux-gnu > armv7-unknown-linux-gnueabihf > powerpc64le-unknown-linux-gnu > mipsel-unknown-linux-gnu > riscv64gc-unknown-linux-gnu > > All of which are tier 2 targets, can run cargo and rustc, and have full std > support. As Jacob already mentioned, aarch64 has a clear path towards tier 1 > which is officially driven by ARM. > > Platform support was also previously discussed at Linux Plumbers Conf back in > August [2], [3] with the main takeaway having been IIRC that adding support to > Rust isn't that hard once LLVM has support. > > [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html > [2] https://linuxplumbersconf.org/event/7/contributions/804/ > [3] https://www.youtube.com/watch?v=FFjV9f_Ub9o&t=2065s > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- Dylan Baker dy...@pnwbakers.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
