Re: [Mesa-dev] Rust drivers in Mesa
Hi On Fri, 02 Oct 2020 08:04:43 -0700 "Dylan Baker" wrote: > I have serious concerns about cargo and crate usage. Cargo is basically npm > for rust, and shares all of the bad design decisions of npm, including > linking multiple versions of the same library together and ballooning > dependency lists that are fetched intrigued from the internet. This is both a > security problem and directly in conflict with meson's design off one and > only one version of a project. And while rust prevents certain kinds of bugs, > it doesn't prevent design bugs or malicious code. Add a meson developer the > rust community has been incredibly hard to work with and basically hostile to > every request we've made "cargo is hour you build rust", is essentially the > answer we've gotten from them at every turn. And if you're not going to use > cargo, is rust really a win? The standard library is rather minimal "because > just pull in 1000 crates". The distro people can correct me if I'm wrong, but > when librsvg went to rust it was a nightmare, several distros went a long > time without u pdates because of cargo. I can't say much about meson, but using Rust has broken the binaries of several packages on i586 for us; which consequently affects Gnome and KDE. [1][2] Rust uses SSE2 instructions on platforms that don't have them. There's a proposed workaround, but it's not yet clear if that's feasible in practice. Best regards Thomas [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1162283 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1077870 > > On the meson front cargo is incredibly hard to integrate with meson, it's > essentially like calling cmake in autotools. > > Dylan > > On Thu, Oct 1, 2020, at 18:35, Alyssa Rosenzweig 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.
[Mesa-dev] piglit merge access
Hi, I would like to request merge access for piglit gitlab. I have contributed a number of commits for mesa/piglit. It would help in my work because sometimes even already reviewed MRs remain not pushed for months. Regards, Andrii (asimiklit). ___ 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 Tue, Oct 13, 2020 at 12:08 AM Thomas Zimmermann wrote: > > Hi > > On Fri, 02 Oct 2020 08:04:43 -0700 "Dylan Baker" wrote: > > > I have serious concerns about cargo and crate usage. Cargo is basically npm > > for rust, and shares all of the bad design decisions of npm, including > > linking multiple versions of the same library together and ballooning > > dependency lists that are fetched intrigued from the internet. This is both > > a security problem and directly in conflict with meson's design off one and > > only one version of a project. And while rust prevents certain kinds of > > bugs, it doesn't prevent design bugs or malicious code. Add a meson > > developer the rust community has been incredibly hard to work with and > > basically hostile to every request we've made "cargo is hour you build > > rust", is essentially the answer we've gotten from them at every turn. And > > if you're not going to use cargo, is rust really a win? The standard > > library is rather minimal "because just pull in 1000 crates". The distro > > people can correct me if I'm wrong, but when librsvg went to rust it was a > > nightmare, several distros went a long time without u > pdates because of cargo. > > I can't say much about meson, but using Rust has broken the binaries of > several packages on i586 for us; which consequently affects Gnome and KDE. > [1][2] Rust uses SSE2 instructions on platforms that don't have them. There's > a proposed workaround, but it's not yet clear if that's feasible in practice. > > Best regards > Thomas > > [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1162283 > [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1077870 >From the first bug: >Not entirely sure what to do about this. i586 is unsupported by Rust (tier 2) >and as such the package is built for i686 This really sounds like your distro is just building with the wrong rust target for packages targeting an earlier processor. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] piglit merge access
As one of the people guilty of forgetting to push your MRs... this is a very reasonable request, and I support it fully. On 10/13/20 1:12 AM, andrey simiklit wrote: > Hi, > > I would like to request merge access for piglit gitlab. I have > contributed a number of commits for mesa/piglit. It would help in my > work because sometimes even already reviewed MRs remain not pushed for > months. > > Regards, > Andrii (asimiklit). > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rust drivers in Mesa
Hi On Tue, 13 Oct 2020 13:01:58 -0700 Eric Anholt wrote: > On Tue, Oct 13, 2020 at 12:08 AM Thomas Zimmermann > wrote: > > > > Hi > > > > On Fri, 02 Oct 2020 08:04:43 -0700 "Dylan Baker" > > wrote: > > > > > I have serious concerns about cargo and crate usage. Cargo is basically > > > npm for rust, and shares all of the bad design decisions of npm, > > > including linking multiple versions of the same library together and > > > ballooning dependency lists that are fetched intrigued from the > > > internet. This is both a security problem and directly in conflict with > > > meson's design off one and only one version of a project. And while > > > rust prevents certain kinds of bugs, it doesn't prevent design bugs or > > > malicious code. Add a meson developer the rust community has been > > > incredibly hard to work with and basically hostile to every request > > > we've made "cargo is hour you build rust", is essentially the answer > > > we've gotten from them at every turn. And if you're not going to use > > > cargo, is rust really a win? The standard library is rather minimal > > > "because just pull in 1000 crates". The distro people can correct me if > > > I'm wrong, but when librsvg went to rust it was a nightmare, several > > > distros went a long time without u > > pdates because of cargo. > > > > I can't say much about meson, but using Rust has broken the binaries of > > several packages on i586 for us; which consequently affects Gnome and KDE. > > [1][2] Rust uses SSE2 instructions on platforms that don't have them. > > There's a proposed workaround, but it's not yet clear if that's feasible > > in practice. > > > > Best regards > > Thomas > > > > [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1162283 > > [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1077870 > > From the first bug: > > >Not entirely sure what to do about this. i586 is unsupported by Rust (tier > >2) and as such the package is built for i686 > > This really sounds like your distro is just building with the wrong > rust target for packages targeting an earlier processor. Every other language/compiler combination appears to get this right. And even i686 does not require SSE2. As I said before, there might be a workaround. Best regards Thomas Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
