[bug#64528] gnu: mesa: Fix Vulkan on older Intel GPUs.

Mesa split the Vulkan intel driver into two: intel and intel_hasvk.
Enables intel_hasvk so vulkan functions on older intel GPUs again, and
swrast for lavapipe as a fallback.
---
 gnu/packages/gl.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


base-commit: 3db685cb2e2ce2a4b29c62d28a66201b2eba018f

Am Samstag, dem 08.07.2023 um 00:16 -0500 schrieb Lilah Tascheter:
> Mesa split the Vulkan intel driver into two: intel and intel_hasvk.
> Enables intel_hasvk so vulkan functions on older intel GPUs again,
> and swrast for lavapipe as a fallback.
> ---
>  gnu/packages/gl.scm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
> index 9885bde712..b84b856c25 100644
> --- a/gnu/packages/gl.scm
> +++ b/gnu/packages/gl.scm
> @@ -345,7 +345,7 @@ (define-public mesa
>           ;; Explicitly enable Vulkan on some architectures.
>           #$@(match (%current-system)
>               ((or "i686-linux" "x86_64-linux")
> -              '("-Dvulkan-drivers=intel,amd"))
> +              '("-Dvulkan-drivers=intel,intel_hasvk,amd,swrast"))
>               ((or "powerpc64le-linux" "powerpc-linux")
>                '("-Dvulkan-drivers=amd,swrast"))
>               ("aarch64-linux"
> 
> base-commit: 3db685cb2e2ce2a4b29c62d28a66201b2eba018f
Is this aimed at master?  If so, it needs a graft.

Cheers

Hello,

Liliana Prikler wrote:
>Am Samstag, dem 08.07.2023 um 13:29 -0500 schrieb Lilah Tascheter:
>> Mesa split the Vulkan intel driver into two: intel and intel_hasvk.
>> Enables intel_hasvk so vulkan functions on older intel GPUs again,
>> and swrast for lavapipe as a fallback.
>>
>> * gnu/packages/gl.scm (mesa-vulkan-hasvk): New variable.
>>   (mesa): Graft with mesa-vulkan-hasvk.
>> ---
>Pushed.

Ah, sorry I didn't see and respond earlier as we have a mesa-updates
branch that I'm just waiting for the go ahead to merge to master. It
updates mesa and is already built on Cuirass.

How can we ensure that upon merging we don't cause the full rebuild?
Should I revert this, apply the updates, and then do this graft? Or will
applying the update on top of this graft commit be okay too?

My original thought was that this shouldn't be grafted but can just be
applied directly to mesa-updates with the next round of patches there,
as this one is already built. This could be done pretty quickly, though
I expect a new mesa version soon that I would group this with, along
with some other mass rebuild changes waiting. I think on the order of a
couple or few weeks.

What do we all think? (Sorry there is no mesa team as of yet, not sure
how to set that up without it applying to a too large scope of packages
by default.)

Thanks,
John

Hi John,

Am Sonntag, dem 16.07.2023 um 18:06 +0000 schrieb John Kehayias:
> Ah, sorry I didn't see and respond earlier as we have a mesa-updates
> branch that I'm just waiting for the go ahead to merge to master. It
> updates mesa and is already built on Cuirass.
> 
> How can we ensure that upon merging we don't cause the full rebuild?
> Should I revert this, apply the updates, and then do this graft? Or
> will applying the update on top of this graft commit be okay too?
Since this graft is phrased as more or less a package transformation, I
would expect it to still apply (more or less) on top of any update you
do on mesa-updates.  If you already fixed the package on mesa-updates,
then you can simply drop the replacement during your regular merge of
master into mesa-updates.  Similarly, if you want to do away with the
graft, but haven't done so yet, you can inline the changes after the
merge.  In either case, it should be done before mesa-updates gets
pushed to master.

> My original thought was that this shouldn't be grafted but can just
> be applied directly to mesa-updates with the next round of patches
> there, as this one is already built. This could be done pretty
> quickly, though I expect a new mesa version soon that I would group
> this with, along with some other mass rebuild changes waiting. I
> think on the order of a couple or few weeks.
> 
> What do we all think? (Sorry there is no mesa team as of yet, not
> sure how to set that up without it applying to a too large scope of
> packages by default.)
I think grafting this for now, but undoing the graft on mesa-updates is
the way to go.  In my humble opinion we should fix bugs on master as
they arise while doing long-term solutions in teams where we have more
resources for big builds.

Cheers

Hi Liliana,

On Sun, Jul 16, 2023 at 08:28 PM, Liliana Marie Prikler wrote:

> Hi John,
>
> Am Sonntag, dem 16.07.2023 um 18:06 +0000 schrieb John Kehayias:
>> Ah, sorry I didn't see and respond earlier as we have a mesa-updates
>> branch that I'm just waiting for the go ahead to merge to master. It
>> updates mesa and is already built on Cuirass.
>>
>> How can we ensure that upon merging we don't cause the full rebuild?
>> Should I revert this, apply the updates, and then do this graft? Or
>> will applying the update on top of this graft commit be okay too?
> Since this graft is phrased as more or less a package transformation, I
> would expect it to still apply (more or less) on top of any update you
> do on mesa-updates.  If you already fixed the package on mesa-updates,
> then you can simply drop the replacement during your regular merge of
> master into mesa-updates.  Similarly, if you want to do away with the
> graft, but haven't done so yet, you can inline the changes after the
> merge.  In either case, it should be done before mesa-updates gets
> pushed to master.
>

I added a new commit on mesa-updates (after rebasing on master) to
ungraft, incorporating this change in mesa directly now.

>> My original thought was that this shouldn't be grafted but can just
>> be applied directly to mesa-updates with the next round of patches
>> there, as this one is already built. This could be done pretty
>> quickly, though I expect a new mesa version soon that I would group
>> this with, along with some other mass rebuild changes waiting. I
>> think on the order of a couple or few weeks.
>>
>> What do we all think? (Sorry there is no mesa team as of yet, not
>> sure how to set that up without it applying to a too large scope of
>> packages by default.)
> I think grafting this for now, but undoing the graft on mesa-updates is
> the way to go.  In my humble opinion we should fix bugs on master as
> they arise while doing long-term solutions in teams where we have more
> resources for big builds.
>

Sure, sounds good. I ended up updating mesa again along with a few
other patches and somewhat related updates; letting things rebuild now
and hope to merge to master once that looks good.

Thanks!
John