From patchwork Mon Jul 21 10:33:37 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Quentin Schulz X-Patchwork-Id: 1768 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C7B2C87FC5 for ; Mon, 21 Jul 2025 10:34:02 +0000 (UTC) Received: from smtp-42ad.mail.infomaniak.ch (smtp-42ad.mail.infomaniak.ch [84.16.66.173]) by mx.groups.io with SMTP id smtpd.web10.37286.1753094033377751544 for ; Mon, 21 Jul 2025 03:33:53 -0700 Authentication-Results: mx.groups.io; dkim=none (message not signed); spf=pass (domain: 0leil.net, ip: 84.16.66.173, mailfrom: foss+yocto@0leil.net) Received: from smtp-4-0000.mail.infomaniak.ch (smtp-4-0000.mail.infomaniak.ch [10.7.10.107]) by smtp-4-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4blxZl4LjQzNwV; Mon, 21 Jul 2025 12:33:51 +0200 (CEST) Received: from unknown by smtp-4-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4blxZk4kNbzWql; Mon, 21 Jul 2025 12:33:50 +0200 (CEST) From: Quentin Schulz Subject: [PATCH RFC v2 0/6] mesa: lighten up target's libclc dependencies and fix panfrost support Date: Mon, 21 Jul 2025 12:33:37 +0200 Message-Id: <20250721-mesa-libclc-panfrost-v2-0-f713d0858949@cherry.de> MIME-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAIEXfmgC/32NQQqDMBBFryKz7pQktJJ0VRB6gG6Li5iMdcCqT EQq4t0bPECX73/++xskEqYEt2IDoYUTj0MGcyogdH54E3LMDEaZqyrNBT+UPPbchD7g5IdWxjS jVjaWhrR1roE8nYRa/h7aFzwfFdQ57DjNo6zH1aKP6r910ajQUbTBO6vI6HvoSGQ9R4J63/cfM 2Ay9b0AAAA= X-Change-ID: 20250624-mesa-libclc-panfrost-108d62e1899b To: openembedded-core@lists.openembedded.org Cc: Dmitry Baryshkov , Markus Volk , Trevor Woerner , Ross Burton , Otavio Salvador , Quentin Schulz X-Mailer: b4 0.14.2 X-Infomaniak-Routing: alpha List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Mon, 21 Jul 2025 10:34:02 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/220673 @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). I tried to enable OpenCL support but it triggers a buildpaths QA error, which can be worked around with the following patch: commit f5508086477eb900bb0bcfa1a65f46c8d853595a Author: Quentin Schulz Date: Mon Jul 21 11:15:54 2025 +0200 clc: avoid host path poisoning LLVM_LIB_DIR is 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 only useful for debugging purposes while 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. I don't know how to fix this properly so I just hardcode it for now to silence build warnings. Upstream-Status: Inappropriate [proper fix sent to mesa stripping the sysroot would be much better] Signed-off-by: Quentin Schulz diff --git a/src/compiler/clc/clc_helpers.cpp b/src/compiler/clc/clc_helpers.cpp index 3c0c9db653f..fbc3b2b3d21 100644 --- a/src/compiler/clc/clc_helpers.cpp +++ b/src/compiler/clc/clc_helpers.cpp @@ -936,7 +936,7 @@ clc_compile_to_llvm_module(LLVMContext &llvm_ctx, false, false); auto clang_install_res_path = - fs::path(LLVM_LIB_DIR) / "clang" / std::to_string(LLVM_VERSION_MAJOR) / "include"; + fs::path("/usr/lib/clang") / std::to_string(LLVM_VERSION_MAJOR) / "include"; c->getHeaderSearchOpts().AddPath(clang_install_res_path.string(), clang::frontend::Angled, false, false); However, building OpenCL support with Asahi enabled triggers a bunch of other buildpaths QA errors and I believe those are triggered by: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/compiler/libcl/assert.h#L33 with __FILE__ pointing at the path on the build host. This should have been mitigated by DEBUG_PREFIX_MAP (-ffile-prefix-map=) but it probably isn't propagated by mesa's build system to the LLVM-only parts of the build? Signed-off-by: Quentin Schulz --- 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 (6): mesa: move PACKAGECONFIG defaults to recipes mesa: move PROVIDES out of include file mesa: move BBCLASSEXTEND out of the include file mesa: add asahi to TOOLS when selected in PACKAGECONFIG mesa: use simpler mesa-tools-native recipe as dependency for libclc mesa: fix panfrost driver build meta/recipes-graphics/mesa/mesa-gl.bb | 16 ++++++++-- meta/recipes-graphics/mesa/mesa-tools-native.bb | 21 +++++++++++++ meta/recipes-graphics/mesa/mesa.bb | 25 +++++++++++++++ meta/recipes-graphics/mesa/mesa.inc | 41 +++---------------------- 4 files changed, 65 insertions(+), 38 deletions(-) --- base-commit: 66f04cba71549f5b0bbfb699e1f662db7c9e8355 change-id: 20250624-mesa-libclc-panfrost-108d62e1899b Best regards,