Re: [Mesa-dev] Rust drivers in Mesa
On Wed, Oct 14, 2020 at 3:26 PM Alyssa Rosenzweig wrote: > > > Since the majority opinion seemed to be "if someone wanted to use it > > in a leaf node without making everyone use it, that's fine", I've > > started trying to put together the CI bits necessary to enable it. > > Currently fighting with meson cross files a bit, but the linting works > > and the amd64 build works. > > > > https://gitlab.freedesktop.org/anholt/mesa/-/commits/ci-rust > > Good luck :) > > I didn't think to enforce a lint during CI. Part of me wonders if we > should be doing that for C too, but we can shave that yak sometime else. I don't think style-linting C is reasonable, but doing pep8 linting would be nice. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rust drivers in Mesa
> Since the majority opinion seemed to be "if someone wanted to use it > in a leaf node without making everyone use it, that's fine", I've > started trying to put together the CI bits necessary to enable it. > Currently fighting with meson cross files a bit, but the linting works > and the amd64 build works. > > https://gitlab.freedesktop.org/anholt/mesa/-/commits/ci-rust Good luck :) I didn't think to enforce a lint during CI. Part of me wonders if we should be doing that for C too, but we can shave that yak sometime else. signature.asc Description: PGP signature ___ 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. > > To some extent I agree, and I think that's a good reason to start with > Rust in a leaf-node of the project (a driver or compiler backend) > rather than in a common piece of infrastructure. Indeed, at least to probe the waters I'm interested in a backend compiler, which necessarily only touches a few people and a few architectures (fewer cross-platform issues. Mali is only* ever paired with ARM CPUs, which have a good Rust story). * We don't talk about SoFIA signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] piglit merge access
On Tue, Oct 13, 2020 at 1:13 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. I've added you now. ___ 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 have found that other tools like RAII/drop, the closely related smart > pointer types, and safe containers (vectors, strings etc.) even without > the borrow checker niceties, to be relatively more useful in preventing > memory errors. However, these are features that modern C++ also offers, > along with a seamless integration story with existing C and C++ code. I > find that Rust has an edge in thread-safety, but I am not sure if this > is a strong selling point in the context of Mesa, where the current > design seems to be well served (for now) by the traditional thread > safety patterns. That's fair... aesthetically I've found Rust's presentation of these patterns to be "nicer" than C++'s (although I recognize modern C++ is a different beast than what I once learned). Techincally you're right that both language have evolved quite some overlap. > As an aside, as much as I like the practicality and richness of the > crate ecosystem, which is one of the strong points of Rust, I do have > concerns about its current security model. For example, the crates are > not signed and thus vulnerable to several plausible attacks, like > compromised github accounts or, even worse due to scale, compromised > crate repositories. This is further aggravated by the sometimes large > indirect dependency trees. Such concerns are especially relevant to Mesa > (and other high-profile projects) since it could be an attractive target > for malicious entities. As enticing as it could be sometimes, I would > be very hesitant to introduce external crate dependencies at this point > in Mesa. As mentioned, Rust with nothing more than the standard library is still richer than what C gives us out-of-the-box. I don't expect to need external crates flying around, at least for backend compiler purposes. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rust drivers in Mesa
> 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. For some data points, Eric started working on build system integration (see below email). FFI will depend greatly on the component in question. For a greenfield backend compiler that does NIR -> backed IR in C and exposes the backend IR builders from Rust over a C ABI, there's little in the way of FFI work needed to go. Conventions and style are easy -- go with rustfmt, the language is quite opinionated so we can quit quibbling and get coding :) signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Rust drivers in Mesa
> 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 I agree with this as well. The Rust standard library is richer than C's, if we can get by fine with C + util/, that should be good enough for Rust as well. We might end up growing a Rust-y version of util/ when we have multiple Rust pieces in-tree, but meson should be ok with that. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] mesa 20.1.10
Hi all, I'd like to announce Mesa 20.1.10, the tenth bugfix release for the 20.1 branch. This is the last release, and everyone is advised to update to the 20.2 series. Cheers, Eric --- Alyssa Rosenzweig (1): pan/bi: Handle vector moves Anuj Phogat (1): intel/gen9: Enable MSC RAW Hazard Avoidance Bas Nieuwenhuizen (2): radv: Use atomics to read query results. radv: Fix mipmap extent adjustment on GFX9+. Dylan Baker (1): glsl/xxd.py: fix imports Eric Engestrom (6): docs/relnotes: add sha256 sums to 20.1.9 .pick_status.json: Update to 68daac28df1b2f50a43740d1905932cfde0ddf1a .pick_status.json: Mark d78df70c2a85fd846d40b71b9e213122347bea1b as denominated .pick_status.json: Mark c02e933de4a9a644410384f815c84d1c08107b82 as applied docs: add release notes for 20.1.10 VERSION: bump to release 20.1.10 Jason Ekstrand (5): nir/cf: Better handle intra-block splits intel/fs: NoMask initialize the address register for shuffles nir/opt_load_store_vectorize: Use bit sizes when checking mask compatibility intel/fs: Don't use NoDDClk/NoDDClr for split SHUFFLEs intel/nir: Don't try to emit vector load_scratch instructions Lionel Landwerlin (1): intel/perf: fix crash when no perf queries are supported Lucas Stach (1): etnaviv: stop leaking the dummy texure descriptor BO Marek Olšák (1): radeonsi: Fix dead lock with aux_context_lock in si_screen_clear_buffer. Nanley Chery (2): iris: Fix a fast-clear skipping optimization anv: Enable multi-layer aux-map init for HIZ+CCS Pierre-Eric Pelloux-Prayer (1): omx/tizonia: fix build Rhys Perry (4): spirv: add and use a generator id enum spirv: replace discard with demote for incorrect HLSL->SPIR-V translations android: fix SPIR-V -> NIR build scons: fix SPIR-V -> NIR build Timothy Arceri (1): glsl: don't duplicate state vars as uniforms in the NIR linker Tony Wasserka (1): aco/isel: Always export position data from VS/NGG Vinson Lee (1): freedreno: Move rsc NULL check to before rsc dereferences. git tag: mesa-20.1.10 https://mesa.freedesktop.org/archive/mesa-20.1.10.tar.xz SHA256: b1dba69910adac9fcb4cbdfd7833d99a4a8c75b91f3d2e97f0fd0a3cd8c6ee9f mesa-20.1.10.tar.xz SHA512: 0d4016abfcc733c853d7b6c3c997ddc554a44088c0a4d9a7edb51ab5ad7d9e1234728b61ffcb9c82a6c5fee1429091a1c31cbeabcb1b50411337b99ee550d28a mesa-20.1.10.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-20.1.10.tar.xz.sig ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] mesa 20.2.1
Hi list,
I realize that this is a week late, I simply put everything in the calendar one
week off. Doh. Anyway, mesa 20.2.1 is now available, this release looks much
bigger than it actually is, because of all of the .pick_status commits. there's
a bit of everything in here, all and all a nice little .1
Dylan
Shortlog
Alyssa Rosenzweig (2):
pan/bi: Handle vector moves
pan/bi: Fix simple txl test
Anuj Phogat (1):
intel/gen9: Enable MSC RAW Hazard Avoidance
Bas Nieuwenhuizen (3):
radv,radeonsi: Disable compression on interop depth images
radv: Use atomics to read query results.
radv: Fix mipmap extent adjustment on GFX9+.
Christian Gmeiner (1):
etnaviv: simplify linear stride implementation
Connor Abbott (1):
nir/lower_io_arrays: Fix xfb_offset bug
Danylo Piliaiev (1):
intel/fs: Disable sample mask predication for scratch stores
Dylan Baker (15):
docs: add release notes for 20.2.0
docs: Add sh256 sums for 20.2.0
.pick_status.json: Update to 291cfb1e41513008a5be08be95399373a7de206d
meson/anv: Use variable that checks for --build-id
.pick_status.json: Update to 7dbb1f7462433940951ce6c3fa22f6368aeafd50
.pick_status.json: Update to e3b814d5e9e414839d5e4de3a76bb2899cbb7249
.pick_status.json: Update to b32a8f83dce3b8789f2e8790ab41b8a63c9bedc6
.pick_status.json: Mark b23013db0aa6845d661c2da5d4003615b064e01f as
denominated
.pick_status.json: Mark 4790811d78011d45830d9543ad6e7401391cfb15 as
denominated
glsl/xxd.py: fix imports
.pick_status.json: Update to e1efc534e6c452e3e606d663864896a654acc185
retab ac_surface.h so that backports apply
docs: add release notes for 20.2.1
VERSION: bump for 20.2.1
docs: add SHA256 sums for 20.2.1
Eric Engestrom (1):
radv: add missing u_atomic.h include
Erik Faye-Lund (1):
st/mesa: use roundf instead of floorf for lod-bias rounding
Jason Ekstrand (6):
nir/liveness: Consider if uses in nir_ssa_defs_interfere
nir/cf: Better handle intra-block splits
intel/fs: NoMask initialize the address register for shuffles
nir/opt_load_store_vectorize: Use bit sizes when checking mask
compatibility
intel/fs: Don't use NoDDClk/NoDDClr for split SHUFFLEs
intel/nir: Don't try to emit vector load_scratch instructions
Jose Maria Casanova Crespo (3):
vc4: Avoid negative scissor caused by no intersection
nir/algebraic: optimize iand/ior of (n)eq zero when umax/umin not
available
vc4: Enable lower_umax and lower_umin
Lionel Landwerlin (1):
intel/perf: fix crash when no perf queries are supported
Lucas Stach (1):
etnaviv: stop leaking the dummy texure descriptor BO
Marek Olšák (4):
radeonsi: fix indirect dispatches with variable block sizes
radeonsi: Fix dead lock with aux_context_lock in si_screen_clear_buffer.
gallium/u_threaded_context: fix use-after-free in transfer_unmap
ac/surface: fix valgrind warnings in DCC retile tile lookups
Nanley Chery (3):
blorp: Ensure aligned HIZ_CCS_WT partial clears
iris: Fix a fast-clear skipping optimization
anv: Enable multi-layer aux-map init for HIZ+CCS
Philipp Zabel (1):
meson: fix power8 option
Pierre-Eric Pelloux-Prayer (3):
gallium/vl: do not call transfer_unmap if transfer is NULL
gallium/vl: add chroma_format arg to vl_video_buffer functions
omx/tizonia: fix build
Rhys Perry (4):
spirv: add and use a generator id enum
android: fix SPIR-V -> NIR build
scons: fix SPIR-V -> NIR build
spirv: replace discard with demote for incorrect HLSL->SPIR-V translations
Samuel Pitoiset (1):
aco: implement missing nir_op_unpack_half_2x16_split_{x,y}_flush_to_zero
Timothy Arceri (1):
glsl: don't duplicate state vars as uniforms in the NIR linker
Vinson Lee (2):
gallium/dri2: Move image->texture assignment after image NULL check.
freedreno: Move rsc NULL check to before rsc dereferences.
git tag: mesa-20.2.1
https://mesa.freedesktop.org/archive/mesa-20.2.1.tar.xz
SHA256: d1a46d9a3f291bc0e0374600bdcb59844fa3eafaa50398e472a36fc65fd0244a
mesa-20.2.1.tar.xz
SHA512:
5d609359754db3e3679bffd5306c1f1d1cf46a2ea98428a9451fe0d99bbf73da863c5d94e6561712cd2012ad13615666cf3d712e54f379b34c091fead39d4795
mesa-20.2.1.tar.xz
PGP: https://mesa.freedesktop.org/archive/mesa-20.2.1.tar.xz.sig
signature.asc
Description: signature
___
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, 23:52 Thomas Zimmermann wrote: > 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. > Rust has co-opted i586-unknown-linux-gnu to mean x86-32 without SSE and i686-unknown-linux-gnu to mean x86-32 with SSE2 (technically it implements it by using the pentium4 target cpu, so may require more than just SSE2). Rust just doesn't provide official binaries for i586-unknown-linux-gnu -- that does not imply that rustc and cargo won't work fine if they are recompiled for i586-unknown-linux-gnu. The only major caveat I'd expect is floats having slightly different semantics due to x87, which may cause some of rustc's tests to fail. 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
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
