| Message ID | 20250327221807.2551544-1-dmitry.baryshkov@oss.qualcomm.com |
|---|---|
| Headers | show |
| Series | mesa: upgrade to 25.0.2 | expand |
On Thu, Mar 27, 2025 at 3:18 PM Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote: > > libclc is required in order to build Intel drivers in Mesa 24.1 and > later. Thus OE-Core is currently locked to the 24.0.x branch, which is > no longer maintained, having last release in June 2024. > > A clean solution is to package Clang, then use it to build libclc and > SPIRV-LLVM-Translator (required for Mesa OpenCL support). However > creating proper recipes for Clang is a long process (ongoing by Khem > Raj). > > This patchset attempts to solve the issue in a simpler way: by building > libclc and SPIRV-LLVM-Translator together with the LLVM. This way we > don't have to create target Clang recipes, there is no extra toolchain > to support, etc. Clang binaries are creted as a part of the build > process (in order to support building target packages), however it only > hits the LLVM sysroot-native and is only used by the LLVM target build. > > Future work by Khem (once Clang is properly supported in OE-Core) should > allow us to create proper recipes for libclc and spirv-llvm-translator > and drop them from the llvm / clang recipe. > > I think this approach provides a good balance between OE-Core being > stuck with the outdated Mesa release and being able to upgrade it, > bringing support for new hardware. > > Last two patches of the series bring in RustiCL support, a new OpenCL > implementation within Mesa. They are optional for the sake of the > upgrade and can be dropped if there is any issue with those. RustiCL > support is mostly compile-tested at this point. I took a look at the patchset, I don't have any particular objection to it. Since this is too late for walnascar release I think this will be considered for next release only atm. In that case, Since clang is also deferred until next release I wonder if we should do it along with clang merge into core but then I don't see big conflicts in there, it could even make mesa stable and a good litmus test for clang merge if that happens after it. > > Changes since v1: > - Dropped YOCTO_ALTERNATE_LIBDIR patch > - Reworked mesa / LLVM integration to always use get_option('libdir') > - Reenabled AMD Vulkan driver (got disabled because of c&p error) > - Moved mesa-clc options to the libclc PACKAGECONFIG to fix several > build errors > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > > Dmitry Baryshkov (6): > llvm: move libLLVM.so.N.M to llvm-libllvm package > llvm: use OECMAKE_SOURCEPATH to specify cmake dir > llvm: support building libclc > llvm: add SPIRV-LLVM-Translator support > mesa: upgrade 24.0.7 -> 25.0.2 > bindgen-cli: a tool to generate Rust bindings > > Zoltán Böszörményi (1): > mesa: add support for RustiCL under PACKAGECONFIG "opencl" > > meta/conf/distro/include/maintainers.inc | 1 + > .../bindgen-cli/bindgen-cli-crates.inc | 186 ++++++++++++++++++ > .../bindgen-cli/bindgen-cli_0.71.1.bb | 19 ++ > ...ossCompile-pass-SPIR-V-headers-path-.patch | 40 ++++ > .../llvm/llvm/fix-native-compilation.patch | 67 +++++++ > .../llvm/llvm/spirv-internal-build.patch | 27 +++ > meta/recipes-devtools/llvm/llvm_20.1.0.bb | 76 ++++++- > ...-meson-do-not-pull-in-clc-for-clover.patch | 53 ----- > ...lude-missing-llvm-IR-header-Module.h.patch | 41 ---- > .../0001-drisw-fix-build-without-dri3.patch | 58 ------ > ...on-t-encode-build-path-into-binaries.patch | 46 ++++- > ...son-use-target-path-for-Clang-libdir.patch | 57 ++++++ > ...cross-compilation-arguments-to-LLVM-.patch | 64 ++++++ > ...on-t-try-zink-if-not-enabled-in-mesa.patch | 42 ---- > meta/recipes-graphics/mesa/mesa.inc | 102 +++++----- > 15 files changed, 625 insertions(+), 254 deletions(-) > create mode 100644 meta/recipes-devtools/bindgen-cli/bindgen-cli-crates.inc > create mode 100644 meta/recipes-devtools/bindgen-cli/bindgen-cli_0.71.1.bb > create mode 100644 meta/recipes-devtools/llvm/llvm/0001-cmake-modules-CrossCompile-pass-SPIR-V-headers-path-.patch > create mode 100644 meta/recipes-devtools/llvm/llvm/fix-native-compilation.patch > create mode 100644 meta/recipes-devtools/llvm/llvm/spirv-internal-build.patch > delete mode 100644 meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch > delete mode 100644 meta/recipes-graphics/mesa/files/0001-amd-Include-missing-llvm-IR-header-Module.h.patch > delete mode 100644 meta/recipes-graphics/mesa/files/0001-drisw-fix-build-without-dri3.patch > create mode 100644 meta/recipes-graphics/mesa/files/0001-meson-use-target-path-for-Clang-libdir.patch > create mode 100644 meta/recipes-graphics/mesa/files/0001-rusticl-provide-cross-compilation-arguments-to-LLVM-.patch > delete mode 100644 meta/recipes-graphics/mesa/files/0002-glxext-don-t-try-zink-if-not-enabled-in-mesa.patch > > -- > 2.39.5 >
On Thu Mar 27, 2025 at 11:18 PM CET, Dmitry Baryshkov via lists.openembedded.org wrote: > libclc is required in order to build Intel drivers in Mesa 24.1 and > later. Thus OE-Core is currently locked to the 24.0.x branch, which is > no longer maintained, having last release in June 2024. > > A clean solution is to package Clang, then use it to build libclc and > SPIRV-LLVM-Translator (required for Mesa OpenCL support). However > creating proper recipes for Clang is a long process (ongoing by Khem > Raj). > > This patchset attempts to solve the issue in a simpler way: by building > libclc and SPIRV-LLVM-Translator together with the LLVM. This way we > don't have to create target Clang recipes, there is no extra toolchain > to support, etc. Clang binaries are creted as a part of the build > process (in order to support building target packages), however it only > hits the LLVM sysroot-native and is only used by the LLVM target build. > > Future work by Khem (once Clang is properly supported in OE-Core) should > allow us to create proper recipes for libclc and spirv-llvm-translator > and drop them from the llvm / clang recipe. > > I think this approach provides a good balance between OE-Core being > stuck with the outdated Mesa release and being able to upgrade it, > bringing support for new hardware. > > Last two patches of the series bring in RustiCL support, a new OpenCL > implementation within Mesa. They are optional for the sake of the > upgrade and can be dropped if there is any issue with those. RustiCL > support is mostly compile-tested at this point. > > Changes since v1: > - Dropped YOCTO_ALTERNATE_LIBDIR patch > - Reworked mesa / LLVM integration to always use get_option('libdir') > - Reenabled AMD Vulkan driver (got disabled because of c&p error) > - Moved mesa-clc options to the libclc PACKAGECONFIG to fix several > build errors > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Hi, Thanks for the v2, but it looks like we still have some issues on the autobuilder: ERROR: nativesdk-mesa-2_25.0.2-r0 do_package_qa: QA Issue: File /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib/dri/libdril_dri.so in package nativesdk-mesa-megadriver contains reference to TMPDIR [buildpaths] ERROR: nativesdk-mesa-2_25.0.2-r0 do_package_qa: QA Issue: nativesdk-mesa-megadriver: /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib/dri/libdril_dri.so contains bad RPATH /srv/pokybuild/yocto-worker/meta-intel/build/build/tmp/work/x86_64-linux/llvm-native/20.1.0/recipe-sysroot-native/usr/lib:/srv/pokybuild/yocto-worker/meta-intel/build/build/tmp/work/x86_64-linux/llvm-native/20.1.0/recipe-sysroot-native/lib [rpaths] ERROR: nativesdk-mesa-2_25.0.2-r0 do_package_qa: QA Issue: File /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib/libgallium-25.0.2.so in package nativesdk-libgallium contains reference to TMPDIR [buildpaths] ERROR: nativesdk-mesa-2_25.0.2-r0 do_package_qa: QA Issue: nativesdk-libgallium: /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib/libgallium-25.0.2.so contains bad RPATH /srv/pokybuild/yocto-worker/meta-intel/build/build/tmp/work/x86_64-linux/llvm-native/20.1.0/recipe-sysroot-native/usr/lib:/srv/pokybuild/yocto-worker/meta-intel/build/build/tmp/work/x86_64-linux/llvm-native/20.1.0/recipe-sysroot-native/lib [rpaths] ERROR: nativesdk-mesa-2_25.0.2-r0 do_package_qa: Fatal QA errors were found, failing task. https://autobuilder.yoctoproject.org/valkyrie/#/builders/4/builds/1288 https://autobuilder.yoctoproject.org/valkyrie/#/builders/2/builds/1289
On Fri, Mar 28, 2025 at 10:18:05AM +0100, Mathieu Dubois-Briand wrote: > On Thu Mar 27, 2025 at 11:18 PM CET, Dmitry Baryshkov via lists.openembedded.org wrote: > > libclc is required in order to build Intel drivers in Mesa 24.1 and > > later. Thus OE-Core is currently locked to the 24.0.x branch, which is > > no longer maintained, having last release in June 2024. > > > > A clean solution is to package Clang, then use it to build libclc and > > SPIRV-LLVM-Translator (required for Mesa OpenCL support). However > > creating proper recipes for Clang is a long process (ongoing by Khem > > Raj). > > > > This patchset attempts to solve the issue in a simpler way: by building > > libclc and SPIRV-LLVM-Translator together with the LLVM. This way we > > don't have to create target Clang recipes, there is no extra toolchain > > to support, etc. Clang binaries are creted as a part of the build > > process (in order to support building target packages), however it only > > hits the LLVM sysroot-native and is only used by the LLVM target build. > > > > Future work by Khem (once Clang is properly supported in OE-Core) should > > allow us to create proper recipes for libclc and spirv-llvm-translator > > and drop them from the llvm / clang recipe. > > > > I think this approach provides a good balance between OE-Core being > > stuck with the outdated Mesa release and being able to upgrade it, > > bringing support for new hardware. > > > > Last two patches of the series bring in RustiCL support, a new OpenCL > > implementation within Mesa. They are optional for the sake of the > > upgrade and can be dropped if there is any issue with those. RustiCL > > support is mostly compile-tested at this point. > > > > Changes since v1: > > - Dropped YOCTO_ALTERNATE_LIBDIR patch > > - Reworked mesa / LLVM integration to always use get_option('libdir') > > - Reenabled AMD Vulkan driver (got disabled because of c&p error) > > - Moved mesa-clc options to the libclc PACKAGECONFIG to fix several > > build errors > > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > > Hi, > > Thanks for the v2, but it looks like we still have some issues on the > autobuilder: > > ERROR: nativesdk-mesa-2_25.0.2-r0 do_package_qa: QA Issue: File /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib/dri/libdril_dri.so in package nativesdk-mesa-megadriver contains reference to TMPDIR [buildpaths] > ERROR: nativesdk-mesa-2_25.0.2-r0 do_package_qa: QA Issue: nativesdk-mesa-megadriver: /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib/dri/libdril_dri.so contains bad RPATH /srv/pokybuild/yocto-worker/meta-intel/build/build/tmp/work/x86_64-linux/llvm-native/20.1.0/recipe-sysroot-native/usr/lib:/srv/pokybuild/yocto-worker/meta-intel/build/build/tmp/work/x86_64-linux/llvm-native/20.1.0/recipe-sysroot-native/lib [rpaths] > ERROR: nativesdk-mesa-2_25.0.2-r0 do_package_qa: QA Issue: File /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib/libgallium-25.0.2.so in package nativesdk-libgallium contains reference to TMPDIR [buildpaths] > ERROR: nativesdk-mesa-2_25.0.2-r0 do_package_qa: QA Issue: nativesdk-libgallium: /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib/libgallium-25.0.2.so contains bad RPATH /srv/pokybuild/yocto-worker/meta-intel/build/build/tmp/work/x86_64-linux/llvm-native/20.1.0/recipe-sysroot-native/usr/lib:/srv/pokybuild/yocto-worker/meta-intel/build/build/tmp/work/x86_64-linux/llvm-native/20.1.0/recipe-sysroot-native/lib [rpaths] > ERROR: nativesdk-mesa-2_25.0.2-r0 do_package_qa: Fatal QA errors were found, failing task. > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/4/builds/1288 > https://autobuilder.yoctoproject.org/valkyrie/#/builders/2/builds/1289 I will take a look at the SDK builds, thanks!
On Thu, Mar 27, 2025 at 09:33:26PM -0700, Khem Raj wrote: > On Thu, Mar 27, 2025 at 3:18 PM Dmitry Baryshkov > <dmitry.baryshkov@oss.qualcomm.com> wrote: > > > > libclc is required in order to build Intel drivers in Mesa 24.1 and > > later. Thus OE-Core is currently locked to the 24.0.x branch, which is > > no longer maintained, having last release in June 2024. > > > > A clean solution is to package Clang, then use it to build libclc and > > SPIRV-LLVM-Translator (required for Mesa OpenCL support). However > > creating proper recipes for Clang is a long process (ongoing by Khem > > Raj). > > > > This patchset attempts to solve the issue in a simpler way: by building > > libclc and SPIRV-LLVM-Translator together with the LLVM. This way we > > don't have to create target Clang recipes, there is no extra toolchain > > to support, etc. Clang binaries are creted as a part of the build > > process (in order to support building target packages), however it only > > hits the LLVM sysroot-native and is only used by the LLVM target build. > > > > Future work by Khem (once Clang is properly supported in OE-Core) should > > allow us to create proper recipes for libclc and spirv-llvm-translator > > and drop them from the llvm / clang recipe. > > > > I think this approach provides a good balance between OE-Core being > > stuck with the outdated Mesa release and being able to upgrade it, > > bringing support for new hardware. > > > > Last two patches of the series bring in RustiCL support, a new OpenCL > > implementation within Mesa. They are optional for the sake of the > > upgrade and can be dropped if there is any issue with those. RustiCL > > support is mostly compile-tested at this point. > > I took a look at the patchset, I don't have any particular objection to it. > Since this is too late for walnascar release I think this will be considered > for next release only atm. I was kind of hoping that this can get into walnascar, but it seems we missed the boat. I saw that the branch was created this night. > In that case, Since clang is also deferred until > next release I wonder if we should do it along with clang merge into core As I wrote earlier, I think we should not be left with the outdated Mesa. Otherwise, we lack modern hardware support. I really fear that it will take several more months to land proper Clang support (sorry). > but then I don't see big conflicts in there, it could even make mesa stable > and a good litmus test for clang merge if that happens after it. I tried to stay as close as possible to the upcoming changes, as possible
On Fri, 28 Mar 2025 at 12:01, Dmitry Baryshkov via lists.openembedded.org <dmitry.baryshkov=oss.qualcomm.com@lists.openembedded.org> wrote: > As I wrote earlier, I think we should not be left with the outdated > Mesa. Otherwise, we lack modern hardware support. I really fear that > it will take several more months to land proper Clang support (sorry). Just to be clear, I fully support you here. Outdated mesa is starting to hurt the project. I only want the patches to be as high quality, well-documented, and maintainable as they can be. Alex
On Fri, 28 Mar 2025 at 13:03, Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > On Fri, 28 Mar 2025 at 12:01, Dmitry Baryshkov via > lists.openembedded.org > <dmitry.baryshkov=oss.qualcomm.com@lists.openembedded.org> wrote: > > As I wrote earlier, I think we should not be left with the outdated > > Mesa. Otherwise, we lack modern hardware support. I really fear that > > it will take several more months to land proper Clang support (sorry). > > Just to be clear, I fully support you here. Outdated mesa is starting > to hurt the project. I only want the patches to be as high quality, > well-documented, and maintainable as they can be. I know. I fully appreciate that.
libclc is required in order to build Intel drivers in Mesa 24.1 and later. Thus OE-Core is currently locked to the 24.0.x branch, which is no longer maintained, having last release in June 2024. A clean solution is to package Clang, then use it to build libclc and SPIRV-LLVM-Translator (required for Mesa OpenCL support). However creating proper recipes for Clang is a long process (ongoing by Khem Raj). This patchset attempts to solve the issue in a simpler way: by building libclc and SPIRV-LLVM-Translator together with the LLVM. This way we don't have to create target Clang recipes, there is no extra toolchain to support, etc. Clang binaries are creted as a part of the build process (in order to support building target packages), however it only hits the LLVM sysroot-native and is only used by the LLVM target build. Future work by Khem (once Clang is properly supported in OE-Core) should allow us to create proper recipes for libclc and spirv-llvm-translator and drop them from the llvm / clang recipe. I think this approach provides a good balance between OE-Core being stuck with the outdated Mesa release and being able to upgrade it, bringing support for new hardware. Last two patches of the series bring in RustiCL support, a new OpenCL implementation within Mesa. They are optional for the sake of the upgrade and can be dropped if there is any issue with those. RustiCL support is mostly compile-tested at this point. Changes since v1: - Dropped YOCTO_ALTERNATE_LIBDIR patch - Reworked mesa / LLVM integration to always use get_option('libdir') - Reenabled AMD Vulkan driver (got disabled because of c&p error) - Moved mesa-clc options to the libclc PACKAGECONFIG to fix several build errors Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Dmitry Baryshkov (6): llvm: move libLLVM.so.N.M to llvm-libllvm package llvm: use OECMAKE_SOURCEPATH to specify cmake dir llvm: support building libclc llvm: add SPIRV-LLVM-Translator support mesa: upgrade 24.0.7 -> 25.0.2 bindgen-cli: a tool to generate Rust bindings Zoltán Böszörményi (1): mesa: add support for RustiCL under PACKAGECONFIG "opencl" meta/conf/distro/include/maintainers.inc | 1 + .../bindgen-cli/bindgen-cli-crates.inc | 186 ++++++++++++++++++ .../bindgen-cli/bindgen-cli_0.71.1.bb | 19 ++ ...ossCompile-pass-SPIR-V-headers-path-.patch | 40 ++++ .../llvm/llvm/fix-native-compilation.patch | 67 +++++++ .../llvm/llvm/spirv-internal-build.patch | 27 +++ meta/recipes-devtools/llvm/llvm_20.1.0.bb | 76 ++++++- ...-meson-do-not-pull-in-clc-for-clover.patch | 53 ----- ...lude-missing-llvm-IR-header-Module.h.patch | 41 ---- .../0001-drisw-fix-build-without-dri3.patch | 58 ------ ...on-t-encode-build-path-into-binaries.patch | 46 ++++- ...son-use-target-path-for-Clang-libdir.patch | 57 ++++++ ...cross-compilation-arguments-to-LLVM-.patch | 64 ++++++ ...on-t-try-zink-if-not-enabled-in-mesa.patch | 42 ---- meta/recipes-graphics/mesa/mesa.inc | 102 +++++----- 15 files changed, 625 insertions(+), 254 deletions(-) create mode 100644 meta/recipes-devtools/bindgen-cli/bindgen-cli-crates.inc create mode 100644 meta/recipes-devtools/bindgen-cli/bindgen-cli_0.71.1.bb create mode 100644 meta/recipes-devtools/llvm/llvm/0001-cmake-modules-CrossCompile-pass-SPIR-V-headers-path-.patch create mode 100644 meta/recipes-devtools/llvm/llvm/fix-native-compilation.patch create mode 100644 meta/recipes-devtools/llvm/llvm/spirv-internal-build.patch delete mode 100644 meta/recipes-graphics/mesa/files/0001-Revert-meson-do-not-pull-in-clc-for-clover.patch delete mode 100644 meta/recipes-graphics/mesa/files/0001-amd-Include-missing-llvm-IR-header-Module.h.patch delete mode 100644 meta/recipes-graphics/mesa/files/0001-drisw-fix-build-without-dri3.patch create mode 100644 meta/recipes-graphics/mesa/files/0001-meson-use-target-path-for-Clang-libdir.patch create mode 100644 meta/recipes-graphics/mesa/files/0001-rusticl-provide-cross-compilation-arguments-to-LLVM-.patch delete mode 100644 meta/recipes-graphics/mesa/files/0002-glxext-don-t-try-zink-if-not-enabled-in-mesa.patch