mbox series

[bug#73071,mesa-updates,0/8] Various updates for mesa to 24.2.2

Message ID cover.1725634153.git.john.kehayias@protonmail.com
Headers show
Series Various updates for mesa to 24.2.2 | expand

Message

John Kehayias Sept. 6, 2024, 3 p.m. UTC 
Hello Guix,

This is a series of patches to update mesa to the latest, 24.2.2, some
dependencies, and fix a vulkan issue <https://issues.guix.gnu.org/71109>.
Along the way I updated llvm-for-mesa and mesa inputs, which unifies the
changes made to build on aarch64-linux, for instance.  Hopefully this doesn't
introduce regressions.  To that end, I've pushed this series now to the
mesa-updates branch to see how building on Cuirass goes.  (A previous version
was there already, but I have updated/rebased and now finally sending this.)

Some notes:

1. The closure size of mesa has increased, something like from 374 MiB to 542
MiB, mostly due to itself (not sure why) and then also from llvm.  This is
from going from v15 to v18 and as you'll see in a patch I had to enable
building all targets.  Possibly this can be alleviated by building a smaller
clang for mesa?

2. Previous discussion was about getting NVK (which requires rust) built in
the last mesa update.  I'm not sure the current status but will check with
those that were working on it before <https://issues.guix.gnu.org/69637>.  I
believe it is no longer experimental, so we should try to include it.

Hopefully the patch changes and brief comments explain all, but please do
provide any feedback, changes, fixes, etc.  The branch has just been rebased
on master but we can rebase as needed or if there are some critical errors on
these patches I missed.

Thanks!
John

PS: I guess python-team will get this series as I added two comments (no code
changes) to python packages now needed for mesa.  One already has a huge
number of dependents anyway, but good to note I suppose.

John Kehayias (6):
  gnu: libdrm: Update to 2.4.123.
  gnu: wayland-protocols: Update to 1.37.
  gnu: Remove wayland-protocols-next.
  gnu: llvm-for-mesa: Update to llvm-18.
  gnu: llvm-for-mesa: Build all targets.
  gnu: mesa: Update to 24.2.2.

nathan (2):
  gnu: vulkan-headers: Hard-code libvulkan.so file name.
  gnu: volk: Hard-code path of vulkan-loader for dynamic loading

 gnu/packages/freedesktop.scm | 17 ++-----------
 gnu/packages/gl.scm          | 49 ++++++++++++++----------------------
 gnu/packages/kde-plasma.scm  |  2 +-
 gnu/packages/llvm.scm        | 29 ++++++++++-----------
 gnu/packages/python-xyz.scm  |  2 ++
 gnu/packages/vulkan.scm      | 41 ++++++++++++++++++++++++++----
 gnu/packages/xdisorg.scm     |  4 +--
 7 files changed, 75 insertions(+), 69 deletions(-)


base-commit: d4fbd1ab341de85c1e5c77e0f7adc5aae056be15
--
2.45.2

Comments

The Man Sept. 18, 2024, 12:35 a.m. UTC | #1 
Hello, In the interest of creating a future where mesa properly works
alongside libglvnd i think there's a few options:

- simply adding "-Dglvnd=true" to mesa configure-flags and tediously adding
libglvnd to the inputs of every package that links to LibGL, as well as
patching anything problematic as mentioned in
https://issues.guix.gnu.org/49339#8

- create an abomination, the ONE MESA TO RULE THEM ALL. an example follows:

(define-public mesa/new
  (package
    (inherit mesa)
    (arguments
      (substitute-keyword-arguments (package-arguments mesa)
        ((#:configure-flags flags ''())
          #~(append #$flags
            (list "-Dglvnd=true")))
        ((#:phases phases ''())
          (with-imported-modules '((guix build union))
          #~(modify-phases #$phases
            (add-before 'validate-runpath 'unionize
              (lambda _ ;; unionize with libglvnd, fixing all problems
                (use-modules (ice-9 match)
                             (guix build union))
                (union-build (string-append #$output "/tmp")
                  '#$(list (this-package-input "libglvnd"))
                  #:create-all-directories? #t)
                (copy-recursively (string-append #$output "/tmp") #$output)
                (delete-file-recursively (string-append #$output "/tmp"))
                ;; leftovers from building with old mesa.
                ;; some packages still link to these.
                ;; remove for rebuilding after applying graft?
                (symlink (string-append #$output "/lib/libEGL.so.1")
                         (string-append #$output "/lib/libEGL.so.1.0.0"))
                (symlink (string-append #$output "/lib/libGLESv1_CM.so.1")
                         (string-append #$output
"/lib/libGLESv1_CM.so.1.1.0"))
                (symlink (string-append #$output "/lib/libGLESv2.so.2")
                         (string-append #$output "/lib/libGLESv2.so.2.0.0"))
                (symlink (string-append #$output "/lib/libGL.so.1")
                         (string-append #$output "/lib/libGL.so.1.2.0"))))
            (add-after 'install 'fix-paths
              (lambda _
                (substitute*
                  (string-append #$output
"/share/glvnd/egl_vendor.d/50_mesa.json")
                  (("libEGL_mesa")
                    (string-append #$output "/lib/libEGL_mesa")))))
            (add-after 'fix-paths 'add-external-egl
              (lambda _
                (mkdir-p (string-append #$output
"/share/egl/egl_external_platform.d")))))))))
    (native-search-paths (append (package-native-search-paths mesa)
     (list
      (search-path-specification
       (variable "__EGL_VENDOR_LIBRARY_DIRS")
       (files '("share/glvnd/egl_vendor.d")))
      (search-path-specification
       (variable "GBM_BACKENDS_PATH")
       (files '("lib")))
      (search-path-specification
       (variable "XDG_DATA_DIRS")
       (files '("share")))
      (search-path-specification
       (variable "__EGL_EXTERNAL_PLATFORM_CONFIG_DIRS")
       (files '("share/egl/egl_external_platform.d"))))))
    (inputs (modify-inputs (package-inputs mesa)
      (prepend libglvnd)))))

Using this to graft over mesa is a filthy answer to the "GL problem". no
rebuilding necessary, it seems to "just work".

Other distributions have settled on packaging mesa build for working with
libglvnd and most software seems to expect such.
Perhaps there's another solution?