[PATCH v3 0/3] Mesa 23.0.0

[PATCH v3 0/3] Mesa 23.0.0

[Zoltán Böszörményi]

Changelog for v3:

* bindgen-cli MR has the suggested changes
  See https://github.com/kraj/meta-clang/pull/748
* The rusticl patch relies on the bindgen wrapper doing
  the right thing regarding loading libclang.
* Moved the __anonymous() function changes to the 3rd patch
  with a comment in both the function and the commit message.

Changelog for v2:

* bindgen-cli recipe was moved to meta-clang.
  See https://github.com/kraj/meta-clang/pull/748
* The __anonymous() function that tweaks packaging variables
  were confused by two libopencl-mesa packages, creating havoc
  in naming subsequent packages. Use a synthetic "opencl"
  value that's added to the pkgconfig variable in this function 
  if either "clover" or "rusticl" exists in PACKAGECONFIG. 
* Made "inherit rust" conditional on PACKAGECONFIG="rusticl".
  (This fails under Kirkstone somehow for me.)

[PATCH v3 1/3] mesa, mesa-gl: 23.0.0

[Zoltán Böszörményi]

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

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

[PATCH v3 2/3] mesa: Rename PACKAGECONFIG "opencl" to "clover"

[Zoltán Böszörményi]

There is another OpenCL frontend called "rusticl" now.

Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
---
 meta/recipes-graphics/mesa/mesa.inc | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index bbe8ca7875..ff352822a3 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -132,9 +132,9 @@ PACKAGECONFIG[gles] = "-Dgles1=enabled -Dgles2=enabled, -Dgles1=disabled -Dgles2
 # "egl" requires "opengl"
 PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
 
-# "opencl" requires libclc from meta-clang and spirv-tools from OE-Core
+# "clover" requires libclc from meta-clang and spirv-tools from OE-Core
 OPENCL_NATIVE = "${@bb.utils.contains('PACKAGECONFIG', 'freedreno', '-Dopencl-native=true', '', d)}"
-PACKAGECONFIG[opencl] = "-Dgallium-opencl=icd -Dopencl-spirv=true ${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc spirv-tools"
+PACKAGECONFIG[clover] = "-Dgallium-opencl=icd -Dopencl-spirv=true ${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc spirv-tools"
 
 PACKAGECONFIG[broadcom] = ""
 PACKAGECONFIG[etnaviv] = ""
@@ -213,7 +213,7 @@ DEV_PKG_DEPENDENCY = ""
 # development package of libgles3.
 RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev"
 
-RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'opencl', 'libclc spirv-tools', '', d)}"
+RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'clover', 'libclc spirv-tools', '', d)}"
 
 PACKAGES =+ "libegl-mesa libegl-mesa-dev \
              libosmesa libosmesa-dev \
@@ -259,7 +259,7 @@ python __anonymous() {
               ("gles", "libgles1", "libglesv1-cm1"),
               ("gles", "libgles2", "libglesv2-2"),
               ("gles", "libgles3",),
-              ("opencl", "libopencl",)):
+              ("clover", "libopencl",)):
         if not p[0] in pkgconfig:
             continue
         mlprefix = d.getVar("MLPREFIX")
-- 
2.39.2

[PATCH v3 3/3] mesa: Add PACKAGECONFIG "rusticl"

[Zoltán Böszörményi]

In the anonymous python function that creates packages based
on PACKAGECONFIG, use a single synthetic "opencl" setting
that is added when either "clover" or "rusticl" are present.

Without this, creating variables for two "libopencl-mesa" will
confuse the packaging code, resulting in subsequent packages
(like mesa-megadriver and others) being renamed incorrectly.

This also makes sense from a packaging standpoint: currently
both clover and rusticl can be enabled, in which case both CL
frontends should go into the same libopencl-mesa subpackage.

Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
---
 meta/recipes-graphics/mesa/mesa.inc | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index ff352822a3..56451d9eea 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -46,6 +46,7 @@ PROVIDES = " \
     "
 
 inherit meson pkgconfig python3native gettext features_check
+inherit ${@bb.utils.contains('PACKAGECONFIG', 'rusticl', 'rust', '', d)}
 
 BBCLASSEXTEND = "native nativesdk"
 
@@ -136,6 +137,9 @@ PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
 OPENCL_NATIVE = "${@bb.utils.contains('PACKAGECONFIG', 'freedreno', '-Dopencl-native=true', '', d)}"
 PACKAGECONFIG[clover] = "-Dgallium-opencl=icd -Dopencl-spirv=true ${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc spirv-tools"
 
+# "rusticl" requires libclc, spirv-llvm-translator and bindgen-cli-native from meta-clang and spirv-tools from OE-Core
+PACKAGECONFIG[rusticl] = "-Dgallium-rusticl=true -Drust_std=2021,-Dgallium-rusticl=false,bindgen-cli-native libclc spirv-tools spirv-llvm-translator,libclc spirv-tools spirv-llvm-translator"
+
 PACKAGECONFIG[broadcom] = ""
 PACKAGECONFIG[etnaviv] = ""
 PACKAGECONFIG[freedreno] = ""
@@ -214,6 +218,7 @@ DEV_PKG_DEPENDENCY = ""
 RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev"
 
 RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'clover', 'libclc spirv-tools', '', d)}"
+RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'rusticl', 'libclc spirv-tools spirv-llvm-translator', '', d)}"
 
 PACKAGES =+ "libegl-mesa libegl-mesa-dev \
              libosmesa libosmesa-dev \
@@ -250,6 +255,11 @@ do_install:append () {
 # RPROVIDEs/RCONFLICTs on the generic libgl name.
 python __anonymous() {
     pkgconfig = (d.getVar('PACKAGECONFIG') or "").split()
+    # Add the synthetic "opencl" string to pkgconfig because
+    # both "clover" and "rusticl" would create libopencl-mesa.
+    # Both CL frontends should go into the same package.
+    if "clover" in pkgconfig or "rusticl" in pkgconfig:
+        pkgconfig.append("opencl")
     suffix = ""
     if "-native" in d.getVar("PN"):
         suffix = "-native"
@@ -259,7 +269,7 @@ python __anonymous() {
               ("gles", "libgles1", "libglesv1-cm1"),
               ("gles", "libgles2", "libglesv2-2"),
               ("gles", "libgles3",),
-              ("clover", "libopencl",)):
+              ("opencl", "libopencl",)):
         if not p[0] in pkgconfig:
             continue
         mlprefix = d.getVar("MLPREFIX")
@@ -320,7 +330,7 @@ FILES:libgles1-mesa = "${libdir}/libGLESv1*.so.*"
 FILES:libgles2-mesa = "${libdir}/libGLESv2.so.*"
 FILES:libgl-mesa = "${libdir}/libGL.so.*"
 FILES:libglx-mesa = "${libdir}/libGLX*.so.*"
-FILES:libopencl-mesa = "${libdir}/libMesaOpenCL.so.* ${libdir}/gallium-pipe/*.so ${sysconfdir}/OpenCL/vendors/mesa.icd"
+FILES:libopencl-mesa = "${libdir}/libMesaOpenCL.so.* ${libdir}/libRusticlOpenCL.so.* ${libdir}/gallium-pipe/*.so ${sysconfdir}/OpenCL/vendors/mesa.icd ${sysconfdir}/OpenCL/vendors/rusticl.icd"
 FILES:libglapi = "${libdir}/libglapi.so.*"
 FILES:libosmesa = "${libdir}/libOSMesa.so.*"
 FILES:libxatracker = "${libdir}/libxatracker.so.*"
@@ -334,7 +344,7 @@ FILES:libglapi-dev = "${libdir}/libglapi.*"
 FILES:libgles1-mesa-dev = "${libdir}/libGLESv1*.* ${includedir}/GLES ${libdir}/pkgconfig/glesv1*.pc"
 FILES:libgles2-mesa-dev = "${libdir}/libGLESv2.* ${includedir}/GLES2 ${libdir}/pkgconfig/glesv2.pc"
 FILES:libgles3-mesa-dev = "${includedir}/GLES3"
-FILES:libopencl-mesa-dev = "${libdir}/libMesaOpenCL.so"
+FILES:libopencl-mesa-dev = "${libdir}/libMesaOpenCL.so ${libdir}/libRusticlOpenCL.so"
 FILES:libosmesa-dev = "${libdir}/libOSMesa.* ${includedir}/GL/osmesa.h ${libdir}/pkgconfig/osmesa.pc"
 FILES:libxatracker-dev = "${libdir}/libxatracker.so ${libdir}/libxatracker.la \
                           ${includedir}/xa_tracker.h ${includedir}/xa_composite.h ${includedir}/xa_context.h \
-- 
2.39.2

Re: [PATCH v3 0/3] Mesa 23.0.0

[Alexander Kanavin]

On Mon, 6 Mar 2023 at 10:11, Zoltán Böszörményi <zboszor@gmail.com> wrote:
> * bindgen-cli MR has the suggested changes
>   See https://github.com/kraj/meta-clang/pull/748

I would prefer that this PR is accepted and merged first before a
change that relies on that recipe to exist is submitted here.

Alex

Re: [OE-core] [PATCH v3 0/3] Mesa 23.0.0

[Alexander Kanavin]

On Mon, 6 Mar 2023 at 11:09, Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:
>
> On Mon, 6 Mar 2023 at 10:11, Zoltán Böszörményi <zboszor@gmail.com> wrote:
> > * bindgen-cli MR has the suggested changes
> >   See https://github.com/kraj/meta-clang/pull/748
>
> I would prefer that this PR is accepted and merged first before a
> change that relies on that recipe to exist is submitted here.

I mean, until that happens, the changes here should be seen RFC.

Alex

Re: [PATCH v3 0/3] Mesa 23.0.0

[Böszörményi Zoltán]

2023. 03. 06. 11:09 keltezéssel, Alexander Kanavin írta:
> On Mon, 6 Mar 2023 at 10:11, Zoltán Böszörményi <zboszor@gmail.com> wrote:
>> * bindgen-cli MR has the suggested changes
>>    See https://github.com/kraj/meta-clang/pull/748
> I would prefer that this PR is accepted and merged first before a
> change that relies on that recipe to exist is submitted here.

And a seemingly unused new recipe is not going to be merged
for maintenance cost reasons as it was expressed on this very
mailing list a couple of times. Chicken and egg problem.

I prefer posting both at the same time.

Re: [OE-core] [PATCH v3 1/3] mesa, mesa-gl: 23.0.0

[Otavio Salvador]

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

Re: [OE-core] [PATCH v3 2/3] mesa: Rename PACKAGECONFIG "opencl" to "clover"

[Otavio Salvador]

Em seg., 6 de mar. de 2023 às 06:11, Zoltan Boszormenyi
<zboszor@gmail.com> escreveu:
>
> There is another OpenCL frontend called "rusticl" now.
>
> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
...
> +PACKAGECONFIG[clover] = "-Dgallium-opencl=icd -Dopencl-spirv=true ${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc spirv-tools"

PACKAGECONFIG[opencl-clover]

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

Re: [OE-core] [PATCH v3 3/3] mesa: Add PACKAGECONFIG "rusticl"

[Otavio Salvador]

Em seg., 6 de mar. de 2023 às 06:11, Zoltan Boszormenyi
<zboszor@gmail.com> escreveu:
>
> In the anonymous python function that creates packages based
> on PACKAGECONFIG, use a single synthetic "opencl" setting
> that is added when either "clover" or "rusticl" are present.
>
> Without this, creating variables for two "libopencl-mesa" will
> confuse the packaging code, resulting in subsequent packages
> (like mesa-megadriver and others) being renamed incorrectly.
>
> This also makes sense from a packaging standpoint: currently
> both clover and rusticl can be enabled, in which case both CL
> frontends should go into the same libopencl-mesa subpackage.
>
> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>

Please name the PACKAGECONFIG as opencl-rusticl

>  inherit meson pkgconfig python3native gettext features_check
> +inherit ${@bb.utils.contains('PACKAGECONFIG', 'rusticl', 'rust', '', d)}

Here.

>  BBCLASSEXTEND = "native nativesdk"
>
> @@ -136,6 +137,9 @@ PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
>  OPENCL_NATIVE = "${@bb.utils.contains('PACKAGECONFIG', 'freedreno', '-Dopencl-native=true', '', d)}"
>  PACKAGECONFIG[clover] = "-Dgallium-opencl=icd -Dopencl-spirv=true ${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc spirv-tools"
>
> +# "rusticl" requires libclc, spirv-llvm-translator and bindgen-cli-native from meta-clang and spirv-tools from OE-Core
> +PACKAGECONFIG[rusticl] = "-Dgallium-rusticl=true -Drust_std=2021,-Dgallium-rusticl=false,bindgen-cli-native libclc spirv-tools spirv-llvm-translator,libclc spirv-tools spirv-llvm-translator"

Here.

>  RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'clover', 'libclc spirv-tools', '', d)}"
> +RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'rusticl', 'libclc spirv-tools spirv-llvm-translator', '', d)}"

Here.

>
>  PACKAGES =+ "libegl-mesa libegl-mesa-dev \
>               libosmesa libosmesa-dev \
> @@ -250,6 +255,11 @@ do_install:append () {
>  # RPROVIDEs/RCONFLICTs on the generic libgl name.
>  python __anonymous() {
>      pkgconfig = (d.getVar('PACKAGECONFIG') or "").split()
> +    # Add the synthetic "opencl" string to pkgconfig because
> +    # both "clover" and "rusticl" would create libopencl-mesa.
> +    # Both CL frontends should go into the same package.
> +    if "clover" in pkgconfig or "rusticl" in pkgconfig:
> +        pkgconfig.append("opencl")

Here.

Also, we need to add RREPLACES, RRECOMMENDS and RCONFLICTS to old
clover package so we support package feed upgrades.

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

Re: [OE-core] [PATCH v3 3/3] mesa: Add PACKAGECONFIG "rusticl"

[Böszörményi Zoltán]

2023. 03. 06. 16:59 keltezéssel, Otavio Salvador írta:
> Em seg., 6 de mar. de 2023 às 06:11, Zoltan Boszormenyi
> <zboszor@gmail.com> escreveu:
>> In the anonymous python function that creates packages based
>> on PACKAGECONFIG, use a single synthetic "opencl" setting
>> that is added when either "clover" or "rusticl" are present.
>>
>> Without this, creating variables for two "libopencl-mesa" will
>> confuse the packaging code, resulting in subsequent packages
>> (like mesa-megadriver and others) being renamed incorrectly.
>>
>> This also makes sense from a packaging standpoint: currently
>> both clover and rusticl can be enabled, in which case both CL
>> frontends should go into the same libopencl-mesa subpackage.
>>
>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
> Please name the PACKAGECONFIG as opencl-rusticl
>
>>   inherit meson pkgconfig python3native gettext features_check
>> +inherit ${@bb.utils.contains('PACKAGECONFIG', 'rusticl', 'rust', '', d)}
> Here.
>
>>   BBCLASSEXTEND = "native nativesdk"
>>
>> @@ -136,6 +137,9 @@ PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
>>   OPENCL_NATIVE = "${@bb.utils.contains('PACKAGECONFIG', 'freedreno', '-Dopencl-native=true', '', d)}"
>>   PACKAGECONFIG[clover] = "-Dgallium-opencl=icd -Dopencl-spirv=true ${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc spirv-tools"
>>
>> +# "rusticl" requires libclc, spirv-llvm-translator and bindgen-cli-native from meta-clang and spirv-tools from OE-Core
>> +PACKAGECONFIG[rusticl] = "-Dgallium-rusticl=true -Drust_std=2021,-Dgallium-rusticl=false,bindgen-cli-native libclc spirv-tools spirv-llvm-translator,libclc spirv-tools spirv-llvm-translator"
> Here.
>
>>   RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'clover', 'libclc spirv-tools', '', d)}"
>> +RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'rusticl', 'libclc spirv-tools spirv-llvm-translator', '', d)}"
> Here.
>
>>   PACKAGES =+ "libegl-mesa libegl-mesa-dev \
>>                libosmesa libosmesa-dev \
>> @@ -250,6 +255,11 @@ do_install:append () {
>>   # RPROVIDEs/RCONFLICTs on the generic libgl name.
>>   python __anonymous() {
>>       pkgconfig = (d.getVar('PACKAGECONFIG') or "").split()
>> +    # Add the synthetic "opencl" string to pkgconfig because
>> +    # both "clover" and "rusticl" would create libopencl-mesa.
>> +    # Both CL frontends should go into the same package.
>> +    if "clover" in pkgconfig or "rusticl" in pkgconfig:
>> +        pkgconfig.append("opencl")
> Here.

Thanks, I will rename the PACKAGECONFIG names.

>
> Also, we need to add RREPLACES, RRECOMMENDS and RCONFLICTS to old
> clover package so we support package feed upgrades.

There is no "clover" package, there is libopencl-mesa.
That doesn't change with this, with either or both PACKAGECONFIGs
enabled, there is still libopencl-mesa that ships either or
both CL frontends. The versioning should be enough for the upgrade.

Re: [OE-core] [PATCH v3 1/3] mesa, mesa-gl: 23.0.0

[Alexander Kanavin]

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

Re: [OE-core] [PATCH v3 1/3] mesa, mesa-gl: 23.0.0

[Böszörményi Zoltán]

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

Re: [OE-core] [PATCH v3 1/3] mesa, mesa-gl: 23.0.0

[Alexander Kanavin]

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

Re: [OE-core] [PATCH v3 1/3] mesa, mesa-gl: 23.0.0

[Böszörményi Zoltán]

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

Re: [OE-core] [PATCH v3 1/3] mesa, mesa-gl: 23.0.0

[Alexander Kanavin]

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

Re: [OE-core] [PATCH v3 1/3] mesa, mesa-gl: 23.0.0

[Böszörményi Zoltán]

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.

Re: [OE-core] [PATCH v3 1/3] mesa, mesa-gl: 23.0.0

[Alexander Kanavin]

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