[PATCH mesa-updates 0/6] gnu: mesa: Update to 24.0.2.

> Hello!

>

> This series of patches updates Mesa to the latest stable version with the NVK

> Vulkan driver for NVIDIA GPUs enabled for x86_64 systems.

>

> Mesa 24.0.2 depends on a newer version of libdrm (>= 2.4.119), which is

> pending in another issue (https://issues.guix.gnu.org/68845).

>

> Some packages (rust-syn-2.0.39, rust-proc-macro2-1.0.70, rust-quote-1.0.33)

> were added specifically to be used as sources that satisfy explicit versions

> of dependencies required by Mesa (for NVK). Would it be better to inline

> origins in the change-subproject-sources phase? The same question also

> applies for the rust-unicode-ident-1 source.

> Currently, the Rust dependencies are found in the build by substituting the

> fallback https://* URLs in the relevant ./subprojects/*.wrap files with

> file://*, then relying on the fallback to "download" from the store. It

> seemed a bit hacky doing it this way, but I'm not aware of a better solution.

> A newer Meson version is also required for NVK (>= 1.3.0), which this patch

> series adds a new variable for.

>

> x86_64-linux and i686-linux have been tested to successfully build.

>

> Cheers,

>

> aurtzy

>

> aurtzy (6):

> gnu: Add meson-1.3.

> gnu: Add rust-syn-2.0.39.

> gnu: Add rust-proc-macro2-1.0.70.

> gnu: Add rust-quote-1.0.33.

> gnu: Add rust-bindgen-cli-0.69.

> gnu: mesa: Update to 24.0.2.

>

> gnu/packages/build-tools.scm | 14 ++++++

> gnu/packages/crates-io.scm | 95 ++++++++++++++++++++++++++++++++++++

> gnu/packages/gl.scm | 68 +++++++++++++++++++-------

> 3 files changed, 160 insertions(+), 17 deletions(-)

>

>

> base-commit: 0b5cbca689b2f91949e191ca256ffc9bb48c1141

> --

> 2.41.0

>

>

>

>

> Are there other architectures which have rust based drivers? x86_64

> isn't the only architecture which has rust building on it.

> The crates are also available in

> %output/share/cargo/registry/name-version.crate, although I can't think

> of a good way to address them by name without using find-files.

>

> I would personally replace the versions requested by mesa with whatever

> version we happen to have in guix so that we don't have to add special

> versions just for mesa.

> On 3/12/24 04:11, Efraim Flashner wrote:

>

> Are there other architectures which have rust based drivers? x86_64

> isn't the only architecture which has rust building on it.

>

> There doesn't appear to be any official documentation stating architecture requirements for Mesa with

> NVK/Rust, however I have added few new inputs other than rust to get NVK working. I've only done extensive

> testing with x86_64 so I was unsure of potential issues with including this on other architectures (other than

> i686 not building rust).

>

> The crates are also available in

> %output/share/cargo/registry/name-version.crate, although I can't think

> of a good way to address them by name without using find-files.

>

> I would personally replace the versions requested by mesa with whatever

> version we happen to have in guix so that we don't have to add special

> versions just for mesa.

>

> I have/had tried a few approaches to use the crates already available in Guix with no success so far. I've

> outlined the approaches below; still looking into solutions, but perhaps there's something I'm missing or

> haven't tried yet?

>

> - Simply including crates as (native-)inputs does not make them discoverable by meson.

>

> - Mesa uses these *.wrap files which specify the rust dependency versions, source URLs, and tar hashes. I

> currently get the build working by relying on meson to fall back to "downloading" from a patched source URL

> (pointing to store), although it still has to match the hash.

>

> - I recently discovered a way to disable the hash requirement so I could use a different input version (i.e. one

> from Guix), but doing it causes "File src/lib.rs does not exist" errors. I'm still looking into this right now, as it

> seems promising.

>

> - Old IRC logs point to projects like newsboat and librsvg which also mix cargo with with another build

> system, but these start with cargo-build-system with phases added/replaced from the second build system.

> Cargo.toml doesn't exist in Mesa either (which cargo-build-system seems to depend on), so experimenting

> with using cargo-build-system didn't yield much.

>

> I wanted to look more into the third bullet before responding, but I felt it would be unfortunate to have this

> information rot while trying to make time for hacking - hopefully it's still useful.

>

> Cheers,

>

> aurtzy

> I would like to get the build farm cranking on the updates I have

> queued for mesa-updates (cairo, libdrm, mesa, vulkan). We could also

> do just the version update of mesa to start, or just NVK on x86_64,

> leaving future changes for the next round. I don't have a preference

> myself, other than wanting to get this branch moving with these

> updates.

> I also tried a couple of different options. The one that I most want

> involved using with-output-to-file to rewrite the wrap file and

> replacing all the fields. I borrowed the file-sha256 function from

> guix/build/cargo-utils.scm to get the source_hash. In the end I wasn't

> able to get the gexp and un-gexp bits working to actually get the file

> written.

>

> When I kept a failed build I saw that the 'directory' field is the

> directory into which meson writes the meson.build file, which is why

> using a different version of the rust crate caused problems with

> src/lib.rs not existing. I suppose we could start from your patch and

> then, after running substitute, extract the tarball into either a

> hardcoded path (determined after manually reading the sources) or we can

> extract the 'directory' field by reading the sources and then untar the

> source there.

> New patchset coming in. Mesa has been updated to 24.0.3, and I've added TODO

> comments for future work as suggested.

>

>> I would like to get the build farm cranking on the updates I have

>> queued for mesa-updates (cairo, libdrm, mesa, vulkan). We could also

>> do just the version update of mesa to start, or just NVK on x86_64,

>> leaving future changes for the next round. I don't have a preference

>> myself, other than wanting to get this branch moving with these

>> updates.

>

> NVK on 24.0.3 is also still considered experimental, so if that's a concern we

> could save this work for 24.1 when it's planned to move out of this stage.

>

>> I also tried a couple of different options. The one that I most want

>> involved using with-output-to-file to rewrite the wrap file and

>> replacing all the fields. I borrowed the file-sha256 function from

>> guix/build/cargo-utils.scm to get the source_hash. In the end I wasn't

>> able to get the gexp and un-gexp bits working to actually get the file

>> written.

>>

>> When I kept a failed build I saw that the 'directory' field is the

>> directory into which meson writes the meson.build file, which is why

>> using a different version of the rust crate caused problems with

>> src/lib.rs not existing. I suppose we could start from your patch and

>> then, after running substitute, extract the tarball into either a

>> hardcoded path (determined after manually reading the sources) or we can

>> extract the 'directory' field by reading the sources and then untar the

>> source there.

>

> Noted, thanks Efraim! I'll keep looking into this.

>

> Hi aurtzy and Efraim,

>

> On Fri, Mar 22, 2024 at 03:24 AM, aurtzy wrote:

>

>> New patchset coming in. Mesa has been updated to 24.0.3, and I've added TODO

>> comments for future work as suggested.

>>

> Thanks!

>>> I would like to get the build farm cranking on the updates I have

>>> queued for mesa-updates (cairo, libdrm, mesa, vulkan). We could also

>>> do just the version update of mesa to start, or just NVK on x86_64,

>>> leaving future changes for the next round. I don't have a preference

>>> myself, other than wanting to get this branch moving with these

>>> updates.

>> NVK on 24.0.3 is also still considered experimental, so if that's a concern we

>> could save this work for 24.1 when it's planned to move out of this stage.

>>

> Right, I forgot about that. I also remember that it depends (or is

> helped by) some changes in recent kernels, 6.7 and/or 6.8 if I remember.

> So, maybe we can take this approach:

>

> 1. Make the update just to 24.0.3 for mesa (does that require newer

> meson?)

> 2. Add any rust packages as needed to master

>

> 3. Either add a mesa-next (to master?) or followup on mesa-updates after

> it gets merged to master with a mesa based on 24.1 (as soon as it is

> tagged) with NVK enabled. This will let us at least get mesa built and

> make for a headstart come 24.0.1.

>

> With 24.1 soon ("this quarter"?) and how long it can take us to build on

> non-x86 architectures, it would be nice to have that go quickly. Since

> I'll be including cairo, libdrm, and vulkan updates (at least) this

> round, I anticipate it taking a bit.

>

> Does that sound okay? It'll give some time to test things and clean

> up/find alternatives as Efraim suggested.

>

> I'm also not opposed to just enabling NVK now. In that case, we should

> have one commit to just update mesa and another to enable NVK.

>>> I also tried a couple of different options. The one that I most want

>>> involved using with-output-to-file to rewrite the wrap file and

>>> replacing all the fields. I borrowed the file-sha256 function from

>>> guix/build/cargo-utils.scm to get the source_hash. In the end I wasn't

>>> able to get the gexp and un-gexp bits working to actually get the file

>>> written.

>>>

>>> When I kept a failed build I saw that the 'directory' field is the

>>> directory into which meson writes the meson.build file, which is why

>>> using a different version of the rust crate caused problems with

>>> src/lib.rs not existing. I suppose we could start from your patch and

>>> then, after running substitute, extract the tarball into either a

>>> hardcoded path (determined after manually reading the sources) or we can

>>> extract the 'directory' field by reading the sources and then untar the

>>> source there.

>> Noted, thanks Efraim! I'll keep looking into this.

>>

> Thanks both of you! I would like to start pushing patches and building

> everything in the next few days, especially as some have sat for a while

> and it will take time to build.

>

> John

> Looks like 24.1 stable should be releasing May-June: https://docs.mesa3d.org/release-calendar.html

>

> This approach sounds fine to me. I don't mind holding back the NVK-related changes for more testing and

> improvement.

>

> Hello,

>

> On Tue, Mar 26, 2024 at 10:14 PM, aurtzy wrote:

>

>> Looks like 24.1 stable should be releasing May-June:

>> <https://docs.mesa3d.org/release-calendar.html>

>>

>

> All the more reason to pre-empt it a bit, as I will be away for most

> of May and the beginning of June :-)

>

>> This approach sounds fine to me. I don't mind holding back the

>> NVK-related changes for more testing and

>> improvement.

>>

>

> Great, thanks!

>

> I applied a version only bump locally (haven't pushed it out live yet)

> and so far so good. I put you as co-author, even though it was just

> the hash basically, you did save me having to do that.

>

> Once this is on mesa-updates, you can base your patches on that (bunch

> of other updates too) and it can live on that branch in prep for 24.1.

>

> Thanks again!

> John