mbox series

[bug#69637,mesa-updates,v2,0/5] gnu: mesa: Update to 24.0.3.

Message ID cover.1711091869.git.aurtzy@gmail.com
Headers show
Series gnu: mesa: Update to 24.0.3. | expand

Message

aurtzy March 22, 2024, 7:24 a.m. UTC
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.

Best,

aurtzy

aurtzy (5):
  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: mesa: Update to 24.0.3.

 gnu/packages/build-tools.scm | 14 +++++++
 gnu/packages/crates-io.scm   | 42 +++++++++++++++++++
 gnu/packages/gl.scm          | 80 ++++++++++++++++++++++++++++--------
 3 files changed, 118 insertions(+), 18 deletions(-)


base-commit: 3d2966e0b7dbf15a5cb497037ace73d1be92febf

Comments

John Kehayias March 25, 2024, 1:29 a.m. UTC | #1
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
aurtzy March 27, 2024, 2:14 a.m. UTC | #2
On 3/24/24 21:29, John Kehayias wrote:
> 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!
Happy to help!
>>> 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.

6.6 appears to be the minimum required according to mesa docs, if that 
changes anything: 
https://docs.mesa3d.org/drivers/nvk.html#kernel-requirements

> So, maybe we can take this approach:
>
> 1. Make the update just to 24.0.3 for mesa (does that require newer
> meson?)
The meson 1.3 requirement is only for NVK; mesa 24.0.3 without NVK can 
build with the current 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.

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.

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

Cheers,

aurtzy
John Kehayias March 27, 2024, 5:22 a.m. UTC | #3
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
John Kehayias April 18, 2024, 4:39 a.m. UTC | #4
On Wed, Mar 27, 2024 at 01:17 AM, John Kehayias wrote:

> 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

mesa updated to 24.0.3 in b43d36a556c1c1d75fdffbec08d8c39121a528cd and
then 24.0.4 in 23928e2d426fb63945682c2c8c60145fe4d333dd.

Closing this issue number, but thank you for the efforts so far for NVK.
Happy to have patches for 24.1 on mesa-updates when you have them.

John