GNU bug report logs - #64528
[PATCH] gnu: mesa: Fix Vulkan on older Intel GPUs.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64528 in the body.
You can then email your comments to 64528 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lilah Tascheter <lilah <at> lunabee.space>
To: guix-patches <at> gnu.org
Cc: Lilah Tascheter <lilah <at> lunabee.space>, liliana.prikler <at> gmail.com,
 iyzsong <at> envs.net
Subject: [PATCH] gnu: mesa: Fix Vulkan on older Intel GPUs.
Date: Sat,  8 Jul 2023 00:16:34 -0500

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

Message #8 received at 64528 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Lilah Tascheter <lilah <at> lunabee.space>, 64528 <at> debbugs.gnu.org
Cc: iyzsong <at> envs.net
Subject: Re: [PATCH] gnu: mesa: Fix Vulkan on older Intel GPUs.
Date: Sat, 08 Jul 2023 17:46:36 +0200

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

Message #11 received at 64528 <at> debbugs.gnu.org (full text, mbox):

From: Lilah Tascheter <lilah <at> lunabee.space>
To: 64528 <at> debbugs.gnu.org
Cc: Lilah Tascheter <lilah <at> lunabee.space>, liliana.prikler <at> gmail.com,
 iyzsong <at> envs.net
Subject: [PATCH v2] gnu: mesa: Fix Vulkan on older Intel GPUs.
Date: Sat,  8 Jul 2023 13:29:28 -0500

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.
---
 gnu/packages/gl.scm | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index 9885bde712..1691086e1a 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -279,6 +279,7 @@ (define-public mesa
          (base32
           "1mcjf41x2bhxs6yxars7nh2vfryfw50g6rvbcfbb1wqdv2jn4qrq"))))
     (build-system meson-build-system)
+    (replacement mesa-vulkan-hasvk)
     (propagated-inputs
      ;; The following are in the Requires.private field of gl.pc.
      (list libdrm
@@ -526,6 +527,21 @@ (define-public mesa
 from software emulation to complete hardware acceleration for modern GPUs.")
     (license license:x11)))
 
+(define mesa-vulkan-hasvk
+  (let ((graft mesa)
+        (vulk "-Dvulkan-drivers=intel,amd"))
+    (package
+      (inherit graft)
+      (arguments
+        (substitute-keyword-arguments (package-arguments graft)
+          ((#:configure-flags flags)
+           #~(begin
+               (use-modules (ice-9 match))
+               (map (match-lambda
+                      (#$vulk (string-append #$vulk ",intel_hasvk,swrast"))
+                      (x x))
+                 #$flags))))))))
+
 (define-public mesa-opencl
   (package/inherit mesa
     (name "mesa-opencl")

base-commit: 3db685cb2e2ce2a4b29c62d28a66201b2eba018f
-- 
2.40.1

Message #16 received at 64528-done <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Lilah Tascheter <lilah <at> lunabee.space>, 64528-done <at> debbugs.gnu.org
Cc: iyzsong <at> envs.net
Subject: Re: [PATCH v2] gnu: mesa: Fix Vulkan on older Intel GPUs.
Date: Sun, 16 Jul 2023 09:26:45 +0200

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.

Message #19 received at 64528 <at> debbugs.gnu.org (full text, mbox):

From: John Kehayias <john.kehayias <at> protonmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Lilah Tascheter <lilah <at> lunabee.space>, 64528 <at> debbugs.gnu.org,
 iyzsong <at> envs.net
Subject: Re: [PATCH v2] gnu: mesa: Fix Vulkan on older Intel GPUs.
Date: Sun, 16 Jul 2023 18:06:56 +0000

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

Message #22 received at 64528 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: John Kehayias <john.kehayias <at> protonmail.com>
Cc: Lilah Tascheter <lilah <at> lunabee.space>, 64528 <at> debbugs.gnu.org,
 iyzsong <at> envs.net
Subject: Re: [PATCH v2] gnu: mesa: Fix Vulkan on older Intel GPUs.
Date: Sun, 16 Jul 2023 20:28:33 +0200

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

Message #25 received at 64528 <at> debbugs.gnu.org (full text, mbox):

From: John Kehayias <john.kehayias <at> protonmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Lilah Tascheter <lilah <at> lunabee.space>, 64528 <at> debbugs.gnu.org,
 iyzsong <at> envs.net
Subject: Re: [PATCH v2] gnu: mesa: Fix Vulkan on older Intel GPUs.
Date: Tue, 25 Jul 2023 21:25:57 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.