[PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[Quentin Schulz]

@Otavio, can I add the new mesa-tools-native recipe under your
maintainership in meta/conf/distro/include/maintainers.inc, it is after
all still mesa?

Panfrost support has been broken for a while already because it now
requires libclc which isn't enforced by default. This fixes this
oversight.

While re-adding support for panfrost, the build time for libclc were a
bit too much to my taste and I tried to figure out if we could lighten
up the dependencies for the target recipe and it seems to be the case.

libclc brings very expensive dependencies such as llvm and clang.
Building clang and llvm for each target architecture is very expensive,
but mesa allows to depend on prebuilt host binaries (mesa-clc and
precomp-compiler). Those are built by mesa as well, but can be compiled
in mesa-native instead of mesa, making the dependency expensive but only
once regardless of the number of target architectures to build for.
Ideally the mesa-clc and precomp-compiler would only be compiled in
mesa-native if target mesa requires libclc support, however this is not
possible as a target recipe cannot impact or depend on a native recipe's
configuration. We thus have two choices, always build libclc in
mesa-native with its heavy dependencies and impact every build or force
the user to modify the mesa-native recipe in a custom layer (as a native
recipe cannot use target's OVERRIDES). The latter is unacceptable so the
former seems to be the only option. Another big downside is that
mesa-native currently builds drivers (amd, nouveau, svga) which we may
have absolutely no interest in building, increasing the build time and
possibly dependencies list).

A third choice is to spin-off the native mesa recipe with libclc support
into a new recipe without drivers and only what's necessary to build
mesa-clc and precomp-compiler binaries.
This allows to keep a "clean" mesa-native recipe for whoever needs those
drivers built-in (e.g. for testing, for qemu-native, or whatever else)
and only bring the libclc dependency when required by the target recipe.

Because libclc is now only built for the host, opencl support now needs
to explicitly bring libclc and others to build as libclc won't bring it
in the build environment anymore.

Note that this was essentially only build tested (run tested on RK3588
with panfrost though).

Note that building gallium-llvm support on big.LITTLE architecture with
TOOLCHAIN = "gcc" (the default) currently doesn't work as llvm doesn't
support big.LITTLE architecture in -mcpu/-march which is passed to the
CFLAGS/CXXFLAGS/LDFLAGS via the TUNE_CCARGS. I haven't investigated
further than that but that prevents us from building opencl support for
Rockchip most popular and powerful SoCs right now. One option could be
to force this recipe to be built with clang toolchain only whenever
gallium-llvm is specified in PACKAGECONFIG (not tested). Though that may
be not straightforward seeing the comment in libclc recipe related to
forcing the toolchain to clang.
I'm also not sure mesa has a way to specify different args to LLVM-only
drivers but that could be another option.

Runtime tested on RK3588 and PX30 with kmscube.
Partially runtime tested on PX30 with opencl-cts (and rusticl; it fails
after some time but could be kernel related as it starts failing after
[  968.625506] panfrost ff400000.gpu: gpu sched timeout, js=1, config=0x7b00, status=0x8, head=0xa68d200, tail=0xa68d200, sched_job=0000000019e6f20d

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
Changes in v6:
- added patches to fix OpenCL, Panfrost and Asahi host paths poisoning,
- removed intel from mesa-tools-native's PACKAGECONFIG as no intel
  driver requires a precomp-compiler anymore,
- added patch for migrating to bb.utils.filter instead of
  bb.utils.contains as recommended by Khem,
- reworded PACKAGECONFIG moving patch's commit log to be hopefully
  clearer as to why mesa-gl.bb is left untouched,
- added patch to allow disabling xmlconfig support,
- fixed mesa-native + mesa-tools-native installing same files (driconf
  files) by disabling xmlconfig in mesa-tools-native,
- rebased on top of master,
- added patch to bump mesa recipes to 25.2.1,
- Link to v5: https://lore.kernel.org/r/20250819-mesa-libclc-panfrost-v5-0-b8b89e6af908@cherry.de

Changes in v5:
- removed RFC prefix as it's gone through multiple reviews already, I
  guess it should be fine by now,
- reworded patch 3 to hopefully make it clearer why mesa-gl doesn't get
  any of the changes mesa.bb gets,
- Link to v4: https://lore.kernel.org/r/20250801-mesa-libclc-panfrost-v4-0-101c6dcf564f@cherry.de

Changes in v4:
- revamped patch removing egl/gles from mesa-gl by making the native and
  nativesdk PACKAGECONFIG use = instead of ??= (see patch 1),
- added "No intended change in behavior" wherever it is expected,
- Link to v3: https://lore.kernel.org/r/20250729-mesa-libclc-panfrost-v3-0-42559ddc93ef@cherry.de

Changes in v3:
- added patch to move S into mesa.inc,
- added patch to remove egl/gles from mesa-gl,
- added patch to make mesa-gl a target-only recipe,
- updated comment for PACKAGECONFIG[opencl] dependency on other
  PACKAGECONFIG,
- added clarification in commit log of commit adding asahi to TOOLS,
- Link to v2: https://lore.kernel.org/r/20250721-mesa-libclc-panfrost-v2-0-f713d0858949@cherry.de

Changes in v2:
- spin-off mesa-clc/precomp-compiler host binary building into a
  mesa-tools-native recipe to lighten the dependency even more (no
  native mesa drivers to build),
- make libclc's target mesa depend on mesa-tools-native instead of
  mesa-native,
- Link to v1: https://lore.kernel.org/r/20250624-mesa-libclc-panfrost-v1-0-9ed8ca980e21@cherry.de

---
Quentin Schulz (13):
      mesa-gl: make mesa-gl really openGL-only
      mesa-gl: use bb.utils.filter to improve readability
      mesa: move PACKAGECONFIG defaults to recipes
      mesa: move PROVIDES out of include file
      mesa: move BBCLASSEXTEND out of the include file
      mesa-gl: make recipe target only
      mesa: add asahi to TOOLS when selected in PACKAGECONFIG
      mesa: allow to disable xmlconfig support
      mesa: avoid host paths poisoning
      mesa: avoid host path poisoning when enabling OpenCL
      mesa: use simpler mesa-tools-native recipe as dependency for libclc
      mesa: fix panfrost driver build
      mesa: upgrade 25.2.0 -> 25.2.1

Ross Burton (1):
      mesa: assign S in include file

 ...01-meson-fix-libcl-assert-reproducibility.patch | 43 ++++++++++++++++++
 meta/recipes-graphics/mesa/mesa-gl.bb              |  8 ++--
 meta/recipes-graphics/mesa/mesa-tools-native.bb    | 19 ++++++++
 meta/recipes-graphics/mesa/mesa.bb                 | 26 +++++++++++
 meta/recipes-graphics/mesa/mesa.inc                | 53 ++++++----------------
 5 files changed, 105 insertions(+), 44 deletions(-)
---
base-commit: e7423ae09e62a1f5f72391e61cad2381f917c113
change-id: 20250624-mesa-libclc-panfrost-108d62e1899b

Best regards,
-- 
Quentin Schulz <quentin.schulz@cherry.de>

[PATCH v6 01/14] mesa-gl: make mesa-gl really openGL-only

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

The ??= operator for PACKAGECONFIG doesn't actually do anything because
the recipe includes mesa.inc which already sets this variable (with the
= operator).

This probably wasn't noticed until now because mesa-gl is likely only
ever built in its target flavor which was already set correctly thanks
to the :class-target override.

This essentially only make mesa-gl-native and nativesdk-mesa-gl follow
the same configuration as the target.

Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa-gl.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa-gl.bb b/meta/recipes-graphics/mesa/mesa-gl.bb
index e2f03c81c4588c6257ffec2892fef7fcbe9f82bf..35d6dc854cf4dfac7a757e333e25e4ddeab10b6e 100644
--- a/meta/recipes-graphics/mesa/mesa-gl.bb
+++ b/meta/recipes-graphics/mesa/mesa-gl.bb
@@ -9,6 +9,4 @@ S = "${UNPACKDIR}/mesa-${PV}"
 TARGET_CFLAGS = "-I${STAGING_INCDIR}/drm"
 
 # At least one DRI rendering engine is required to build mesa.
-PACKAGECONFIG ??= "opengl gallium ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
-PACKAGECONFIG:class-target = "opengl gallium ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
-
+PACKAGECONFIG = "opengl gallium ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"

-- 
2.50.1

[PATCH v6 02/14] mesa-gl: use bb.utils.filter to improve readability

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}" is
exactly the same as ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} so
use the latter to make it easier on the eyes.

Suggested-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa-gl.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa-gl.bb b/meta/recipes-graphics/mesa/mesa-gl.bb
index 35d6dc854cf4dfac7a757e333e25e4ddeab10b6e..e11758767f02efd38e2d7b90738424b9ec825120 100644
--- a/meta/recipes-graphics/mesa/mesa-gl.bb
+++ b/meta/recipes-graphics/mesa/mesa-gl.bb
@@ -9,4 +9,4 @@ S = "${UNPACKDIR}/mesa-${PV}"
 TARGET_CFLAGS = "-I${STAGING_INCDIR}/drm"
 
 # At least one DRI rendering engine is required to build mesa.
-PACKAGECONFIG = "opengl gallium ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
+PACKAGECONFIG = "opengl gallium ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"

-- 
2.50.1

Patchtest results for [PATCH v6 02/14] mesa-gl: use bb.utils.filter to improve readability

[patchtest]

[-- Attachment #1: Type: text/plain, Size: 3235 bytes --]

Thank you for your submission. Patchtest identified one
or more issues with the patch. Please see the log below for
more information:

---
Testing patch /home/patchtest/share/mboxes/v6-02-14-mesa-gl-use-bb.utils.filter-to-improve-readability.patch

FAIL: test commit message user tags: Mbox includes one or more GitHub-style username tags. Ensure that any "@" symbols are stripped out of usernames (test_mbox.TestMbox.test_commit_message_user_tags)

PASS: test Signed-off-by presence (test_mbox.TestMbox.test_signed_off_by_presence)
PASS: test author valid (test_mbox.TestMbox.test_author_valid)
PASS: test commit message presence (test_mbox.TestMbox.test_commit_message_presence)
PASS: test max line length (test_metadata.TestMetadata.test_max_line_length)
PASS: test mbox format (test_mbox.TestMbox.test_mbox_format)
PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade)
PASS: test shortlog format (test_mbox.TestMbox.test_shortlog_format)
PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length)
PASS: test target mailing list (test_mbox.TestMbox.test_target_mailing_list)

SKIP: pretest pylint: No python related patches, skipping test (test_python_pylint.PyLint.pretest_pylint)
SKIP: pretest src uri left files: No modified recipes, skipping pretest (test_metadata.TestMetadata.pretest_src_uri_left_files)
SKIP: test CVE check ignore: No modified recipes or older target branch, skipping test (test_metadata.TestMetadata.test_cve_check_ignore)
SKIP: test CVE tag format: No new CVE patches introduced (test_patch.TestPatch.test_cve_tag_format)
SKIP: test Signed-off-by presence: No new CVE patches introduced (test_patch.TestPatch.test_signed_off_by_presence)
SKIP: test Upstream-Status presence: No new CVE patches introduced (test_patch.TestPatch.test_upstream_status_presence_format)
SKIP: test bugzilla entry format: No bug ID found (test_mbox.TestMbox.test_bugzilla_entry_format)
SKIP: test lic files chksum modified not mentioned: No modified recipes, skipping test (test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned)
SKIP: test lic files chksum presence: No added recipes, skipping test (test_metadata.TestMetadata.test_lic_files_chksum_presence)
SKIP: test license presence: No added recipes, skipping test (test_metadata.TestMetadata.test_license_presence)
SKIP: test pylint: No python related patches, skipping test (test_python_pylint.PyLint.test_pylint)
SKIP: test series merge on head: Merge test is disabled for now (test_mbox.TestMbox.test_series_merge_on_head)
SKIP: test src uri left files: No modified recipes, skipping pretest (test_metadata.TestMetadata.test_src_uri_left_files)
SKIP: test summary presence: No added recipes, skipping test (test_metadata.TestMetadata.test_summary_presence)

---

Please address the issues identified and
submit a new revision of the patch, or alternatively, reply to this
email with an explanation of why the patch should be accepted. If you
believe these results are due to an error in patchtest, please submit a
bug at https://bugzilla.yoctoproject.org/ (use the 'Patchtest' category
under 'Yocto Project Subprojects'). For more information on specific
failures, see: https://wiki.yoctoproject.org/wiki/Patchtest. Thank
you!

[PATCH v6 03/14] mesa: move PACKAGECONFIG defaults to recipes

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

We're planning on reusing mesa.inc for a new mesa-tools-native recipe
which will require much less in terms of PACKAGECONFIG than the actual
mesa recipes.

It also doesn't make a lot of sense to have a default PACKAGECONFIG in
an include file inherited by multiple recipes (here mesa and mesa-gl)
which is highlighted by the fact that the only other recipe that
includes mesa.inc (mesa-gl) overrides PACKAGECONFIG (hence why mesa-gl
only gets a partial migration of PACKAGECONFIG defaults.

No intended change in behavior.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa-gl.bb |  5 +++++
 meta/recipes-graphics/mesa/mesa.bb    | 12 ++++++++++++
 meta/recipes-graphics/mesa/mesa.inc   | 13 -------------
 3 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa-gl.bb b/meta/recipes-graphics/mesa/mesa-gl.bb
index e11758767f02efd38e2d7b90738424b9ec825120..d27d606875a5e143276356b9844634082c7354cb 100644
--- a/meta/recipes-graphics/mesa/mesa-gl.bb
+++ b/meta/recipes-graphics/mesa/mesa-gl.bb
@@ -10,3 +10,8 @@ TARGET_CFLAGS = "-I${STAGING_INCDIR}/drm"
 
 # At least one DRI rendering engine is required to build mesa.
 PACKAGECONFIG = "opengl gallium ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
+
+PACKAGECONFIG:append:x86 = " libclc gallium-llvm intel amd nouveau svga"
+PACKAGECONFIG:append:x86-64 = " libclc gallium-llvm intel amd nouveau svga"
+PACKAGECONFIG:append:i686 = " libclc gallium-llvm intel amd nouveau svga"
+PACKAGECONFIG:append:class-native = " libclc gallium-llvm amd nouveau svga"
diff --git a/meta/recipes-graphics/mesa/mesa.bb b/meta/recipes-graphics/mesa/mesa.bb
index 96e8aa38d61661c02d2228d825f70cf41f985382..305b18070d6a47a53f204906a16bc8d4833fd9d6 100644
--- a/meta/recipes-graphics/mesa/mesa.bb
+++ b/meta/recipes-graphics/mesa/mesa.bb
@@ -1,2 +1,14 @@
 require ${BPN}.inc
 
+PACKAGECONFIG = " \
+	gallium \
+	video-codecs \
+	${@bb.utils.filter('DISTRO_FEATURES', 'x11 vulkan wayland glvnd', d)} \
+	${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl egl gles gbm virgl', '', d)} \
+	${@bb.utils.contains('DISTRO_FEATURES', 'vulkan', 'zink', '', d)} \
+"
+
+PACKAGECONFIG:append:x86 = " libclc gallium-llvm intel amd nouveau svga"
+PACKAGECONFIG:append:x86-64 = " libclc gallium-llvm intel amd nouveau svga"
+PACKAGECONFIG:append:i686 = " libclc gallium-llvm intel amd nouveau svga"
+PACKAGECONFIG:append:class-native = " libclc gallium-llvm amd nouveau svga"
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index a848a2ad8c73dad945039b5374c66e221b5b9a05..387f954789c603dac767ccf18ad60acb6731d35a 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -80,22 +80,9 @@ EXTRA_OEMESON = " \
 def strip_comma(s):
     return s.strip(',')
 
-PACKAGECONFIG = " \
-	gallium \
-	video-codecs \
-	${@bb.utils.filter('DISTRO_FEATURES', 'x11 vulkan wayland glvnd', d)} \
-	${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl egl gles gbm virgl', '', d)} \
-	${@bb.utils.contains('DISTRO_FEATURES', 'vulkan', 'zink', '', d)} \
-"
-
 # skip all Rust dependencies if we are not building OpenCL"
 INHIBIT_DEFAULT_RUST_DEPS = "${@bb.utils.contains('PACKAGECONFIG', 'opencl', '', '1', d)}"
 
-PACKAGECONFIG:append:x86 = " libclc gallium-llvm intel amd nouveau svga"
-PACKAGECONFIG:append:x86-64 = " libclc gallium-llvm intel amd nouveau svga"
-PACKAGECONFIG:append:i686 = " libclc gallium-llvm intel amd nouveau svga"
-PACKAGECONFIG:append:class-native = " libclc gallium-llvm amd nouveau svga"
-
 # "gbm" requires "opengl"
 PACKAGECONFIG[gbm] = "-Dgbm=enabled,-Dgbm=disabled"
 

-- 
2.50.1

[PATCH v6 04/14] mesa: move PROVIDES out of include file

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

There currently are two recipes including mesa.inc: mesa-gl and mesa.

Because mesa-gl.bb already sets PROVIDES, overriding the value it should
be getting from mesa.inc, move PROVIDES from mesa.inc to mesa.bb,
keeping the value in mesa-gl.bb intact.

Because GLPROVIDES is not used in mesa-gl.bb, it also is only moved to
mesa.bb.

No intended change in behavior.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa.bb  | 11 +++++++++++
 meta/recipes-graphics/mesa/mesa.inc | 10 ----------
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa.bb b/meta/recipes-graphics/mesa/mesa.bb
index 305b18070d6a47a53f204906a16bc8d4833fd9d6..51d0384ef5930f36ff2f5c20ebad2d7ad8b817a9 100644
--- a/meta/recipes-graphics/mesa/mesa.bb
+++ b/meta/recipes-graphics/mesa/mesa.bb
@@ -12,3 +12,14 @@ PACKAGECONFIG:append:x86 = " libclc gallium-llvm intel amd nouveau svga"
 PACKAGECONFIG:append:x86-64 = " libclc gallium-llvm intel amd nouveau svga"
 PACKAGECONFIG:append:i686 = " libclc gallium-llvm intel amd nouveau svga"
 PACKAGECONFIG:append:class-native = " libclc gallium-llvm amd nouveau svga"
+
+GLPROVIDES = " \
+    ${@bb.utils.contains('PACKAGECONFIG', 'opengl', 'virtual/libgl', '', d)} \
+    ${@bb.utils.contains('PACKAGECONFIG', 'gles', 'virtual/libgles1 virtual/libgles2 virtual/libgles3', '', d)} \
+    ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'virtual/egl', '', d)} \
+"
+PROVIDES = " \
+    ${@bb.utils.contains('PACKAGECONFIG', 'glvnd', '', d.getVar('GLPROVIDES'), d)} \
+    ${@bb.utils.contains('PACKAGECONFIG', 'gbm', 'virtual/libgbm', '', d)} \
+    virtual/mesa \
+"
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 387f954789c603dac767ccf18ad60acb6731d35a..46fe465cd84ae9e799571d8c519a1d7933c716a6 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -40,16 +40,6 @@ do_install:append() {
 
 DEPENDS = "expat makedepend-native flex-native bison-native libxml2-native zlib chrpath-replacement-native python3-mako-native gettext-native python3-pyyaml-native"
 EXTRANATIVEPATH += "chrpath-native"
-GLPROVIDES = " \
-    ${@bb.utils.contains('PACKAGECONFIG', 'opengl', 'virtual/libgl', '', d)} \
-    ${@bb.utils.contains('PACKAGECONFIG', 'gles', 'virtual/libgles1 virtual/libgles2 virtual/libgles3', '', d)} \
-    ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'virtual/egl', '', d)} \
-"
-PROVIDES = " \
-    ${@bb.utils.contains('PACKAGECONFIG', 'glvnd', '', d.getVar('GLPROVIDES'), d)} \
-    ${@bb.utils.contains('PACKAGECONFIG', 'gbm', 'virtual/libgbm', '', d)} \
-    virtual/mesa \
-    "
 
 inherit meson pkgconfig python3native gettext features_check rust
 

-- 
2.50.1

[PATCH v6 05/14] mesa: move BBCLASSEXTEND out of the include file

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

We're going to have a new mesa-tools-native recipe include mesa.inc
soon. We don't need a target mesa-tools recipe for now so we'll go with
a native-only recipe which this BBCLASSEXTEND prevents us to do
properly, so let's move them to the recipes instead.

No intended change in behavior.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa-gl.bb | 2 ++
 meta/recipes-graphics/mesa/mesa.bb    | 2 ++
 meta/recipes-graphics/mesa/mesa.inc   | 2 --
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa-gl.bb b/meta/recipes-graphics/mesa/mesa-gl.bb
index d27d606875a5e143276356b9844634082c7354cb..4d71406b6dfbdd260ef61a7ab9427c70c47685f4 100644
--- a/meta/recipes-graphics/mesa/mesa-gl.bb
+++ b/meta/recipes-graphics/mesa/mesa-gl.bb
@@ -15,3 +15,5 @@ PACKAGECONFIG:append:x86 = " libclc gallium-llvm intel amd nouveau svga"
 PACKAGECONFIG:append:x86-64 = " libclc gallium-llvm intel amd nouveau svga"
 PACKAGECONFIG:append:i686 = " libclc gallium-llvm intel amd nouveau svga"
 PACKAGECONFIG:append:class-native = " libclc gallium-llvm amd nouveau svga"
+
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-graphics/mesa/mesa.bb b/meta/recipes-graphics/mesa/mesa.bb
index 51d0384ef5930f36ff2f5c20ebad2d7ad8b817a9..db5eab5fb27c6a7228f6e0fd823514352c42ad1f 100644
--- a/meta/recipes-graphics/mesa/mesa.bb
+++ b/meta/recipes-graphics/mesa/mesa.bb
@@ -23,3 +23,5 @@ PROVIDES = " \
     ${@bb.utils.contains('PACKAGECONFIG', 'gbm', 'virtual/libgbm', '', d)} \
     virtual/mesa \
 "
+
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 46fe465cd84ae9e799571d8c519a1d7933c716a6..4c079fe0aba8125763f0a598d6e114082a8453ee 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -43,8 +43,6 @@ EXTRANATIVEPATH += "chrpath-native"
 
 inherit meson pkgconfig python3native gettext features_check rust
 
-BBCLASSEXTEND = "native nativesdk"
-
 ANY_OF_DISTRO_FEATURES = "opengl vulkan"
 
 PLATFORMS ??= "${@bb.utils.filter('PACKAGECONFIG', 'x11 wayland', d)}"

-- 
2.50.1

[PATCH v6 06/14] mesa: assign S in include file

[Quentin Schulz]

From: Ross Burton <ross.burton@arm.com>

Anything including mesa.inc will have the sources extracted in
${UNPACKDIR}/mesa-${PV}.

The default for S is ${UNPACKDIR}/${BP}. ${BP} is ${BPN}-${PV}. Because
mesa.bb is named mesa, BPN will be mesa and thus S wasn't required for
mesa.bb but only for mesa-gl.bb. This also explains why this change is
fine for mesa.bb as the value of S won't have changed, the ${BPN} part
is now just hardcoded to "mesa" for mesa.bb instead.

No intended change in behavior.

Signed-off-by: Ross Burton <ross.burton@arm.com>
[added commit log and title]
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa-gl.bb | 2 --
 meta/recipes-graphics/mesa/mesa.inc   | 2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa-gl.bb b/meta/recipes-graphics/mesa/mesa-gl.bb
index 4d71406b6dfbdd260ef61a7ab9427c70c47685f4..7b283415dd26a4dc73713a8bed1f794b02c979a9 100644
--- a/meta/recipes-graphics/mesa/mesa-gl.bb
+++ b/meta/recipes-graphics/mesa/mesa-gl.bb
@@ -4,8 +4,6 @@ SUMMARY += " (OpenGL only, no EGL/GLES)"
 
 PROVIDES = "virtual/libgl virtual/mesa"
 
-S = "${UNPACKDIR}/mesa-${PV}"
-
 TARGET_CFLAGS = "-I${STAGING_INCDIR}/drm"
 
 # At least one DRI rendering engine is required to build mesa.
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 4c079fe0aba8125763f0a598d6e114082a8453ee..45499f6c421e7fb0b06ef95179168c6cb9fff1cf 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -24,6 +24,8 @@ PV = "25.2.0"
 
 UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P<pver>\d+(\.\d+)+)"
 
+S = "${UNPACKDIR}/mesa-${PV}"
+
 #because we cannot rely on the fact that all apps will use pkgconfig,
 #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER
 do_install:append() {

-- 
2.50.1

[PATCH v6 07/14] mesa-gl: make recipe target only

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

According to the introducing commit log[1] and Dmitry's recollection[2],
the whole point of mesa-gl recipe is to provide GL library in case there
are vendor-provided GLES libraries.

Therefore, let's make this recipe target only by removing the
BBCLASSEXTEND variable.

No intended change in behavior for the target recipe.

[1] https://git.yoctoproject.org/poky/commit/?id=015cb13a67c672de30f5384dab5ab4b8db305281
[2] https://lore.kernel.org/openembedded-core/5ebxxyvkcur3zpef5krvyizomgdgtls4qau7s2i2mgcmvs2loy@ilcud37qk6sn/

Suggested-by: Ross Burton <ross.burton@arm.com>
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa-gl.bb | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa-gl.bb b/meta/recipes-graphics/mesa/mesa-gl.bb
index 7b283415dd26a4dc73713a8bed1f794b02c979a9..832137c8188f1253c9924e4c8410e5fae40f10fb 100644
--- a/meta/recipes-graphics/mesa/mesa-gl.bb
+++ b/meta/recipes-graphics/mesa/mesa-gl.bb
@@ -12,6 +12,3 @@ PACKAGECONFIG = "opengl gallium ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}
 PACKAGECONFIG:append:x86 = " libclc gallium-llvm intel amd nouveau svga"
 PACKAGECONFIG:append:x86-64 = " libclc gallium-llvm intel amd nouveau svga"
 PACKAGECONFIG:append:i686 = " libclc gallium-llvm intel amd nouveau svga"
-PACKAGECONFIG:append:class-native = " libclc gallium-llvm amd nouveau svga"
-
-BBCLASSEXTEND = "native nativesdk"

-- 
2.50.1

[PATCH v6 08/14] mesa: add asahi to TOOLS when selected in PACKAGECONFIG

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

Similarly to panfrost and other PACKAGECONFIG, mesa has tools for asahi.
So let's build the tools whenever asked.

While the tools are often built regardless of their presence in the
"tools" mesa option whenever the appropriate gallium or vulkan driver is
built, this allows to build the tool(s) without building the drivers
which can be beneficial for native recipes where it makes little sense
to build drivers.

This will be useful for building asahi_clc precomp-compiler in native
mesa for example which only builds if:
 - one enables the asahi gallium driver, or
 - one enables the asahi vulkan driver, or
 - one builds the asahi tools
c.f. https://gitlab.freedesktop.org/mesa/mesa/-/blob/mesa-25.1.5/src/asahi/meson.build?ref_type=tags#L12-L17

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 45499f6c421e7fb0b06ef95179168c6cb9fff1cf..81b099bf6e5fe624e91e6a780f8bb55854580c2d 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -100,6 +100,7 @@ PACKAGECONFIG[vulkan] = "-Dvulkan-drivers=${@strip_comma('${VULKAN_DRIVERS}')},
 # mesa development and testing tools support, per driver
 TOOLS = ""
 TOOLS_DEPS = ""
+TOOLS:append = "${@bb.utils.contains('PACKAGECONFIG', 'asahi', ',asahi', '', d)}"
 TOOLS:append = "${@bb.utils.contains('PACKAGECONFIG', 'etnaviv', ',etnaviv', '', d)}"
 TOOLS:append = "${@bb.utils.contains('PACKAGECONFIG', 'freedreno', ',freedreno', '', d)}"
 TOOLS:append = "${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima', '', d)}"

-- 
2.50.1

[PATCH v6 09/14] mesa: allow to disable xmlconfig support

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

From my understanding, xmlconfig is useful for "dynamic" driconf
support, i.e. driconf the user specifies at runtime.

According to the wiki[1], driconf is useful for OpenGL drivers.

I wager we mostly don't need xmlconfig at all which may allow us to also
get rid (in most cases) of the expat dependency. But that is an
optimization to investigate later, so let's keep xmlconfig enabled for
now as it is the default whenever the meson feature is not disabled
(defaults to auto) and expat is found (currently part of DEPENDS in
mesa.inc).

This will be useful for mesa-tools-native which isn't meant to compile
drivers and thus shouldn't try to compile driconf support and install
driconf example files.

Technically, xmlconfig depends on the expat meson feature (and the
presence of the expat build dependency) but the feature is default auto
so having expat dependency in xmlconfig PACKAGECONFIG seems enough
instead of having one PACKAGECONFIG depend on another PACKAGECONFIG's
presence.

[1] https://dri.freedesktop.org/wiki/DriConf/

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa-gl.bb | 2 +-
 meta/recipes-graphics/mesa/mesa.bb    | 1 +
 meta/recipes-graphics/mesa/mesa.inc   | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa-gl.bb b/meta/recipes-graphics/mesa/mesa-gl.bb
index 832137c8188f1253c9924e4c8410e5fae40f10fb..3b55d2b77e55b1297a1507a86aa16e6d15944983 100644
--- a/meta/recipes-graphics/mesa/mesa-gl.bb
+++ b/meta/recipes-graphics/mesa/mesa-gl.bb
@@ -7,7 +7,7 @@ PROVIDES = "virtual/libgl virtual/mesa"
 TARGET_CFLAGS = "-I${STAGING_INCDIR}/drm"
 
 # At least one DRI rendering engine is required to build mesa.
-PACKAGECONFIG = "opengl gallium ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
+PACKAGECONFIG = "opengl gallium ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} xmlconfig"
 
 PACKAGECONFIG:append:x86 = " libclc gallium-llvm intel amd nouveau svga"
 PACKAGECONFIG:append:x86-64 = " libclc gallium-llvm intel amd nouveau svga"
diff --git a/meta/recipes-graphics/mesa/mesa.bb b/meta/recipes-graphics/mesa/mesa.bb
index db5eab5fb27c6a7228f6e0fd823514352c42ad1f..49e077b20cd254415c73a30040da76b5d25fd2f3 100644
--- a/meta/recipes-graphics/mesa/mesa.bb
+++ b/meta/recipes-graphics/mesa/mesa.bb
@@ -6,6 +6,7 @@ PACKAGECONFIG = " \
 	${@bb.utils.filter('DISTRO_FEATURES', 'x11 vulkan wayland glvnd', d)} \
 	${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl egl gles gbm virgl', '', d)} \
 	${@bb.utils.contains('DISTRO_FEATURES', 'vulkan', 'zink', '', d)} \
+	xmlconfig \
 "
 
 PACKAGECONFIG:append:x86 = " libclc gallium-llvm intel amd nouveau svga"
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 81b099bf6e5fe624e91e6a780f8bb55854580c2d..4b1c11be55f7b3f54b5244674263b83a8703bc25 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -115,6 +115,7 @@ TOOLS_DEPS:append = "${@bb.utils.contains('PACKAGECONFIG', 'freedreno', ' ncurse
 PACKAGECONFIG[freedreno-fdperf] = ",,libconfig"
 
 PACKAGECONFIG[tools] = "-Dtools=${@strip_comma('${TOOLS}')}, -Dtools='', ${TOOLS_DEPS}"
+PACKAGECONFIG[xmlconfig] = "-Dxmlconfig=enabled, -Dxmlconfig=disabled, expat"
 
 PACKAGECONFIG[opengl] = "-Dopengl=true, -Dopengl=false"
 PACKAGECONFIG[glvnd] = "-Dglvnd=enabled, -Dglvnd=disabled, libglvnd"

-- 
2.50.1

[PATCH v6 10/14] mesa: avoid host paths poisoning

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

At least panfrost and asahi drivers are prone to host paths poisoning
due to unpatched __FILE__ macro in assert() of libcl.

The compilation units for files including this file all are passed
specific arguments via the cl_args meson variable which currently only
contains one fmacro-prefix-map entry for relative paths. However, there
are also absolute build and source paths that seem to make it to the
generated files and libraries so this patches mesa to also strip those
paths.

Note that out of the four paths in the default DEBUG_PREFIX_MAP, only
the source and build directories make it to the fmacro-prefix-map and
they aren't mapped like they are when used with ffile-prefix-map in
DEBUG_PREFIX_MAP as I'm not sure if it is at all possible for meson to
fetch this Yocto-provided path we should be mapping to in the current
mesa code base. I guess this is good enough for now.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 ...01-meson-fix-libcl-assert-reproducibility.patch | 43 ++++++++++++++++++++++
 meta/recipes-graphics/mesa/mesa.inc                |  1 +
 2 files changed, 44 insertions(+)

diff --git a/meta/recipes-graphics/mesa/files/0001-meson-fix-libcl-assert-reproducibility.patch b/meta/recipes-graphics/mesa/files/0001-meson-fix-libcl-assert-reproducibility.patch
new file mode 100644
index 0000000000000000000000000000000000000000..118b52a22714594999f9c8d38a56b47afe4e4e66
--- /dev/null
+++ b/meta/recipes-graphics/mesa/files/0001-meson-fix-libcl-assert-reproducibility.patch
@@ -0,0 +1,43 @@
+From b9d43acde2d2e21d321e57d632cac199e41048ef Mon Sep 17 00:00:00 2001
+From: Quentin Schulz <quentin.schulz@cherry.de>
+Date: Thu, 21 Aug 2025 17:24:08 +0200
+Subject: [PATCH] meson: fix libcl assert() reproducibility
+
+The current -fmacro-prefix-map only handles removal of relative paths
+but we still need to handle absolute paths.
+
+The following path can be found in libvulkan_panfrost.so when building
+with Yocto for example:
+/work/build/tmp/work/cortexa76-cortexa55-crypto-poky-linux/mesa/25.2.0/sources/mesa-25.2.0/src/panfrost/libpan/../../util/bitpack_helpers.h
+
+These paths currently seem to only appear in the binary in strings that
+start with "Shader assertion fail at " which seems to indicate there are
+calls to assert() with absolute paths as well as relative paths (which
+are already patched with fmacro-prefix-map).
+
+By stripping the global source and build root directories from the paths
+with -fmacro-prefix-map, we get rid of this reproducibility issue (which
+incidentally makes the build fail due to buildpaths QA issue).
+
+Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
+
+Upstream-Status: Submitted [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36927]
+
+Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
+---
+ meson.build | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/meson.build b/meson.build
+index 9cc75f6636e..d4779905020 100644
+--- a/meson.build
++++ b/meson.build
+@@ -52,6 +52,8 @@ relative_dir = fs.relative_to(meson.global_source_root(), meson.global_build_roo
+ 
+ cl_args = [
+   '-fmacro-prefix-map=@0@/='.format(relative_dir),
++  '-fmacro-prefix-map=@0@/='.format(meson.global_source_root()),
++  '-fmacro-prefix-map=@0@/='.format(meson.global_build_root()),
+ 
+   # Set the OpenCL standard to CL 2.0, enabling everything at a frontend.
+   # Drivers may not actually support everything but that's ok.
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 4b1c11be55f7b3f54b5244674263b83a8703bc25..beaf99b796f117ab4b7b10bf9c9ea57d65995ddb 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -17,6 +17,7 @@ PE = "2"
 SRC_URI = "https://archive.mesa3d.org/mesa-${PV}.tar.xz \
            file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
            file://0001-freedreno-don-t-encode-build-path-into-binaries.patch \
+           file://0001-meson-fix-libcl-assert-reproducibility.patch \
 "
 
 SRC_URI[sha256sum] = "7c726b21c074d14d31d253d638b741422f3c0a497ce7f1b4aaaa917d10bd8d4f"

-- 
2.50.1

[PATCH v6 11/14] mesa: avoid host path poisoning when enabling OpenCL

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

When enabling rusticl (and the shared-llvm meson feature via the
gallium-llvm PACKAGECONFIG documented dependency), the clc headers are
looked on the filesystem at runtime. Unfortunately, part of the lookup
path contains LLVM_LIB_DIR, a variable derived from llvm_libdir meson
variable. The latter is required to figure out where the clang/llvm
libraries are for the cross-compiler but the former is used when running
on the target. When in a cross-compiling environment, LLVM_LIB_DIR would
actually point at a non-existing path (the sysroot path on the build
host) instead of the target path. This sadly triggers a buildpaths QA
error in addition of being incorrect.

Another option is to bundle the clc headers directly inside the binary
instead of looking them up at runtime, something we can do with
mesa-clc-bundle-headers meson feature.

So let's do that to fix the issue and buildpaths QA error.

Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index beaf99b796f117ab4b7b10bf9c9ea57d65995ddb..54af134c77e90938534db1b0009ec08272f271e0 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -129,7 +129,7 @@ PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
 
 # "opencl" also requires libclc and gallium-llvm to be present in PKGCONFIG!
 # Be sure to enable them both for the target and for the native build.
-PACKAGECONFIG[opencl] = "-Dgallium-rusticl=true, -Dgallium-rusticl=false, bindgen-cli-native"
+PACKAGECONFIG[opencl] = "-Dgallium-rusticl=true -Dmesa-clc-bundle-headers=enabled, -Dgallium-rusticl=false, bindgen-cli-native"
 
 PACKAGECONFIG[broadcom] = ""
 PACKAGECONFIG[etnaviv] = ",,python3-pycparser-native"

-- 
2.50.1

[PATCH v6 12/14] mesa: use simpler mesa-tools-native recipe as dependency for libclc

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

libclc is required for some drivers (asahi, panfrost and intel at the
very least).
libclc brings very expensive dependencies such as llvm and clang.
Building clang and llvm for each target architecture is very expensive,
but mesa allows to depend on prebuilt host binaries (mesa-clc and
precomp-compiler). Those are built by mesa as well, but can be compiled
in mesa-native instead of mesa, making the dependency expensive but only
once regardless of the number of target architectures to build for.
Ideally the mesa-clc and precomp-compiler would only be compiled in
mesa-native if target mesa requires libclc support, however this is not
possible as a target recipe cannot impact or depend on a native recipe's
configuration. We thus have two choices, always build libclc in
mesa-native with its heavy dependencies and impact every build or force
the user to modify the mesa-native recipe in a custom layer (as a native
recipe cannot use target's OVERRIDES). The latter is unacceptable so the
former seems to be the only option. Another big downside is that
mesa-native currently builds drivers (amd, nouveau, svga) which we may
have absolutely no interest in building, increasing the build time and
possibly dependencies list).

A third choice is to spin-off the native mesa recipe with libclc support
into a new recipe without drivers and only what's necessary to build
mesa-clc and precomp-compiler binaries.
This allows to keep a "clean" mesa-native recipe for whoever needs those
drivers built-in (e.g. for testing, for qemu-native, or whatever else)
and only bring the libclc dependency when required by the target recipe.

Because libclc is now only built for the host, opencl support now needs
to explicitly bring libclc and others to build as libclc won't bring it
in the build environment anymore.

Suggested-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa-tools-native.bb | 19 +++++++++++++++++++
 meta/recipes-graphics/mesa/mesa.inc             | 15 ++++-----------
 2 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa-tools-native.bb b/meta/recipes-graphics/mesa/mesa-tools-native.bb
new file mode 100644
index 0000000000000000000000000000000000000000..dab1a037851cca6b33eae4b69a6a141fbbcd801b
--- /dev/null
+++ b/meta/recipes-graphics/mesa/mesa-tools-native.bb
@@ -0,0 +1,19 @@
+require mesa.inc
+inherit native
+
+SUMMARY += " (tools only)"
+
+PACKAGECONFIG = "tools asahi panfrost"
+# llvm required for libclc
+PACKAGECONFIG += "gallium-llvm"
+# Doesn't compile without wayland-scanner if PLATFORMS has wayland in, and,
+# doesn't compile at all if PLATFORMS is empty so add x11 and wayland
+# to PACKAGECONFIG like in mesa.inc
+PACKAGECONFIG += "${@bb.utils.filter('DISTRO_FEATURES', 'x11 wayland', d)}"
+
+DEPENDS += "libclc-native spirv-tools-native spirv-llvm-translator-native"
+
+EXTRA_OEMESON += " \
+    -Dmesa-clc=enabled -Dinstall-mesa-clc=true -Dmesa-clc-bundle-headers=enabled \
+    -Dprecomp-compiler=enabled -Dinstall-precomp-compiler=true \
+"
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 54af134c77e90938534db1b0009ec08272f271e0..b38386977da2a2fa2409afaef036cd2c09a0cdbf 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -127,9 +127,9 @@ PACKAGECONFIG[gles] = "-Dgles1=enabled -Dgles2=enabled, -Dgles1=disabled -Dgles2
 # "egl" requires "opengl"
 PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
 
-# "opencl" also requires libclc and gallium-llvm to be present in PKGCONFIG!
-# Be sure to enable them both for the target and for the native build.
-PACKAGECONFIG[opencl] = "-Dgallium-rusticl=true -Dmesa-clc-bundle-headers=enabled, -Dgallium-rusticl=false, bindgen-cli-native"
+# "opencl" also requires gallium-llvm to be present in PACKAGECONFIG!
+# Be sure to enable it for the target and for the native build.
+PACKAGECONFIG[opencl] = "-Dgallium-rusticl=true -Dmesa-clc-bundle-headers=enabled, -Dgallium-rusticl=false, bindgen-cli-native libclc spirv-tools spirv-llvm-translator"
 
 PACKAGECONFIG[broadcom] = ""
 PACKAGECONFIG[etnaviv] = ",,python3-pycparser-native"
@@ -168,16 +168,9 @@ GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'gallium-llvm', '
 GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'amd', ',r600', '', d)}"
 GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'virgl', ',virgl', '', d)}"
 
-MESA_CLC = "system"
-MESA_CLC:class-native = "enabled"
-INSTALL_MESA_CLC = "false"
-INSTALL_MESA_CLC:class-native = "true"
-MESA_NATIVE = "mesa-native"
-MESA_NATIVE:class-native = ""
-
 PACKAGECONFIG[gallium] = "-Dgallium-drivers=${@strip_comma('${GALLIUMDRIVERS}')}, -Dgallium-drivers='', libdrm"
 PACKAGECONFIG[gallium-llvm] = "-Dllvm=enabled -Dshared-llvm=enabled, -Dllvm=disabled, llvm llvm-native elfutils"
-PACKAGECONFIG[libclc] = "-Dmesa-clc=${MESA_CLC} -Dinstall-mesa-clc=${INSTALL_MESA_CLC} -Dmesa-clc-bundle-headers=enabled,,libclc spirv-tools spirv-llvm-translator ${MESA_NATIVE}"
+PACKAGECONFIG[libclc] = "-Dmesa-clc=system -Dprecomp-compiler=system,,mesa-tools-native"
 PACKAGECONFIG[va] = "-Dgallium-va=enabled,-Dgallium-va=disabled,libva-initial"
 PACKAGECONFIG[vdpau] = "-Dgallium-vdpau=enabled,-Dgallium-vdpau=disabled,libvdpau"
 

-- 
2.50.1

Re: [PATCH v6 12/14] mesa: use simpler mesa-tools-native recipe as dependency for libclc

[Quentin Schulz]

Hi all,

On 8/22/25 2:53 PM, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@cherry.de>
> 
> libclc is required for some drivers (asahi, panfrost and intel at the
> very least).
> libclc brings very expensive dependencies such as llvm and clang.
> Building clang and llvm for each target architecture is very expensive,
> but mesa allows to depend on prebuilt host binaries (mesa-clc and
> precomp-compiler). Those are built by mesa as well, but can be compiled
> in mesa-native instead of mesa, making the dependency expensive but only
> once regardless of the number of target architectures to build for.
> Ideally the mesa-clc and precomp-compiler would only be compiled in
> mesa-native if target mesa requires libclc support, however this is not
> possible as a target recipe cannot impact or depend on a native recipe's
> configuration. We thus have two choices, always build libclc in
> mesa-native with its heavy dependencies and impact every build or force
> the user to modify the mesa-native recipe in a custom layer (as a native
> recipe cannot use target's OVERRIDES). The latter is unacceptable so the
> former seems to be the only option. Another big downside is that
> mesa-native currently builds drivers (amd, nouveau, svga) which we may
> have absolutely no interest in building, increasing the build time and
> possibly dependencies list).
> 
> A third choice is to spin-off the native mesa recipe with libclc support
> into a new recipe without drivers and only what's necessary to build
> mesa-clc and precomp-compiler binaries.
> This allows to keep a "clean" mesa-native recipe for whoever needs those
> drivers built-in (e.g. for testing, for qemu-native, or whatever else)
> and only bring the libclc dependency when required by the target recipe.
> 
> Because libclc is now only built for the host, opencl support now needs
> to explicitly bring libclc and others to build as libclc won't bring it
> in the build environment anymore.
> 
> Suggested-by: Ross Burton <ross.burton@arm.com>
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
>   meta/recipes-graphics/mesa/mesa-tools-native.bb | 19 +++++++++++++++++++
>   meta/recipes-graphics/mesa/mesa.inc             | 15 ++++-----------
>   2 files changed, 23 insertions(+), 11 deletions(-)
> 
> diff --git a/meta/recipes-graphics/mesa/mesa-tools-native.bb b/meta/recipes-graphics/mesa/mesa-tools-native.bb
> new file mode 100644
> index 0000000000000000000000000000000000000000..dab1a037851cca6b33eae4b69a6a141fbbcd801b
> --- /dev/null
> +++ b/meta/recipes-graphics/mesa/mesa-tools-native.bb
> @@ -0,0 +1,19 @@
> +require mesa.inc
> +inherit native

I think I should have inherit_defer native here instead? To make sure 
regardless of what the user does in a bbappend (well aside from using 
another inherit_defer), native is always the last inherited class?

Cheers,
Quentin

[PATCH v6 13/14] mesa: fix panfrost driver build

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

Panfrost drivers require libclc, so let's force libclc to be present in
the PACKAGECONFIG to build the drivers.

Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index b38386977da2a2fa2409afaef036cd2c09a0cdbf..6a586c55363959fa6bc4405f5d810d85ca307bf5 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -95,7 +95,7 @@ VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'freedreno', ',fr
 VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'broadcom', ',broadcom', '', d)}"
 VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'gallium-llvm', '${VULKAN_DRIVERS_LLVM}', '', d)}"
 VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'imagination', ',imagination-experimental', '', d)}"
-VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'panfrost', ',panfrost', '', d)}"
+VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'panfrost libclc', ',panfrost', '', d)}"
 PACKAGECONFIG[vulkan] = "-Dvulkan-drivers=${@strip_comma('${VULKAN_DRIVERS}')}, -Dvulkan-drivers='',glslang-native vulkan-loader vulkan-headers"
 
 # mesa development and testing tools support, per driver
@@ -185,7 +185,7 @@ PACKAGECONFIG[lima] = ""
 GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima', '', d)}"
 
 PACKAGECONFIG[panfrost] = ""
-GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'panfrost', ',panfrost', '', d)}"
+GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'panfrost libclc', ',panfrost', '', d)}"
 
 PACKAGECONFIG[tegra] = ""
 GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'tegra', ',tegra,nouveau', '', d)}"

-- 
2.50.1

[PATCH v6 14/14] mesa: upgrade 25.2.0 -> 25.2.1

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

Changelog and sha256sum: https://docs.mesa3d.org/relnotes/25.2.1.html

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 meta/recipes-graphics/mesa/mesa.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 6a586c55363959fa6bc4405f5d810d85ca307bf5..7d346f2fd1d786c5fa03e6874ed1aee2ba0ad00a 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -20,8 +20,8 @@ SRC_URI = "https://archive.mesa3d.org/mesa-${PV}.tar.xz \
            file://0001-meson-fix-libcl-assert-reproducibility.patch \
 "
 
-SRC_URI[sha256sum] = "7c726b21c074d14d31d253d638b741422f3c0a497ce7f1b4aaaa917d10bd8d4f"
-PV = "25.2.0"
+SRC_URI[sha256sum] = "c124372189d35f48e049ee503029171c68962c580971cb86d968a6771c965ba4"
+PV = "25.2.1"
 
 UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P<pver>\d+(\.\d+)+)"
 

-- 
2.50.1

Re: [PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[Dmitry Baryshkov]

On Fri, Aug 22, 2025 at 02:53:06PM +0200, Quentin Schulz wrote:
> @Otavio, can I add the new mesa-tools-native recipe under your
> maintainership in meta/conf/distro/include/maintainers.inc, it is after
> all still mesa?
> 
> Panfrost support has been broken for a while already because it now
> requires libclc which isn't enforced by default. This fixes this
> oversight.
> 
> While re-adding support for panfrost, the build time for libclc were a
> bit too much to my taste and I tried to figure out if we could lighten
> up the dependencies for the target recipe and it seems to be the case.
> 
> libclc brings very expensive dependencies such as llvm and clang.
> Building clang and llvm for each target architecture is very expensive,
> but mesa allows to depend on prebuilt host binaries (mesa-clc and
> precomp-compiler). Those are built by mesa as well, but can be compiled
> in mesa-native instead of mesa, making the dependency expensive but only
> once regardless of the number of target architectures to build for.
> Ideally the mesa-clc and precomp-compiler would only be compiled in
> mesa-native if target mesa requires libclc support, however this is not
> possible as a target recipe cannot impact or depend on a native recipe's
> configuration. We thus have two choices, always build libclc in
> mesa-native with its heavy dependencies and impact every build or force
> the user to modify the mesa-native recipe in a custom layer (as a native
> recipe cannot use target's OVERRIDES). The latter is unacceptable so the
> former seems to be the only option. Another big downside is that
> mesa-native currently builds drivers (amd, nouveau, svga) which we may
> have absolutely no interest in building, increasing the build time and
> possibly dependencies list).
> 
> A third choice is to spin-off the native mesa recipe with libclc support
> into a new recipe without drivers and only what's necessary to build
> mesa-clc and precomp-compiler binaries.
> This allows to keep a "clean" mesa-native recipe for whoever needs those
> drivers built-in (e.g. for testing, for qemu-native, or whatever else)
> and only bring the libclc dependency when required by the target recipe.
> 
> Because libclc is now only built for the host, opencl support now needs
> to explicitly bring libclc and others to build as libclc won't bring it
> in the build environment anymore.
> 
> Note that this was essentially only build tested (run tested on RK3588
> with panfrost though).
> 
> Note that building gallium-llvm support on big.LITTLE architecture with
> TOOLCHAIN = "gcc" (the default) currently doesn't work as llvm doesn't
> support big.LITTLE architecture in -mcpu/-march which is passed to the
> CFLAGS/CXXFLAGS/LDFLAGS via the TUNE_CCARGS. I haven't investigated
> further than that but that prevents us from building opencl support for
> Rockchip most popular and powerful SoCs right now. One option could be
> to force this recipe to be built with clang toolchain only whenever
> gallium-llvm is specified in PACKAGECONFIG (not tested). Though that may
> be not straightforward seeing the comment in libclc recipe related to
> forcing the toolchain to clang.
> I'm also not sure mesa has a way to specify different args to LLVM-only
> drivers but that could be another option.
> 
> Runtime tested on RK3588 and PX30 with kmscube.
> Partially runtime tested on PX30 with opencl-cts (and rusticl; it fails
> after some time but could be kernel related as it starts failing after
> [  968.625506] panfrost ff400000.gpu: gpu sched timeout, js=1, config=0x7b00, status=0x8, head=0xa68d200, tail=0xa68d200, sched_job=0000000019e6f20d
> 
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>


Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>



-- 
With best wishes
Dmitry

Re: [OE-core] [PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[Mathieu Dubois-Briand]

On Fri Aug 22, 2025 at 2:53 PM CEST, Quentin Schulz wrote:
> @Otavio, can I add the new mesa-tools-native recipe under your
> maintainership in meta/conf/distro/include/maintainers.inc, it is after
> all still mesa?
>
> Panfrost support has been broken for a while already because it now
> requires libclc which isn't enforced by default. This fixes this
> oversight.
>
> While re-adding support for panfrost, the build time for libclc were a
> bit too much to my taste and I tried to figure out if we could lighten
> up the dependencies for the target recipe and it seems to be the case.
>
> libclc brings very expensive dependencies such as llvm and clang.
> Building clang and llvm for each target architecture is very expensive,
> but mesa allows to depend on prebuilt host binaries (mesa-clc and
> precomp-compiler). Those are built by mesa as well, but can be compiled
> in mesa-native instead of mesa, making the dependency expensive but only
> once regardless of the number of target architectures to build for.
> Ideally the mesa-clc and precomp-compiler would only be compiled in
> mesa-native if target mesa requires libclc support, however this is not
> possible as a target recipe cannot impact or depend on a native recipe's
> configuration. We thus have two choices, always build libclc in
> mesa-native with its heavy dependencies and impact every build or force
> the user to modify the mesa-native recipe in a custom layer (as a native
> recipe cannot use target's OVERRIDES). The latter is unacceptable so the
> former seems to be the only option. Another big downside is that
> mesa-native currently builds drivers (amd, nouveau, svga) which we may
> have absolutely no interest in building, increasing the build time and
> possibly dependencies list).
>
> A third choice is to spin-off the native mesa recipe with libclc support
> into a new recipe without drivers and only what's necessary to build
> mesa-clc and precomp-compiler binaries.
> This allows to keep a "clean" mesa-native recipe for whoever needs those
> drivers built-in (e.g. for testing, for qemu-native, or whatever else)
> and only bring the libclc dependency when required by the target recipe.
>
> Because libclc is now only built for the host, opencl support now needs
> to explicitly bring libclc and others to build as libclc won't bring it
> in the build environment anymore.
>
> Note that this was essentially only build tested (run tested on RK3588
> with panfrost though).
>
> Note that building gallium-llvm support on big.LITTLE architecture with
> TOOLCHAIN = "gcc" (the default) currently doesn't work as llvm doesn't
> support big.LITTLE architecture in -mcpu/-march which is passed to the
> CFLAGS/CXXFLAGS/LDFLAGS via the TUNE_CCARGS. I haven't investigated
> further than that but that prevents us from building opencl support for
> Rockchip most popular and powerful SoCs right now. One option could be
> to force this recipe to be built with clang toolchain only whenever
> gallium-llvm is specified in PACKAGECONFIG (not tested). Though that may
> be not straightforward seeing the comment in libclc recipe related to
> forcing the toolchain to clang.
> I'm also not sure mesa has a way to specify different args to LLVM-only
> drivers but that could be another option.
>
> Runtime tested on RK3588 and PX30 with kmscube.
> Partially runtime tested on PX30 with opencl-cts (and rusticl; it fails
> after some time but could be kernel related as it starts failing after
> [  968.625506] panfrost ff400000.gpu: gpu sched timeout, js=1, config=0x7b00, status=0x8, head=0xa68d200, tail=0xa68d200, sched_job=0000000019e6f20d
>
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---

Hi Quentin,

Thanks for the new version.

It looks like we have a build issue for riscv platforms:

ERROR: mesa-tools-native-2_25.2.1-r0 do_prepare_recipe_sysroot: The sstate manifest for task 'expat:populate_sysroot' (multilib variant '') could not be found.
The pkgarchs considered were: qemuriscv64, allarch, x86_64_x86_64-nativesdk.
But none of these manifests exists:
    /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-qemuriscv64-expat.populate_sysroot
    /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-allarch-expat.populate_sysroot
    /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-expat.populate_sysroot

https://autobuilder.yoctoproject.org/valkyrie/#/builders/45/builds/379
https://autobuilder.yoctoproject.org/valkyrie/#/builders/56/builds/396
https://autobuilder.yoctoproject.org/valkyrie/#/builders/58/builds/362

Can you have a look at these, please?

Best regards,
Mathieu

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[Mathieu Dubois-Briand]

On Sat Aug 23, 2025 at 8:01 PM CEST, Mathieu Dubois-Briand wrote:
> Hi Quentin,
>
> Thanks for the new version.
>
> It looks like we have a build issue for riscv platforms:
>
> ERROR: mesa-tools-native-2_25.2.1-r0 do_prepare_recipe_sysroot: The sstate manifest for task 'expat:populate_sysroot' (multilib variant '') could not be found.
> The pkgarchs considered were: qemuriscv64, allarch, x86_64_x86_64-nativesdk.
> But none of these manifests exists:
>     /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-qemuriscv64-expat.populate_sysroot
>     /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-allarch-expat.populate_sysroot
>     /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-expat.populate_sysroot
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/45/builds/379
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/56/builds/396
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/58/builds/362
>
> Can you have a look at these, please?
>
> Best regards,
> Mathieu

Hi Quentin,

Some selftests are also failing:

2025-08-23 17:05:10,234 - oe-selftest - INFO - baremetal.BaremetalTest.test_baremetal (subunit.RemotedTestCase)
2025-08-23 17:05:10,236 - oe-selftest - INFO -  ... FAIL
...
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'ldconfig' (but /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/meta/recipes-devtools/dpkg/dpkg_1.22.21.bb RDEPENDS on or otherwise requires it)
nativesdk-glibc-testsuite RPROVIDES ldconfig but was skipped: glibc-testsuite requires that virtual/libc is glibc
glibc-testsuite RPROVIDES ldconfig but was skipped: glibc-testsuite requires that virtual/libc is glibc
glibc RPROVIDES ldconfig but was skipped: PREFERRED_PROVIDER_virtual/libc set to musl, not glibc

https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/2353
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/2204
https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/2135

Best regards,
Mathieu

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[Quentin Schulz]

Hi Mathieu, all,

On 8/23/25 8:01 PM, Mathieu Dubois-Briand wrote:
> On Fri Aug 22, 2025 at 2:53 PM CEST, Quentin Schulz wrote:
>> @Otavio, can I add the new mesa-tools-native recipe under your
>> maintainership in meta/conf/distro/include/maintainers.inc, it is after
>> all still mesa?
>>
>> Panfrost support has been broken for a while already because it now
>> requires libclc which isn't enforced by default. This fixes this
>> oversight.
>>
>> While re-adding support for panfrost, the build time for libclc were a
>> bit too much to my taste and I tried to figure out if we could lighten
>> up the dependencies for the target recipe and it seems to be the case.
>>
>> libclc brings very expensive dependencies such as llvm and clang.
>> Building clang and llvm for each target architecture is very expensive,
>> but mesa allows to depend on prebuilt host binaries (mesa-clc and
>> precomp-compiler). Those are built by mesa as well, but can be compiled
>> in mesa-native instead of mesa, making the dependency expensive but only
>> once regardless of the number of target architectures to build for.
>> Ideally the mesa-clc and precomp-compiler would only be compiled in
>> mesa-native if target mesa requires libclc support, however this is not
>> possible as a target recipe cannot impact or depend on a native recipe's
>> configuration. We thus have two choices, always build libclc in
>> mesa-native with its heavy dependencies and impact every build or force
>> the user to modify the mesa-native recipe in a custom layer (as a native
>> recipe cannot use target's OVERRIDES). The latter is unacceptable so the
>> former seems to be the only option. Another big downside is that
>> mesa-native currently builds drivers (amd, nouveau, svga) which we may
>> have absolutely no interest in building, increasing the build time and
>> possibly dependencies list).
>>
>> A third choice is to spin-off the native mesa recipe with libclc support
>> into a new recipe without drivers and only what's necessary to build
>> mesa-clc and precomp-compiler binaries.
>> This allows to keep a "clean" mesa-native recipe for whoever needs those
>> drivers built-in (e.g. for testing, for qemu-native, or whatever else)
>> and only bring the libclc dependency when required by the target recipe.
>>
>> Because libclc is now only built for the host, opencl support now needs
>> to explicitly bring libclc and others to build as libclc won't bring it
>> in the build environment anymore.
>>
>> Note that this was essentially only build tested (run tested on RK3588
>> with panfrost though).
>>
>> Note that building gallium-llvm support on big.LITTLE architecture with
>> TOOLCHAIN = "gcc" (the default) currently doesn't work as llvm doesn't
>> support big.LITTLE architecture in -mcpu/-march which is passed to the
>> CFLAGS/CXXFLAGS/LDFLAGS via the TUNE_CCARGS. I haven't investigated
>> further than that but that prevents us from building opencl support for
>> Rockchip most popular and powerful SoCs right now. One option could be
>> to force this recipe to be built with clang toolchain only whenever
>> gallium-llvm is specified in PACKAGECONFIG (not tested). Though that may
>> be not straightforward seeing the comment in libclc recipe related to
>> forcing the toolchain to clang.
>> I'm also not sure mesa has a way to specify different args to LLVM-only
>> drivers but that could be another option.
>>
>> Runtime tested on RK3588 and PX30 with kmscube.
>> Partially runtime tested on PX30 with opencl-cts (and rusticl; it fails
>> after some time but could be kernel related as it starts failing after
>> [  968.625506] panfrost ff400000.gpu: gpu sched timeout, js=1, config=0x7b00, status=0x8, head=0xa68d200, tail=0xa68d200, sched_job=0000000019e6f20d
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>> ---
> 
> Hi Quentin,
> 
> Thanks for the new version.
> 
> It looks like we have a build issue for riscv platforms:
> 
> ERROR: mesa-tools-native-2_25.2.1-r0 do_prepare_recipe_sysroot: The sstate manifest for task 'expat:populate_sysroot' (multilib variant '') could not be found.
> The pkgarchs considered were: qemuriscv64, allarch, x86_64_x86_64-nativesdk.
> But none of these manifests exists:
>      /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-qemuriscv64-expat.populate_sysroot
>      /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-allarch-expat.populate_sysroot
>      /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-expat.populate_sysroot
> 
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/45/builds/379
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/56/builds/396
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/58/builds/362
> 
> Can you have a look at these, please?
> 

Ok so I believe this is because mesa-tools-native uses a different 
mechanism from other mesa recipes to be a native recipe.

mesa-tools-native inherits native + -native in the recipe filename. 
mesa-gl/mesa simply adds native to BBCLASSEXTEND.

The issue I believe is that mesa.inc has a DEPENDS with expat (and zlib) 
in it. In the case of BBCLASSEXTEND, non-native dependencies are 
suffixed with -native to be native when building the native recipe. But 
in the case of inherit native + -native in filename, it doesn't.

To validate this, I did a simple

DEPENDS:remove = "expat zlib"
DEPENDS += "expat-native zlib-native"

and compiling mesa-tools-native on qemurisc64 then worked just fine.

For a quick and dirty fix, I can simply parse DEPENDS for non-native 
packages and just add the -native suffix, but it feels very wrong.

I remembered that PACKAGECONFIG can also bring dependencies to DEPENDS 
if selected and those have a mix of native and non-native dependencies. 
Turns out, those automatically get -native appended though! (via the 
anonymous python in base.bbclass:529).
So I'm wondering if we shouldn't "just" fix the DEPENDS not adding 
-native suffix when building for the native variant even when there only 
exists a native variant of the recipe?

Otherwise I started to look into making mesa-tools a target+native 
recipe to match the other mesa recipes but then I hit a dependency loop 
for some reason (and also, there already exists a mesa-tools package 
generated by the mesa-gl/mesa target recipe, so that may make things 
more confusing as well. I guess I could call it mesa-tools-only or 
something like that, this doesn't break the dependency loop though).

Any preference on how to go forward with this?

Cheers,
Quentin

Re: [OE-core] [PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[Quentin Schulz]

On 9/1/25 4:51 PM, Quentin Schulz via lists.openembedded.org wrote:
> Hi Mathieu, all,
> 
> On 8/23/25 8:01 PM, Mathieu Dubois-Briand wrote:
>> On Fri Aug 22, 2025 at 2:53 PM CEST, Quentin Schulz wrote:
>>> @Otavio, can I add the new mesa-tools-native recipe under your
>>> maintainership in meta/conf/distro/include/maintainers.inc, it is after
>>> all still mesa?
>>>
>>> Panfrost support has been broken for a while already because it now
>>> requires libclc which isn't enforced by default. This fixes this
>>> oversight.
>>>
>>> While re-adding support for panfrost, the build time for libclc were a
>>> bit too much to my taste and I tried to figure out if we could lighten
>>> up the dependencies for the target recipe and it seems to be the case.
>>>
>>> libclc brings very expensive dependencies such as llvm and clang.
>>> Building clang and llvm for each target architecture is very expensive,
>>> but mesa allows to depend on prebuilt host binaries (mesa-clc and
>>> precomp-compiler). Those are built by mesa as well, but can be compiled
>>> in mesa-native instead of mesa, making the dependency expensive but only
>>> once regardless of the number of target architectures to build for.
>>> Ideally the mesa-clc and precomp-compiler would only be compiled in
>>> mesa-native if target mesa requires libclc support, however this is not
>>> possible as a target recipe cannot impact or depend on a native recipe's
>>> configuration. We thus have two choices, always build libclc in
>>> mesa-native with its heavy dependencies and impact every build or force
>>> the user to modify the mesa-native recipe in a custom layer (as a native
>>> recipe cannot use target's OVERRIDES). The latter is unacceptable so the
>>> former seems to be the only option. Another big downside is that
>>> mesa-native currently builds drivers (amd, nouveau, svga) which we may
>>> have absolutely no interest in building, increasing the build time and
>>> possibly dependencies list).
>>>
>>> A third choice is to spin-off the native mesa recipe with libclc support
>>> into a new recipe without drivers and only what's necessary to build
>>> mesa-clc and precomp-compiler binaries.
>>> This allows to keep a "clean" mesa-native recipe for whoever needs those
>>> drivers built-in (e.g. for testing, for qemu-native, or whatever else)
>>> and only bring the libclc dependency when required by the target recipe.
>>>
>>> Because libclc is now only built for the host, opencl support now needs
>>> to explicitly bring libclc and others to build as libclc won't bring it
>>> in the build environment anymore.
>>>
>>> Note that this was essentially only build tested (run tested on RK3588
>>> with panfrost though).
>>>
>>> Note that building gallium-llvm support on big.LITTLE architecture with
>>> TOOLCHAIN = "gcc" (the default) currently doesn't work as llvm doesn't
>>> support big.LITTLE architecture in -mcpu/-march which is passed to the
>>> CFLAGS/CXXFLAGS/LDFLAGS via the TUNE_CCARGS. I haven't investigated
>>> further than that but that prevents us from building opencl support for
>>> Rockchip most popular and powerful SoCs right now. One option could be
>>> to force this recipe to be built with clang toolchain only whenever
>>> gallium-llvm is specified in PACKAGECONFIG (not tested). Though that may
>>> be not straightforward seeing the comment in libclc recipe related to
>>> forcing the toolchain to clang.
>>> I'm also not sure mesa has a way to specify different args to LLVM-only
>>> drivers but that could be another option.
>>>
>>> Runtime tested on RK3588 and PX30 with kmscube.
>>> Partially runtime tested on PX30 with opencl-cts (and rusticl; it fails
>>> after some time but could be kernel related as it starts failing after
>>> [  968.625506] panfrost ff400000.gpu: gpu sched timeout, js=1, 
>>> config=0x7b00, status=0x8, head=0xa68d200, tail=0xa68d200, 
>>> sched_job=0000000019e6f20d
>>>
>>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>>> ---
>>
>> Hi Quentin,
>>
>> Thanks for the new version.
>>
>> It looks like we have a build issue for riscv platforms:
>>
>> ERROR: mesa-tools-native-2_25.2.1-r0 do_prepare_recipe_sysroot: The 
>> sstate manifest for task 'expat:populate_sysroot' (multilib variant 
>> '') could not be found.
>> The pkgarchs considered were: qemuriscv64, allarch, x86_64_x86_64- 
>> nativesdk.
>> But none of these manifests exists:
>>      /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate- 
>> control/manifest-qemuriscv64-expat.populate_sysroot
>>      /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate- 
>> control/manifest-allarch-expat.populate_sysroot
>>      /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate- 
>> control/manifest-x86_64_x86_64-nativesdk-expat.populate_sysroot
>>
>> https://eur02.safelinks.protection.outlook.com/? 
>> url=https%3A%2F%2Fautobuilder.yoctoproject.org%2Fvalkyrie%2F%23%2Fbuilders%2F45%2Fbuilds%2F379&data=05%7C02%7Cquentin.schulz%40cherry.de%7C0c66831ac5ba49c1d25908dde9671d66%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638923351293360001%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ao0lx3qCzc7c7LM8aBbFgzKhgDOTldZQq%2Fv9GLbKhQY%3D&reserved=0
>> https://eur02.safelinks.protection.outlook.com/? 
>> url=https%3A%2F%2Fautobuilder.yoctoproject.org%2Fvalkyrie%2F%23%2Fbuilders%2F56%2Fbuilds%2F396&data=05%7C02%7Cquentin.schulz%40cherry.de%7C0c66831ac5ba49c1d25908dde9671d66%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638923351293391687%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yxdpkunuYbmZehHivrJxHkqCZwPSfiT2m4xVnm27oUA%3D&reserved=0
>> https://eur02.safelinks.protection.outlook.com/? 
>> url=https%3A%2F%2Fautobuilder.yoctoproject.org%2Fvalkyrie%2F%23%2Fbuilders%2F58%2Fbuilds%2F362&data=05%7C02%7Cquentin.schulz%40cherry.de%7C0c66831ac5ba49c1d25908dde9671d66%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638923351293414274%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dCx1ZUeLnMbcG9w4Rs4PcazKrfhWh7U88Vu4k1Lzjnk%3D&reserved=0
>>
>> Can you have a look at these, please?
>>
> 
> Ok so I believe this is because mesa-tools-native uses a different 
> mechanism from other mesa recipes to be a native recipe.
> 
> mesa-tools-native inherits native + -native in the recipe filename. 
> mesa-gl/mesa simply adds native to BBCLASSEXTEND.
> 
> The issue I believe is that mesa.inc has a DEPENDS with expat (and zlib) 
> in it. In the case of BBCLASSEXTEND, non-native dependencies are 
> suffixed with -native to be native when building the native recipe. But 
> in the case of inherit native + -native in filename, it doesn't.
> 
> To validate this, I did a simple
> 
> DEPENDS:remove = "expat zlib"
> DEPENDS += "expat-native zlib-native"
> 
> and compiling mesa-tools-native on qemurisc64 then worked just fine.
> 
> For a quick and dirty fix, I can simply parse DEPENDS for non-native 
> packages and just add the -native suffix, but it feels very wrong.
> 
> I remembered that PACKAGECONFIG can also bring dependencies to DEPENDS 
> if selected and those have a mix of native and non-native dependencies. 
> Turns out, those automatically get -native appended though! (via the 
> anonymous python in base.bbclass:529).
> So I'm wondering if we shouldn't "just" fix the DEPENDS not adding - 
> native suffix when building for the native variant even when there only 
> exists a native variant of the recipe?
> 
> Otherwise I started to look into making mesa-tools a target+native 
> recipe to match the other mesa recipes but then I hit a dependency loop 
> for some reason (and also, there already exists a mesa-tools package 
> generated by the mesa-gl/mesa target recipe, so that may make things 
> more confusing as well. I guess I could call it mesa-tools-only or 
> something like that, this doesn't break the dependency loop though).
> 
> Any preference on how to go forward with this?
> 

Discussing with Ross on private IRC chat, another option could be to 
postpone patch 12 and merge the rest as they should work just fine like 
that. Patch 12 is a build optimization to avoid building panfrost/asahi 
drivers in mesa-native to be able to build panfrost/asahi mesa target 
drivers with precomp-compilers enabled (which are enabled via 
panfrost/asahi tools in mesa-tools-native), as well as only having 
libclc dependency on the host and not requiring libclc PACKAGECONFIG to 
be present in both mesa-native and mesa target recipes.

I have some unrelated clean up for mesa waiting locally as well, so 
reducing the amount of patches I have to carry and rebase would be nice 
:) (especially since there's a mesa recipe upgrade we probably want to 
have as soon as possible).

Let me know what you prefer on how to handle the issue reported in the 
previous mail and the partial/full merge of this series.

Thanks!
Quentin

Re: [OE-core] [PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[Mathieu Dubois-Briand]

On Mon Sep 1, 2025 at 5:16 PM CEST, Quentin Schulz via lists.openembedded.org wrote:
> Discussing with Ross on private IRC chat, another option could be to 
> postpone patch 12 and merge the rest as they should work just fine like 
> that. Patch 12 is a build optimization to avoid building panfrost/asahi 
> drivers in mesa-native to be able to build panfrost/asahi mesa target 
> drivers with precomp-compilers enabled (which are enabled via 
> panfrost/asahi tools in mesa-tools-native), as well as only having 
> libclc dependency on the host and not requiring libclc PACKAGECONFIG to 
> be present in both mesa-native and mesa target recipes.
>

Hi Quentin,

I just want to confirm, this series builds successfully on the
autobuilder after dropping patch 12.

Thanks,
Mathieu

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[Quentin Schulz]

Hi Mathieu,

On 9/4/25 8:09 AM, Mathieu Dubois-Briand wrote:
> On Mon Sep 1, 2025 at 5:16 PM CEST, Quentin Schulz via lists.openembedded.org wrote:
>> Discussing with Ross on private IRC chat, another option could be to
>> postpone patch 12 and merge the rest as they should work just fine like
>> that. Patch 12 is a build optimization to avoid building panfrost/asahi
>> drivers in mesa-native to be able to build panfrost/asahi mesa target
>> drivers with precomp-compilers enabled (which are enabled via
>> panfrost/asahi tools in mesa-tools-native), as well as only having
>> libclc dependency on the host and not requiring libclc PACKAGECONFIG to
>> be present in both mesa-native and mesa target recipes.
>>
> 
> Hi Quentin,
> 
> I just want to confirm, this series builds successfully on the
> autobuilder after dropping patch 12.
> 

Thanks, I guess I'll split this into two series to avoid holding off 
updates and cleanups then.

There's a 25.2.2 release that got out meanwhile so I'll respin this for 
a v7 when I have time.

Cheers,
Quentin

Re: [OE-core] [PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[Dmitry Baryshkov]

On Mon, Sep 01, 2025 at 04:51:49PM +0200, Quentin Schulz wrote:
> Hi Mathieu, all,
> 
> On 8/23/25 8:01 PM, Mathieu Dubois-Briand wrote:
> > On Fri Aug 22, 2025 at 2:53 PM CEST, Quentin Schulz wrote:
> > > @Otavio, can I add the new mesa-tools-native recipe under your
> > > maintainership in meta/conf/distro/include/maintainers.inc, it is after
> > > all still mesa?
> > > 
> > > Panfrost support has been broken for a while already because it now
> > > requires libclc which isn't enforced by default. This fixes this
> > > oversight.
> > > 
> > > While re-adding support for panfrost, the build time for libclc were a
> > > bit too much to my taste and I tried to figure out if we could lighten
> > > up the dependencies for the target recipe and it seems to be the case.
> > > 
> > > libclc brings very expensive dependencies such as llvm and clang.
> > > Building clang and llvm for each target architecture is very expensive,
> > > but mesa allows to depend on prebuilt host binaries (mesa-clc and
> > > precomp-compiler). Those are built by mesa as well, but can be compiled
> > > in mesa-native instead of mesa, making the dependency expensive but only
> > > once regardless of the number of target architectures to build for.
> > > Ideally the mesa-clc and precomp-compiler would only be compiled in
> > > mesa-native if target mesa requires libclc support, however this is not
> > > possible as a target recipe cannot impact or depend on a native recipe's
> > > configuration. We thus have two choices, always build libclc in
> > > mesa-native with its heavy dependencies and impact every build or force
> > > the user to modify the mesa-native recipe in a custom layer (as a native
> > > recipe cannot use target's OVERRIDES). The latter is unacceptable so the
> > > former seems to be the only option. Another big downside is that
> > > mesa-native currently builds drivers (amd, nouveau, svga) which we may
> > > have absolutely no interest in building, increasing the build time and
> > > possibly dependencies list).
> > > 
> > > A third choice is to spin-off the native mesa recipe with libclc support
> > > into a new recipe without drivers and only what's necessary to build
> > > mesa-clc and precomp-compiler binaries.
> > > This allows to keep a "clean" mesa-native recipe for whoever needs those
> > > drivers built-in (e.g. for testing, for qemu-native, or whatever else)
> > > and only bring the libclc dependency when required by the target recipe.
> > > 
> > > Because libclc is now only built for the host, opencl support now needs
> > > to explicitly bring libclc and others to build as libclc won't bring it
> > > in the build environment anymore.
> > > 
> > > Note that this was essentially only build tested (run tested on RK3588
> > > with panfrost though).
> > > 
> > > Note that building gallium-llvm support on big.LITTLE architecture with
> > > TOOLCHAIN = "gcc" (the default) currently doesn't work as llvm doesn't
> > > support big.LITTLE architecture in -mcpu/-march which is passed to the
> > > CFLAGS/CXXFLAGS/LDFLAGS via the TUNE_CCARGS. I haven't investigated
> > > further than that but that prevents us from building opencl support for
> > > Rockchip most popular and powerful SoCs right now. One option could be
> > > to force this recipe to be built with clang toolchain only whenever
> > > gallium-llvm is specified in PACKAGECONFIG (not tested). Though that may
> > > be not straightforward seeing the comment in libclc recipe related to
> > > forcing the toolchain to clang.
> > > I'm also not sure mesa has a way to specify different args to LLVM-only
> > > drivers but that could be another option.
> > > 
> > > Runtime tested on RK3588 and PX30 with kmscube.
> > > Partially runtime tested on PX30 with opencl-cts (and rusticl; it fails
> > > after some time but could be kernel related as it starts failing after
> > > [  968.625506] panfrost ff400000.gpu: gpu sched timeout, js=1, config=0x7b00, status=0x8, head=0xa68d200, tail=0xa68d200, sched_job=0000000019e6f20d
> > > 
> > > Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> > > ---
> > 
> > Hi Quentin,
> > 
> > Thanks for the new version.
> > 
> > It looks like we have a build issue for riscv platforms:
> > 
> > ERROR: mesa-tools-native-2_25.2.1-r0 do_prepare_recipe_sysroot: The sstate manifest for task 'expat:populate_sysroot' (multilib variant '') could not be found.
> > The pkgarchs considered were: qemuriscv64, allarch, x86_64_x86_64-nativesdk.
> > But none of these manifests exists:
> >      /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-qemuriscv64-expat.populate_sysroot
> >      /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-allarch-expat.populate_sysroot
> >      /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-expat.populate_sysroot
> > 
> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/45/builds/379
> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/56/builds/396
> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/58/builds/362
> > 
> > Can you have a look at these, please?
> > 
> 
> Ok so I believe this is because mesa-tools-native uses a different mechanism
> from other mesa recipes to be a native recipe.
> 
> mesa-tools-native inherits native + -native in the recipe filename.
> mesa-gl/mesa simply adds native to BBCLASSEXTEND.
> 
> The issue I believe is that mesa.inc has a DEPENDS with expat (and zlib) in
> it. In the case of BBCLASSEXTEND, non-native dependencies are suffixed with
> -native to be native when building the native recipe. But in the case of
> inherit native + -native in filename, it doesn't.
> 
> To validate this, I did a simple
> 
> DEPENDS:remove = "expat zlib"
> DEPENDS += "expat-native zlib-native"

I took a glance. I think it would be more idiomatic to write something
like:

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index ddcf3b774a37..5a303538d7be 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -41,7 +41,10 @@ do_install:append() {
   fi
 }

-DEPENDS = "expat makedepend-native flex-native bison-native libxml2-native zlib chrpath-replacement-native python3-mako-native gettext-native python3-pyyaml-native"
+DEPENDS = "makedepend-native flex-native bison-native libxml2-native chrpath-replacement-native python3-mako-native gettext-native python3-pyyaml-native"
+DEPENDS:append:class-target = " expat zlib"
+DEPENDS:append:class-native = " expat-native zlib-native"
+DEPENDS:append:class-nativesdk = " nativesdk-expat nativesdk-zlib"
 EXTRANATIVEPATH += "chrpath-native"

 inherit meson pkgconfig python3native gettext features_check rust


> 
> and compiling mesa-tools-native on qemurisc64 then worked just fine.
> 

-- 
With best wishes
Dmitry

RE: [OE-core] [PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Dmitry Baryshkov via lists.openembedded.org
> Sent: den 21 september 2025 03:49
> To: Quentin Schulz <quentin.schulz@cherry.de>
> Cc: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>; Quentin Schulz <foss@0leil.net>; openembedded-core@lists.openembedded.org; Markus Volk <f_l_k@t-online.de>; Trevor Woerner <twoerner@gmail.com>; Ross Burton <ross.burton@arm.com>; Otavio Salvador <otavio.salvador@ossystems.com.br>; Khem Raj <raj.khem@gmail.com>
> Subject: Re: [OE-core] [PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support
> 
> On Mon, Sep 01, 2025 at 04:51:49PM +0200, Quentin Schulz wrote:
> > Hi Mathieu, all,
> >
> > On 8/23/25 8:01 PM, Mathieu Dubois-Briand wrote:
> > > On Fri Aug 22, 2025 at 2:53 PM CEST, Quentin Schulz wrote:
> > > > @Otavio, can I add the new mesa-tools-native recipe under your
> > > > maintainership in meta/conf/distro/include/maintainers.inc, it is after
> > > > all still mesa?
> > > >
> > > > Panfrost support has been broken for a while already because it now
> > > > requires libclc which isn't enforced by default. This fixes this
> > > > oversight.
> > > >
> > > > While re-adding support for panfrost, the build time for libclc were a
> > > > bit too much to my taste and I tried to figure out if we could lighten
> > > > up the dependencies for the target recipe and it seems to be the case.
> > > >
> > > > libclc brings very expensive dependencies such as llvm and clang.
> > > > Building clang and llvm for each target architecture is very expensive,
> > > > but mesa allows to depend on prebuilt host binaries (mesa-clc and
> > > > precomp-compiler). Those are built by mesa as well, but can be compiled
> > > > in mesa-native instead of mesa, making the dependency expensive but only
> > > > once regardless of the number of target architectures to build for.
> > > > Ideally the mesa-clc and precomp-compiler would only be compiled in
> > > > mesa-native if target mesa requires libclc support, however this is not
> > > > possible as a target recipe cannot impact or depend on a native recipe's
> > > > configuration. We thus have two choices, always build libclc in
> > > > mesa-native with its heavy dependencies and impact every build or force
> > > > the user to modify the mesa-native recipe in a custom layer (as a native
> > > > recipe cannot use target's OVERRIDES). The latter is unacceptable so the
> > > > former seems to be the only option. Another big downside is that
> > > > mesa-native currently builds drivers (amd, nouveau, svga) which we may
> > > > have absolutely no interest in building, increasing the build time and
> > > > possibly dependencies list).
> > > >
> > > > A third choice is to spin-off the native mesa recipe with libclc support
> > > > into a new recipe without drivers and only what's necessary to build
> > > > mesa-clc and precomp-compiler binaries.
> > > > This allows to keep a "clean" mesa-native recipe for whoever needs those
> > > > drivers built-in (e.g. for testing, for qemu-native, or whatever else)
> > > > and only bring the libclc dependency when required by the target recipe.
> > > >
> > > > Because libclc is now only built for the host, opencl support now needs
> > > > to explicitly bring libclc and others to build as libclc won't bring it
> > > > in the build environment anymore.
> > > >
> > > > Note that this was essentially only build tested (run tested on RK3588
> > > > with panfrost though).
> > > >
> > > > Note that building gallium-llvm support on big.LITTLE architecture with
> > > > TOOLCHAIN = "gcc" (the default) currently doesn't work as llvm doesn't
> > > > support big.LITTLE architecture in -mcpu/-march which is passed to the
> > > > CFLAGS/CXXFLAGS/LDFLAGS via the TUNE_CCARGS. I haven't investigated
> > > > further than that but that prevents us from building opencl support for
> > > > Rockchip most popular and powerful SoCs right now. One option could be
> > > > to force this recipe to be built with clang toolchain only whenever
> > > > gallium-llvm is specified in PACKAGECONFIG (not tested). Though that may
> > > > be not straightforward seeing the comment in libclc recipe related to
> > > > forcing the toolchain to clang.
> > > > I'm also not sure mesa has a way to specify different args to LLVM-only
> > > > drivers but that could be another option.
> > > >
> > > > Runtime tested on RK3588 and PX30 with kmscube.
> > > > Partially runtime tested on PX30 with opencl-cts (and rusticl; it fails
> > > > after some time but could be kernel related as it starts failing after
> > > > [  968.625506] panfrost ff400000.gpu: gpu sched timeout, js=1, config=0x7b00, status=0x8, head=0xa68d200, tail=0xa68d200, sched_job=0000000019e6f20d
> > > >
> > > > Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> > > > ---
> > >
> > > Hi Quentin,
> > >
> > > Thanks for the new version.
> > >
> > > It looks like we have a build issue for riscv platforms:
> > >
> > > ERROR: mesa-tools-native-2_25.2.1-r0 do_prepare_recipe_sysroot: The sstate manifest for task 'expat:populate_sysroot' (multilib variant '') could not be found.
> > > The pkgarchs considered were: qemuriscv64, allarch, x86_64_x86_64-nativesdk.
> > > But none of these manifests exists:
> > >      /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-qemuriscv64-expat.populate_sysroot
> > >      /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-allarch-expat.populate_sysroot
> > >      /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-expat.populate_sysroot
> > >
> > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/45/builds/379
> > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/56/builds/396
> > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/58/builds/362
> > >
> > > Can you have a look at these, please?
> > >
> >
> > Ok so I believe this is because mesa-tools-native uses a different mechanism
> > from other mesa recipes to be a native recipe.
> >
> > mesa-tools-native inherits native + -native in the recipe filename.
> > mesa-gl/mesa simply adds native to BBCLASSEXTEND.
> >
> > The issue I believe is that mesa.inc has a DEPENDS with expat (and zlib) in
> > it. In the case of BBCLASSEXTEND, non-native dependencies are suffixed with
> > -native to be native when building the native recipe. But in the case of
> > inherit native + -native in filename, it doesn't.
> >
> > To validate this, I did a simple
> >
> > DEPENDS:remove = "expat zlib"
> > DEPENDS += "expat-native zlib-native"
> 
> I took a glance. I think it would be more idiomatic to write something
> like:
> 
> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-
> graphics/mesa/mesa.inc
> index ddcf3b774a37..5a303538d7be 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -41,7 +41,10 @@ do_install:append() {
>    fi
>  }
> 
> -DEPENDS = "expat makedepend-native flex-native bison-native libxml2-native zlib chrpath-replacement-native python3-mako-native gettext-native python3-pyyaml-native"
> +DEPENDS = "makedepend-native flex-native bison-native libxml2-native chrpath-replacement-native python3-mako-native gettext-native python3-pyyaml-native"

Make sure to add a comment here or someone is bound to come along 
thinking that these can be added to DEPENDS instead because they will 
automatically be converted for native etc. E.g.:

# Specify these explicitly since this file is included by the mesa-native recipe

> +DEPENDS:append:class-target = " expat zlib"
> +DEPENDS:append:class-native = " expat-native zlib-native"
> +DEPENDS:append:class-nativesdk = " nativesdk-expat nativesdk-zlib"
>  EXTRANATIVEPATH += "chrpath-native"
> 
>  inherit meson pkgconfig python3native gettext features_check rust
> 
> 
> >
> > and compiling mesa-tools-native on qemurisc64 then worked just fine.
> >
> 
> --
> With best wishes
> Dmitry

//Peter

Re: [OE-core] [PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[Quentin Schulz]

Hi Dmitry,

On 9/21/25 3:49 AM, Dmitry Baryshkov via lists.openembedded.org wrote:
> On Mon, Sep 01, 2025 at 04:51:49PM +0200, Quentin Schulz wrote:
>> Hi Mathieu, all,
>>
>> On 8/23/25 8:01 PM, Mathieu Dubois-Briand wrote:
>>> On Fri Aug 22, 2025 at 2:53 PM CEST, Quentin Schulz wrote:
>>>> @Otavio, can I add the new mesa-tools-native recipe under your
>>>> maintainership in meta/conf/distro/include/maintainers.inc, it is after
>>>> all still mesa?
>>>>
>>>> Panfrost support has been broken for a while already because it now
>>>> requires libclc which isn't enforced by default. This fixes this
>>>> oversight.
>>>>
>>>> While re-adding support for panfrost, the build time for libclc were a
>>>> bit too much to my taste and I tried to figure out if we could lighten
>>>> up the dependencies for the target recipe and it seems to be the case.
>>>>
>>>> libclc brings very expensive dependencies such as llvm and clang.
>>>> Building clang and llvm for each target architecture is very expensive,
>>>> but mesa allows to depend on prebuilt host binaries (mesa-clc and
>>>> precomp-compiler). Those are built by mesa as well, but can be compiled
>>>> in mesa-native instead of mesa, making the dependency expensive but only
>>>> once regardless of the number of target architectures to build for.
>>>> Ideally the mesa-clc and precomp-compiler would only be compiled in
>>>> mesa-native if target mesa requires libclc support, however this is not
>>>> possible as a target recipe cannot impact or depend on a native recipe's
>>>> configuration. We thus have two choices, always build libclc in
>>>> mesa-native with its heavy dependencies and impact every build or force
>>>> the user to modify the mesa-native recipe in a custom layer (as a native
>>>> recipe cannot use target's OVERRIDES). The latter is unacceptable so the
>>>> former seems to be the only option. Another big downside is that
>>>> mesa-native currently builds drivers (amd, nouveau, svga) which we may
>>>> have absolutely no interest in building, increasing the build time and
>>>> possibly dependencies list).
>>>>
>>>> A third choice is to spin-off the native mesa recipe with libclc support
>>>> into a new recipe without drivers and only what's necessary to build
>>>> mesa-clc and precomp-compiler binaries.
>>>> This allows to keep a "clean" mesa-native recipe for whoever needs those
>>>> drivers built-in (e.g. for testing, for qemu-native, or whatever else)
>>>> and only bring the libclc dependency when required by the target recipe.
>>>>
>>>> Because libclc is now only built for the host, opencl support now needs
>>>> to explicitly bring libclc and others to build as libclc won't bring it
>>>> in the build environment anymore.
>>>>
>>>> Note that this was essentially only build tested (run tested on RK3588
>>>> with panfrost though).
>>>>
>>>> Note that building gallium-llvm support on big.LITTLE architecture with
>>>> TOOLCHAIN = "gcc" (the default) currently doesn't work as llvm doesn't
>>>> support big.LITTLE architecture in -mcpu/-march which is passed to the
>>>> CFLAGS/CXXFLAGS/LDFLAGS via the TUNE_CCARGS. I haven't investigated
>>>> further than that but that prevents us from building opencl support for
>>>> Rockchip most popular and powerful SoCs right now. One option could be
>>>> to force this recipe to be built with clang toolchain only whenever
>>>> gallium-llvm is specified in PACKAGECONFIG (not tested). Though that may
>>>> be not straightforward seeing the comment in libclc recipe related to
>>>> forcing the toolchain to clang.
>>>> I'm also not sure mesa has a way to specify different args to LLVM-only
>>>> drivers but that could be another option.
>>>>
>>>> Runtime tested on RK3588 and PX30 with kmscube.
>>>> Partially runtime tested on PX30 with opencl-cts (and rusticl; it fails
>>>> after some time but could be kernel related as it starts failing after
>>>> [  968.625506] panfrost ff400000.gpu: gpu sched timeout, js=1, config=0x7b00, status=0x8, head=0xa68d200, tail=0xa68d200, sched_job=0000000019e6f20d
>>>>
>>>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>>>> ---
>>>
>>> Hi Quentin,
>>>
>>> Thanks for the new version.
>>>
>>> It looks like we have a build issue for riscv platforms:
>>>
>>> ERROR: mesa-tools-native-2_25.2.1-r0 do_prepare_recipe_sysroot: The sstate manifest for task 'expat:populate_sysroot' (multilib variant '') could not be found.
>>> The pkgarchs considered were: qemuriscv64, allarch, x86_64_x86_64-nativesdk.
>>> But none of these manifests exists:
>>>       /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-qemuriscv64-expat.populate_sysroot
>>>       /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-allarch-expat.populate_sysroot
>>>       /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-expat.populate_sysroot
>>>
>>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/45/builds/379
>>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/56/builds/396
>>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/58/builds/362
>>>
>>> Can you have a look at these, please?
>>>
>>
>> Ok so I believe this is because mesa-tools-native uses a different mechanism
>> from other mesa recipes to be a native recipe.
>>
>> mesa-tools-native inherits native + -native in the recipe filename.
>> mesa-gl/mesa simply adds native to BBCLASSEXTEND.
>>
>> The issue I believe is that mesa.inc has a DEPENDS with expat (and zlib) in
>> it. In the case of BBCLASSEXTEND, non-native dependencies are suffixed with
>> -native to be native when building the native recipe. But in the case of
>> inherit native + -native in filename, it doesn't.
>>
>> To validate this, I did a simple
>>
>> DEPENDS:remove = "expat zlib"
>> DEPENDS += "expat-native zlib-native"
> 
> I took a glance. I think it would be more idiomatic to write something
> like:
> 
> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
> index ddcf3b774a37..5a303538d7be 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -41,7 +41,10 @@ do_install:append() {
>     fi
>   }
> 
> -DEPENDS = "expat makedepend-native flex-native bison-native libxml2-native zlib chrpath-replacement-native python3-mako-native gettext-native python3-pyyaml-native"
> +DEPENDS = "makedepend-native flex-native bison-native libxml2-native chrpath-replacement-native python3-mako-native gettext-native python3-pyyaml-native"
> +DEPENDS:append:class-target = " expat zlib"
> +DEPENDS:append:class-native = " expat-native zlib-native"
> +DEPENDS:append:class-nativesdk = " nativesdk-expat nativesdk-zlib"
>   EXTRANATIVEPATH += "chrpath-native"
> 
>   inherit meson pkgconfig python3native gettext features_check rust
> 

I would prefer to have a PACKAGECONFIG option for expat and another for 
zlib since it seems from my reading of mesa various meson files that 
both are optional.

But we could start with this to move forward and revisit this later on 
once someone has time and motivation.

What bothers me is that both suggestions rely on the fact that DEPENDS 
will never get a non-native recipe as dependency, which is kind of 
implementing a ticking bomb.

Another option I thought of is to move mesa-tools package from mesa 
recipe to a new mesa-tools recipe and thus make mesa-tools recipe both 
target and native (and likely nativesdk as well). This eliminates the 
need for a new PACKAGECONFIG or fixing DEPENDS like suggested here, but 
this likely involves the user changing PACKAGECONFIG for both mesa-tools 
and mesa recipes to include whatever they need and keeping them in sync 
if they want the tools for the driver they are building. I'm also not 
entirely sure it is possible to build all tools from mesa for drivers 
while not enabling the drivers themselves.

Cheers,
Quentin

Re: [OE-core] [PATCH v6 00/14] mesa: lighten up target's libclc dependencies and fix panfrost support

[Dmitry Baryshkov]

On Mon, Sep 22, 2025 at 11:37:01AM +0200, Quentin Schulz wrote:
> Hi Dmitry,
> 
> On 9/21/25 3:49 AM, Dmitry Baryshkov via lists.openembedded.org wrote:
> > On Mon, Sep 01, 2025 at 04:51:49PM +0200, Quentin Schulz wrote:
> > > Hi Mathieu, all,
> > > 
> > > On 8/23/25 8:01 PM, Mathieu Dubois-Briand wrote:
> > > > On Fri Aug 22, 2025 at 2:53 PM CEST, Quentin Schulz wrote:
> > > > > @Otavio, can I add the new mesa-tools-native recipe under your
> > > > > maintainership in meta/conf/distro/include/maintainers.inc, it is after
> > > > > all still mesa?
> > > > > 
> > > > > Panfrost support has been broken for a while already because it now
> > > > > requires libclc which isn't enforced by default. This fixes this
> > > > > oversight.
> > > > > 
> > > > > While re-adding support for panfrost, the build time for libclc were a
> > > > > bit too much to my taste and I tried to figure out if we could lighten
> > > > > up the dependencies for the target recipe and it seems to be the case.
> > > > > 
> > > > > libclc brings very expensive dependencies such as llvm and clang.
> > > > > Building clang and llvm for each target architecture is very expensive,
> > > > > but mesa allows to depend on prebuilt host binaries (mesa-clc and
> > > > > precomp-compiler). Those are built by mesa as well, but can be compiled
> > > > > in mesa-native instead of mesa, making the dependency expensive but only
> > > > > once regardless of the number of target architectures to build for.
> > > > > Ideally the mesa-clc and precomp-compiler would only be compiled in
> > > > > mesa-native if target mesa requires libclc support, however this is not
> > > > > possible as a target recipe cannot impact or depend on a native recipe's
> > > > > configuration. We thus have two choices, always build libclc in
> > > > > mesa-native with its heavy dependencies and impact every build or force
> > > > > the user to modify the mesa-native recipe in a custom layer (as a native
> > > > > recipe cannot use target's OVERRIDES). The latter is unacceptable so the
> > > > > former seems to be the only option. Another big downside is that
> > > > > mesa-native currently builds drivers (amd, nouveau, svga) which we may
> > > > > have absolutely no interest in building, increasing the build time and
> > > > > possibly dependencies list).
> > > > > 
> > > > > A third choice is to spin-off the native mesa recipe with libclc support
> > > > > into a new recipe without drivers and only what's necessary to build
> > > > > mesa-clc and precomp-compiler binaries.
> > > > > This allows to keep a "clean" mesa-native recipe for whoever needs those
> > > > > drivers built-in (e.g. for testing, for qemu-native, or whatever else)
> > > > > and only bring the libclc dependency when required by the target recipe.
> > > > > 
> > > > > Because libclc is now only built for the host, opencl support now needs
> > > > > to explicitly bring libclc and others to build as libclc won't bring it
> > > > > in the build environment anymore.
> > > > > 
> > > > > Note that this was essentially only build tested (run tested on RK3588
> > > > > with panfrost though).
> > > > > 
> > > > > Note that building gallium-llvm support on big.LITTLE architecture with
> > > > > TOOLCHAIN = "gcc" (the default) currently doesn't work as llvm doesn't
> > > > > support big.LITTLE architecture in -mcpu/-march which is passed to the
> > > > > CFLAGS/CXXFLAGS/LDFLAGS via the TUNE_CCARGS. I haven't investigated
> > > > > further than that but that prevents us from building opencl support for
> > > > > Rockchip most popular and powerful SoCs right now. One option could be
> > > > > to force this recipe to be built with clang toolchain only whenever
> > > > > gallium-llvm is specified in PACKAGECONFIG (not tested). Though that may
> > > > > be not straightforward seeing the comment in libclc recipe related to
> > > > > forcing the toolchain to clang.
> > > > > I'm also not sure mesa has a way to specify different args to LLVM-only
> > > > > drivers but that could be another option.
> > > > > 
> > > > > Runtime tested on RK3588 and PX30 with kmscube.
> > > > > Partially runtime tested on PX30 with opencl-cts (and rusticl; it fails
> > > > > after some time but could be kernel related as it starts failing after
> > > > > [  968.625506] panfrost ff400000.gpu: gpu sched timeout, js=1, config=0x7b00, status=0x8, head=0xa68d200, tail=0xa68d200, sched_job=0000000019e6f20d
> > > > > 
> > > > > Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> > > > > ---
> > > > 
> > > > Hi Quentin,
> > > > 
> > > > Thanks for the new version.
> > > > 
> > > > It looks like we have a build issue for riscv platforms:
> > > > 
> > > > ERROR: mesa-tools-native-2_25.2.1-r0 do_prepare_recipe_sysroot: The sstate manifest for task 'expat:populate_sysroot' (multilib variant '') could not be found.
> > > > The pkgarchs considered were: qemuriscv64, allarch, x86_64_x86_64-nativesdk.
> > > > But none of these manifests exists:
> > > >       /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-qemuriscv64-expat.populate_sysroot
> > > >       /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-allarch-expat.populate_sysroot
> > > >       /srv/pokybuild/yocto-worker/qemuriscv64/build/build/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-expat.populate_sysroot
> > > > 
> > > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/45/builds/379
> > > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/56/builds/396
> > > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/58/builds/362
> > > > 
> > > > Can you have a look at these, please?
> > > > 
> > > 
> > > Ok so I believe this is because mesa-tools-native uses a different mechanism
> > > from other mesa recipes to be a native recipe.
> > > 
> > > mesa-tools-native inherits native + -native in the recipe filename.
> > > mesa-gl/mesa simply adds native to BBCLASSEXTEND.
> > > 
> > > The issue I believe is that mesa.inc has a DEPENDS with expat (and zlib) in
> > > it. In the case of BBCLASSEXTEND, non-native dependencies are suffixed with
> > > -native to be native when building the native recipe. But in the case of
> > > inherit native + -native in filename, it doesn't.
> > > 
> > > To validate this, I did a simple
> > > 
> > > DEPENDS:remove = "expat zlib"
> > > DEPENDS += "expat-native zlib-native"
> > 
> > I took a glance. I think it would be more idiomatic to write something
> > like:
> > 
> > diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
> > index ddcf3b774a37..5a303538d7be 100644
> > --- a/meta/recipes-graphics/mesa/mesa.inc
> > +++ b/meta/recipes-graphics/mesa/mesa.inc
> > @@ -41,7 +41,10 @@ do_install:append() {
> >     fi
> >   }
> > 
> > -DEPENDS = "expat makedepend-native flex-native bison-native libxml2-native zlib chrpath-replacement-native python3-mako-native gettext-native python3-pyyaml-native"
> > +DEPENDS = "makedepend-native flex-native bison-native libxml2-native chrpath-replacement-native python3-mako-native gettext-native python3-pyyaml-native"
> > +DEPENDS:append:class-target = " expat zlib"
> > +DEPENDS:append:class-native = " expat-native zlib-native"
> > +DEPENDS:append:class-nativesdk = " nativesdk-expat nativesdk-zlib"
> >   EXTRANATIVEPATH += "chrpath-native"
> > 
> >   inherit meson pkgconfig python3native gettext features_check rust
> > 
> 
> I would prefer to have a PACKAGECONFIG option for expat and another for zlib
> since it seems from my reading of mesa various meson files that both are
> optional.

expat is required for Intel tools or for XML driconf support and
optional for v3d driver. Zlib is also used by Intel tools, v3d driver
and for compressed shader DP support (or it can be replaced by zstd for
shader storage).

> But we could start with this to move forward and revisit this later on once
> someone has time and motivation.

Ack

> 
> What bothers me is that both suggestions rely on the fact that DEPENDS will
> never get a non-native recipe as dependency, which is kind of implementing a
> ticking bomb.
> 
> Another option I thought of is to move mesa-tools package from mesa recipe
> to a new mesa-tools recipe and thus make mesa-tools recipe both target and
> native (and likely nativesdk as well). This eliminates the need for a new
> PACKAGECONFIG or fixing DEPENDS like suggested here, but this likely
> involves the user changing PACKAGECONFIG for both mesa-tools and mesa
> recipes to include whatever they need and keeping them in sync if they want
> the tools for the driver they are building. I'm also not entirely sure it is
> possible to build all tools from mesa for drivers while not enabling the
> drivers themselves.

Each time I see 'keep in sync' it makes me worry a bit. I like your
current approach of enabling drivers necessary to build host tools.

-- 
With best wishes
Dmitry