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

["Mathieu Dubois-Briand" <mathieu.dubois-briand@bootlin.com>]

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