| Message ID | 20250822-mesa-libclc-panfrost-v6-0-393cf47e2fa2@cherry.de |
|---|---|
| Headers | show |
| Series | mesa: lighten up target's libclc dependencies and fix panfrost support | expand |
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>
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
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
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
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
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
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
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. >
> -----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
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
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.
@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,