| Message ID | 20230306091108.3347363-2-zboszor@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | Mesa 23.0.0 | expand |
Em seg., 6 de mar. de 2023 às 06:11, Zoltan Boszormenyi <zboszor@gmail.com> escreveu: > > Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Just wanted to give everyone a heads up that mesa 23.0 started to strictly enforce that driver versions match the libraries that load them: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20069 https://gitlab.freedesktop.org/mesa/mesa/-/commit/1026d29344192755dd340d6ac13a9674189d2d61 This breaks our implementation of accelerated virtual graphics which 'outsources' the provision of the drivers to the host distribution's mesa. Unfortunately enabling a useful set of drivers in mesa-native is not straightforward, as many of them rely on llvm, or pull in other lengthy dependency chains. I'll see what can be done: we'll probably have to guard the rich set of drivers with a DISTRO_FEATURE. Ideas? Alex On Mon, 6 Mar 2023 at 16:54, Otavio Salvador <otavio.salvador@ossystems.com.br> wrote: > > Em seg., 6 de mar. de 2023 às 06:11, Zoltan Boszormenyi > <zboszor@gmail.com> escreveu: > > > > Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> > > > Acked-by: Otavio Salvador <otavio@ossystems.com.br> > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.br http://code.ossystems.com.br > Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
2023. 03. 07. 11:41 keltezéssel, Alexander Kanavin írta: > Just wanted to give everyone a heads up that mesa 23.0 started to > strictly enforce that driver versions match the libraries that load > them: > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20069 > https://gitlab.freedesktop.org/mesa/mesa/-/commit/1026d29344192755dd340d6ac13a9674189d2d61 > > This breaks our implementation of accelerated virtual graphics which > 'outsources' the provision of the drivers to the host distribution's > mesa. Unfortunately enabling a useful set of drivers in mesa-native is > not straightforward, as many of them rely on llvm, or pull in other > lengthy dependency chains. I'll see what can be done: we'll probably > have to guard the rich set of drivers with a DISTRO_FEATURE. Ideas? The reasoning for the change is that glvnd is a thing. Maybe the drivers you mention should just use that. Recent distros enable glvnd in Mesa out of the box and NVIDIA also supports that. > > Alex > > On Mon, 6 Mar 2023 at 16:54, Otavio Salvador > <otavio.salvador@ossystems.com.br> wrote: >> Em seg., 6 de mar. de 2023 às 06:11, Zoltan Boszormenyi >> <zboszor@gmail.com> escreveu: >>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >> >> Acked-by: Otavio Salvador <otavio@ossystems.com.br> >> >> -- >> Otavio Salvador O.S. Systems >> http://www.ossystems.com.br http://code.ossystems.com.br >> Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
On Tue, 7 Mar 2023 at 12:39, Böszörményi Zoltán <zboszor@gmail.com> wrote: > The reasoning for the change is that glvnd is a thing. > Maybe the drivers you mention should just use that. > Recent distros enable glvnd in Mesa out of the box and > NVIDIA also supports that. qemu unfortunately doesn't work this way. It links directly with libgbm, and libgbm probes directly into the drivers. This are the errors: did not find extension DRI_Mesa version 1 failed to bind extensions did not find extension DRI_Mesa version 1 failed to bind extensions did not find extension DRI_Mesa version 1 failed to bind extensions did not find extension DRI_Mesa version 1 failed to bind extensions qemu-system-x86_64: egl: gbm_create_device failed qemu-system-x86_64: egl: render node init failed And this is where they happen: Thread 1 "qemu-system-x86" hit Breakpoint 1, 0x00007ffff77e6020 in loader_bind_extensions () from /home/alex/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 (gdb) bt #0 0x00007ffff77e6020 in loader_bind_extensions () from /home/alex/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 #1 0x00007ffff77e4fda in dri_screen_create_for_driver () from /home/alex/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 #2 0x00007ffff77e53a8 in dri_device_create () from /home/alex/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 #3 0x00007ffff77e376c in find_backend () from /home/alex/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 #4 0x00007ffff77e3891 in gbm_create_device () from /home/alex/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 #5 0x00005555559a00f8 in egl_rendernode_init (rendernode=<optimized out>, mode=DISPLAYGL_MODE_ON) at ../qemu-7.2.0/ui/egl-helpers.c:177 #6 0x00005555559a04b1 in egl_headless_init (ds=<optimized out>, opts=<optimized out>) at ../qemu-7.2.0/ui/egl-headless.c:203 #7 0x00005555559545f8 in qemu_init_displays () at ../qemu-7.2.0/softmmu/vl.c:2485 #8 qemu_init (argc=<optimized out>, argv=<optimized out>) at ../qemu-7.2.0/softmmu/vl.c:3603 #9 0x00005555557ec369 in main (argc=<optimized out>, argv=<optimized out>) at ../qemu-7.2.0/softmmu/main.c:47 Alex
2023. 03. 07. 16:40 keltezéssel, Alexander Kanavin írta: > On Tue, 7 Mar 2023 at 12:39, Böszörményi Zoltán <zboszor@gmail.com> wrote: >> The reasoning for the change is that glvnd is a thing. >> Maybe the drivers you mention should just use that. >> Recent distros enable glvnd in Mesa out of the box and >> NVIDIA also supports that. > qemu unfortunately doesn't work this way. It links directly with > libgbm, and libgbm probes directly into the drivers. This are the > errors: > > did not find extension DRI_Mesa version 1 > failed to bind extensions > did not find extension DRI_Mesa version 1 > failed to bind extensions > did not find extension DRI_Mesa version 1 > failed to bind extensions > did not find extension DRI_Mesa version 1 > failed to bind extensions > qemu-system-x86_64: egl: gbm_create_device failed > qemu-system-x86_64: egl: render node init failed > > And this is where they happen: > > Thread 1 "qemu-system-x86" hit Breakpoint 1, 0x00007ffff77e6020 in > loader_bind_extensions () from > /home/alex/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 This looks like it's coming from a mesa-native build which should match the target build version. The problem may be that despite of this, it tries to open the host drivers from /usr instead of .../recipe-sysroot-native/usr. > (gdb) bt > #0 0x00007ffff77e6020 in loader_bind_extensions () from > /home/alex/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 > #1 0x00007ffff77e4fda in dri_screen_create_for_driver () from > /home/alex/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 > #2 0x00007ffff77e53a8 in dri_device_create () from > /home/alex/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 > #3 0x00007ffff77e376c in find_backend () from > /home/alex/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 > #4 0x00007ffff77e3891 in gbm_create_device () from > /home/alex/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/../lib/libgbm.so.1 > #5 0x00005555559a00f8 in egl_rendernode_init (rendernode=<optimized > out>, mode=DISPLAYGL_MODE_ON) at ../qemu-7.2.0/ui/egl-helpers.c:177 > #6 0x00005555559a04b1 in egl_headless_init (ds=<optimized out>, > opts=<optimized out>) at ../qemu-7.2.0/ui/egl-headless.c:203 > #7 0x00005555559545f8 in qemu_init_displays () at > ../qemu-7.2.0/softmmu/vl.c:2485 > #8 qemu_init (argc=<optimized out>, argv=<optimized out>) at > ../qemu-7.2.0/softmmu/vl.c:3603 > #9 0x00005555557ec369 in main (argc=<optimized out>, argv=<optimized > out>) at ../qemu-7.2.0/softmmu/main.c:47 > > Alex
On Tue, 7 Mar 2023 at 17:43, Böszörményi Zoltán <zboszor@gmail.com> wrote: > This looks like it's coming from a mesa-native build > which should match the target build version. > The problem may be that despite of this, it tries to open > the host drivers from /usr instead of .../recipe-sysroot-native/usr. Yes, that's exactly what runqemu does, on purpose, by redirecting native mesa to use the host drivers via LIBGL_DRIVERS_PATH environment variable. We could easily make it use its own drivers from recipe-sysroot-native, but that means we have to actually build them, which is very heavy (e.g. llvm is required for llvmpipe, and some amd drivers). Unfortunately mesa 23.0.0 more or less forces that with its version matching. Alex
2023. 03. 07. 17:50 keltezéssel, Alexander Kanavin írta: > On Tue, 7 Mar 2023 at 17:43, Böszörményi Zoltán <zboszor@gmail.com> wrote: > >> This looks like it's coming from a mesa-native build >> which should match the target build version. >> The problem may be that despite of this, it tries to open >> the host drivers from /usr instead of .../recipe-sysroot-native/usr. > Yes, that's exactly what runqemu does, on purpose, by redirecting > native mesa to use the host drivers via LIBGL_DRIVERS_PATH environment > variable. We could easily make it use its own drivers from > recipe-sysroot-native, but that means we have to actually build them, > which is very heavy (e.g. llvm is required for llvmpipe, and some amd > drivers). Unfortunately mesa 23.0.0 more or less forces that with its > version matching. I think that was already brewing with 22.3.x, since that version cut off the "classic" drivers, keeping only the gallium ones. Like the kernel, Mesa's drivers were implicitly expected to work with everything built from the same main version because they were using internal structures that may be reworked from one major version to another. That's why glvnd exists. NVIDIA's libGL.so.1 only loaded its own hardware driver (kernel or userspace), and Mesa too. The situation that started with 22.3.x explicitly stated that glvnd has to be used if someone wanted to use the classic drivers from Mesa 22.2.x a.k.a. the "amber" branch. Though it's true that the version enforcing was only added to 23.0.0, but it only added emphasis to the already existing state of affairs.
On Wed, 8 Mar 2023 at 06:28, Böszörményi Zoltán <zboszor@gmail.com> wrote: > I think that was already brewing with 22.3.x, since that version > cut off the "classic" drivers, keeping only the gallium ones. > Like the kernel, Mesa's drivers were implicitly expected to work > with everything built from the same main version because > they were using internal structures that may be reworked > from one major version to another. I just posted a RFC patchset that switches runqemu to use mesa-native fully. Some form of that patchset has to go in before mesa can be updated to 23.3 - we're in the middle of feature freeze now, so it'll likely have to wait. Alex
diff --git a/meta/recipes-graphics/mesa/files/0001-gbm-backend-fix-gbm-compile-without-dri.patch b/meta/recipes-graphics/mesa/files/0001-gbm-backend-fix-gbm-compile-without-dri.patch deleted file mode 100644 index 6541671b7a..0000000000 --- a/meta/recipes-graphics/mesa/files/0001-gbm-backend-fix-gbm-compile-without-dri.patch +++ /dev/null @@ -1,65 +0,0 @@ -From 25946100e21cf2095bea334e8d7096798561d0b7 Mon Sep 17 00:00:00 2001 -From: Vincent Davis Jr <vince@underview.tech> -Date: Wed, 28 Dec 2022 16:28:01 -0600 -Subject: [PATCH] gbm/backend: fix gbm compile without dri - -Upstream-Status: Backport - -https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20447 -https://gitlab.freedesktop.org/mesa/mesa/-/commit/842ca284650f066e58706741a7d22d67b5088e60 - -At mesa version 22.2.3 patch wasn't introduced until after. - -Commit introduces a fix that allows for gbm to be built with an empty -backend. There are situation especially in a Yocto/OE cross compilation -environment where you want to build with an empty backend. The particular -situation is as such: - -The mesa-gl recipe is the preferred provider for virtual/libgbm, virtual/libgl, -virtual/mesa, etc... But the x11 DISTRO_FEATURE in't included this leads to build -errors such as: - -| /../../../ld: src/gbm/libgbm.so.1.0.0.p/main_backend.c.o: in function `find_backend': -| backend.c:(.text.find_backend+0xa4): undefined reference to `gbm_dri_backend' -| /../../../ld: src/gbm/libgbm.so.1.0.0.p/main_backend.c.o:(.data.rel.ro.builtin_backends+0x4): - undefined reference to `gbm_dri_backend' -| collect2: error: ld returned 1 exit status - -Issue should be replicable by setting -Ddri3=disabled and -Dgbm=enabled - -Add fix to bypasses compilation issue by excluding gbm dri backend. If -HAVE_DRI || HAVE_DRIX not specified. - -Acked-by: David Heidelberg <david.heidelberg@collabora.com> -Signed-off-by: Vincent Davis Jr <vince@underview.tech> ---- - src/gbm/main/backend.c | 4 ++++ - 1 file changed, 4 insertions(+) - -diff --git a/src/gbm/main/backend.c b/src/gbm/main/backend.c -index 974d0a76a4e..feee0703495 100644 ---- a/src/gbm/main/backend.c -+++ b/src/gbm/main/backend.c -@@ -42,7 +42,9 @@ - #define ARRAY_SIZE(a) (sizeof(a)/sizeof((a)[0])) - #define VER_MIN(a, b) ((a) < (b) ? (a) : (b)) - -+#if defined(HAVE_DRI) || defined(HAVE_DRI2) || defined(HAVE_DRI3) - extern const struct gbm_backend gbm_dri_backend; -+#endif - - struct gbm_backend_desc { - const char *name; -@@ -51,7 +53,9 @@ struct gbm_backend_desc { - }; - - static const struct gbm_backend_desc builtin_backends[] = { -+#if defined(HAVE_DRI) || defined(HAVE_DRI2) || defined(HAVE_DRI3) - { "dri", &gbm_dri_backend }, -+#endif - }; - - #define BACKEND_LIB_SUFFIX "_gbm" --- -2.34.1 - diff --git a/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch b/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch index d22ff3c8a8..0bbd518047 100644 --- a/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch +++ b/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch @@ -23,12 +23,12 @@ diff --git a/src/util/format/u_format.c b/src/util/format/u_format.c index c071250..0880984 100644 --- a/src/util/format/u_format.c +++ b/src/util/format/u_format.c -@@ -1184,7 +1184,7 @@ static void +@@ -1187,7 +1187,7 @@ util_format_unpack_table_init(void) { for (enum pipe_format format = PIPE_FORMAT_NONE; format < PIPE_FORMAT_COUNT; format++) { --#if (defined(PIPE_ARCH_AARCH64) || defined(PIPE_ARCH_ARM)) && !defined(NO_FORMAT_ASM) && !defined(__SOFTFP__) -+#if (defined(PIPE_ARCH_AARCH64) || (defined(__ARM_NEON) && defined(PIPE_ARCH_ARM))) && !defined(NO_FORMAT_ASM) +-#if (DETECT_ARCH_AARCH64 || DETECT_ARCH_ARM) && !defined(NO_FORMAT_ASM) && !defined(__SOFTFP__) ++#if (DETECT_ARCH_AARCH64 || (DETECT_ARCH_ARM && defined(__ARM_NEON))) && !defined(NO_FORMAT_ASM) && !defined(__SOFTFP__) const struct util_format_unpack_description *unpack = util_format_unpack_description_neon(format); if (unpack) { util_format_unpack_table[format] = unpack; @@ -36,12 +36,12 @@ diff --git a/src/util/format/u_format_unpack_neon.c b/src/util/format/u_format_u index a4a5cb1..1e4f794 100644 --- a/src/util/format/u_format_unpack_neon.c +++ b/src/util/format/u_format_unpack_neon.c -@@ -23,7 +23,7 @@ +@@ -24,7 +24,7 @@ + #include "util/detect_arch.h" + #include "util/format/u_format.h" - #include <u_format.h> - --#if (defined(PIPE_ARCH_AARCH64) || defined(PIPE_ARCH_ARM)) && !defined(NO_FORMAT_ASM) && !defined(__SOFTFP__) -+#if (defined(PIPE_ARCH_AARCH64) || (defined(__ARM_NEON) && defined(PIPE_ARCH_ARM))) && !defined(NO_FORMAT_ASM) +-#if (DETECT_ARCH_AARCH64 || DETECT_ARCH_ARM) && !defined(NO_FORMAT_ASM) && !defined(__SOFTFP__) ++#if (DETECT_ARCH_AARCH64 || (DETECT_ARCH_ARM && defined(__ARM_NEON))) && !defined(NO_FORMAT_ASM) && !defined(__SOFTFP__) /* armhf builds default to vfp, not neon, and refuses to compile neon intrinsics * unless you tell it "no really". diff --git a/meta/recipes-graphics/mesa/mesa-gl_22.3.5.bb b/meta/recipes-graphics/mesa/mesa-gl_23.0.0.bb similarity index 100% rename from meta/recipes-graphics/mesa/mesa-gl_22.3.5.bb rename to meta/recipes-graphics/mesa/mesa-gl_23.0.0.bb diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc index 8a8a057c6b..bbe8ca7875 100644 --- a/meta/recipes-graphics/mesa/mesa.inc +++ b/meta/recipes-graphics/mesa/mesa.inc @@ -18,10 +18,9 @@ SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \ file://0001-meson.build-check-for-all-linux-host_os-combinations.patch \ file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \ file://0001-util-format-Check-for-NEON-before-using-it.patch \ - file://0001-gbm-backend-fix-gbm-compile-without-dri.patch \ " -SRC_URI[sha256sum] = "3eed2ecae2bc674494566faab9fcc9beb21cd804c7ba2b59a1694f3d7236e6a9" +SRC_URI[sha256sum] = "01f3cff3763f09e0adabcb8011e4aebc6ad48f6a4dd4bae904fe918707d253e4" UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P<pver>\d+(\.\d+)+)" diff --git a/meta/recipes-graphics/mesa/mesa_22.3.5.bb b/meta/recipes-graphics/mesa/mesa_23.0.0.bb similarity index 100% rename from meta/recipes-graphics/mesa/mesa_22.3.5.bb rename to meta/recipes-graphics/mesa/mesa_23.0.0.bb
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> --- ...-backend-fix-gbm-compile-without-dri.patch | 65 ------------------- ...ormat-Check-for-NEON-before-using-it.patch | 16 ++--- .../{mesa-gl_22.3.5.bb => mesa-gl_23.0.0.bb} | 0 meta/recipes-graphics/mesa/mesa.inc | 3 +- .../mesa/{mesa_22.3.5.bb => mesa_23.0.0.bb} | 0 5 files changed, 9 insertions(+), 75 deletions(-) delete mode 100644 meta/recipes-graphics/mesa/files/0001-gbm-backend-fix-gbm-compile-without-dri.patch rename meta/recipes-graphics/mesa/{mesa-gl_22.3.5.bb => mesa-gl_23.0.0.bb} (100%) rename meta/recipes-graphics/mesa/{mesa_22.3.5.bb => mesa_23.0.0.bb} (100%)