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

[John Kehayias]

Hi aurtzy and Efraim,

On Wed, Mar 20, 2024 at 09:52 PM, aurtzy wrote:

> 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).
>

I guess this is the main question, if we will try to enable the NVK
driver for other architectures, if that is supported. We could also
leave it for the known working x86_64 to start. I would say we could
provide a mesa variant package for testing, but that might be
difficult as far as I know (e.g. trying to get Xorg to use a different
mesa package looked difficult from what I saw others try).

We could try just checking for where rust is available (is that just
supported-systems for the rust package, or do we have other logic?)
and building with NVK to see what fails... Though with how long it can
take us to build on other architectures, that might take a while to
find out and then correct.

>  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

Thanks for this additional info, aurtzy, and your work on this!

Efraim, any thoughts on the rust related stuff based on these other
attempts? I'm not familiar enough with rust, rust packaging, or what
mesa is doing in the meson builds to comment right now.

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.

Thoughts?

And thanks both of you again!
John