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 <[email protected]>
---
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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#222665):
https://lists.openembedded.org/g/openembedded-core/message/222665
Mute This Topic: https://lists.openembedded.org/mt/114834520/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
