mesa: update to 24.3.1, wayland-protocol updated to 1.38

[BassemMohsen]

Based on PR #1390

Update to latest mesa 24.3.1 release Fixes DRAM DSI linking to missing library drm-rp1-dsi_dri.so

fixes https://github.com/agherzan/meta-raspberrypi/issues/1389

Added new dependencies required by msea version update. Removed DRI3 option as it's now removed from meson build options. Updated Wayland Protocol to 1.38 as it's minimum required version for mesa 24.3.1 This PR will be completed when 24.3.1 is final official release. For now, I'm leaving it as work of progress to help whoever have issues with RPI5 DSI.

[BassemMohsen]

@leon-anavi I'm still testing the build against meta-raspberrypi scarthgap latest.

[BassemMohsen]

Amazing work @leon-anavi Thanks a lot.

I did test with Qt Wayland on Poky Styhead and master meta-raspberrypi too.

In that case, I would say both PRs are ready for CI and merging unless anyone have more change requests.

[BassemMohsen]

This Pull Request along with #1390 is becoming abandoned and neglected. Either we can accept it, or close it.

[leon-anavi]

This Pull Request along with #1390 is becoming abandoned and neglected. Either we can accept it, or close it.

@agherzan @kraj could you please have a look at these GitHub pull requests? With these changes @BassemMohsen has fixed the hardware acceleration for DSI displays. A lot of people have been asking/waiting for this fix. I tested it more than a moth ago, back in December.

Best regards, Leon

[danielfdickinson]

At least on walnascar this conflicts with meta-clang when setup as the default llvm and clang.

ERROR: Multiple .bb files are due to be built which each provide llvm:##################################                                                                                                       | ETA:  0:00:00
  /home/build/meta-clang/recipes-devtools/clang/clang_git.bb
  /home/build/meta-oe-core/meta/recipes-devtools/llvm/llvm_20.1.0.bb
A list of tasks depending on these providers is shown and may help explain where the dependency comes from.
/home/build/meta-clang/recipes-devtools/clang/clang_git.bb has unique dependees:
  /home/build/meta-oe-core/meta/recipes-graphics/mesa/mesa.bb:do_package
  /home/build/meta-doky/recipes-graphics/images/core-image-x11-doky.bb:do_populate_lic_deploy
  /home/build/meta-oe-core/meta/recipes-graphics/mesa/mesa.bb:do_prepare_recipe_sysroot
  /home/build/meta-oe-core/meta/recipes-graphics/mesa/mesa.bb:do_collect_spdx_deps
/home/build/meta-oe-core/meta/recipes-devtools/llvm/llvm_20.1.0.bb has unique dependees:
  /home/build/meta-oe-core/meta/recipes-graphics/mesa/mesa.bb:do_package_qa
  /home/build/meta-oe-core/meta/recipes-graphics/mesa/mesa.bb:do_create_package_spdx
It could be that one recipe provides something the other doesn't and should. The following provider and runtime provider differences may be helpful.
/home/build/meta-clang/recipes-devtools/clang/clang_git.bb has unique provides:
  clang
/home/build/meta-clang/recipes-devtools/clang/clang_git.bb has unique rprovides:
  lldb-server
  clang-libclang-cpp
  clang-doc
  ^clang-locale-.*
  clang-locale
  libclang
  liblldb
  clang-tools
  clang-libclang-python
  clang-dev
  clang
  clang-format
  clang-tidy
  clang-staticdev
  lldb
  clang-libllvm
  clang-src
  clang-lldb-python
  llvm-linker-tools
  clang-dbg
/home/build/meta-oe-core/meta/recipes-devtools/llvm/llvm_20.1.0.bb has unique provides:
  
/home/build/meta-oe-core/meta/recipes-devtools/llvm/llvm_20.1.0.bb has unique rprovides:
  llvm-src
  llvm-locale
  llvm-dbg
  llvm-liboptremarks
  llvm-staticdev
  llvm-llvmhello
  llvm
  ^llvm-locale-.*
  llvm-doc
  llvm-libllvm
  llvm-bugpointpasses
  llvm-dev
  llvm-liblto

This is due to being having an RDEPENDS on llvm (which lives in both oe-core and meta-clang) while being a bbappend on a recipe in oe-core

[danielfdickinson]

Copying the recipe-graphics/mesa directory from oe-core and stashing a pi-based bsp layer, and modifying per the bbappend in this PR (and adding wayland-protocols update) resolves the compile issue, but is obviously not a solution for the meta-raspberrypi layer.

[danielfdickinson]

Putting the following in your local.conf or distro/<distro_name>.conf file resolves the llvm conflicts with meta-clang

PROVIDES:pn-clang = "llvm"
RPROVIDES:clang-libllvm = "llvm-libllvm"

[crl-manoj]

@BassemMohsen Does this commit requires meta-clang? I am getting this error while building for scarthgap:

| | ../mesa-24.3.1/meson.build:815:12: ERROR: Dependency "libclc" not found, tried pkgconfig and cmake

[danielfdickinson]

@crl-manoj You may want to look at https://github.com/kraj/meta-clang/issues/896#issuecomment-3067897210 - I've discovered that mesa in OE-Core, this PR, as well as the more update PR in this repo for mesa update (https://github.com/agherzan/meta-raspberrypi/pull/1484) have undeclared dependencies on llvm. You can see a working mesa upgrade for walnascar (which is almost the same as what is needed for scarthgap), here: https://gitlab.com/yocto-doky/doky/-/tree/main/meta-bsp_doky_pi/recipes-graphics/mesa?ref_type=heads. HTH

[BassemMohsen]

@crl-manoj You may want to look at kraj/meta-clang#896 (comment) - I've discovered that mesa in OE-Core, this PR, as well as the more update PR in this repo for mesa update (#1484) have undeclared dependencies on llvm. You can see a working mesa upgrade for walnascar (which is almost the same as what is needed for scarthgap), here: https://gitlab.com/yocto-doky/doky/-/tree/main/meta-bsp_doky_pi/recipes-graphics/mesa?ref_type=heads. HTH

Interesting since their documentation claims you can compile mesa with GCC or clang https://docs.mesa3d.org/install.html#compiler

But the recipes your linked says, clang is required if it's built with packageconfig opencl

"opencl" requires libclc from meta-clang and spirv-tools from OE-Core

[danielfdickinson]

@BassemMohsen This (opencl) could be a misunderstanding on my part, due to the libclc from clang requirement when using clang. I will investigate further.

[BassemMohsen]

@BassemMohsen This (opencl) could be a misunderstanding on my part, due to the libclc from clang requirement when using clang. I will investigate further.

You can investigate by removing opencl from the package configs and see if it still require libclc during the build stage.

[crl-manoj]

@BassemMohsen This (opencl) could be a misunderstanding on my part, due to the libclc from clang requirement when using clang. I will investigate further.

You can investigate by removing opencl from the package configs and see if it still require libclc during the build stage.

libclc is required otherwise the build will fail.

PACKAGECONFIG:append:rpi = " gallium gallium-llvm vc4 v3d ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'x11', '', d)} ${@bb.utils.contains('DISTRO_FEATURES', 'vulkan', 'vulkan broadcom', '', d)}"
DRIDRIVERS:class-target:rpi = ""

# Remove unused patches
SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
           file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
"

SRC_URI[sha256sum] = "9c795900449ce5bc7c526ba0ab3532a22c3c951cab7e0dd9de5fcac41b0843af"
PV = "24.3.1"

# -Dglvnd is deprecated from true/false to enabled/disabled 
PACKAGECONFIG[glvnd] = "-Dglvnd=enabled, -Dglvnd=disabled, libglvnd"

# DRI3 note:
# DRI3 Build option is removed from meson.
PACKAGECONFIG:remove = "dri3"
unset PACKAGECONFIG[dri3]

DEPENDS += " wayland-protocols libclc python3-pyyaml python3-pyyaml-native"

RDEPENDS:libgl-mesa += " wayland-protocols"

FILES:libgbm += " ${libdir}/gbm/dri_gbm*.so"

FILES:libgl-mesa += " ${libdir}/libgallium*.so"

FILES:libgbm-dev += " ${includedir}/gbm.h"

[crl-manoj]

@BassemMohsen @leon-anavi

I can now run the Qt QML with eglfs (gpu rendering) in CM5 and the yocto image builds successfully. My only problem now is when I try to populate the sdk I get the LLVM is disabled error. (NOTE: I'm using the meta-clang with recommended conf:

PREFERRED_PROVIDER_llvm = "clang" PREFERRED_PROVIDER_llvm-native = "clang-native" PREFERRED_PROVIDER_nativesdk-llvm = "nativesdk-clang" PROVIDES:pn-clang = "llvm" PROVIDES:pn-clang-native = "llvm-native" PROVIDES:pn-nativesdk-clang = "nativesdk-llvm"

ERROR: | Run-time dependency libzstd found: YES 1.5.5 | Run-time dependency threads found: YES | Checking for function "pthread_setaffinity_np" with dependency threads: YES | Run-time dependency expat found: YES 2.6.4 | Library m found: YES | Run-time dependency libdrm_intel found: YES 2.4.123 | Run-time dependency libdrm found: YES 2.4.123 | Found CMake: NO | Run-time dependency libudev found: NO (tried pkgconfig and cmake) | | ../mesa-24.3.1/meson.build:1811:2: ERROR: Problem encountered: llvmpipe requires LLVM and is enabled, but LLVM is disabled.

Any ideas what might be happening? I feel like because I'm using clang llvm is not getting to sdk?

[danielfdickinson]

@BassemMohsen

From https://libclc.llvm.org:

libclc is intended to be used with the Clang compiler's OpenCL frontend. libclc is designed to be portable and extensible.

And as @crl-manoj points out libclc is a hard DEPENDS in the current mesa_xx.bb

This is not actually a hard requirement of mesa however. Doing:

DEPENDS += " ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland-protocols', '', d)} python3-pyyaml python3-pyyaml-native libxshmfence ${@bb.utils.contains('PACKAGECONFIG', 'opencl', 'libclc', '', d)} llvm llvm-native"

Removes the libclc dependency if one is not using opencl, and mesa still builds and works correctly.

[danielfdickinson]

@crl-manoj Try adding llvm and llvm-native to your DEPENDS.

[danielfdickinson]

@crl-manoj

But the recipes your linked says, clang is required if it's built with packageconfig opencl

opencl / libclc is not required to build mesa, therefore their statement that one can build mesa without llvm/clang or gcc is correct.

[BassemMohsen]

I agree with @danielfdickinson , it's better to keep meta-raspberrypi minimal and not bloat it.

Majority won't use opencl on RPI, and those who needs it can append the recipe to include it in their own custom layer.

Just remove opencl from package config and it will solve your sdk problem too

[crl-manoj]

@danielfdickinson @BassemMohsen Thanks I will try that. One thing I'm not clear about is does pull request require the meta-clang layer also or the openembedded supplied llvm_18.1.6.bb enough for scarthgap?

[BassemMohsen]

@danielfdickinson @BassemMohsen Thanks I will try that. One thing I'm not clear about is does pull request require the meta-clang layer also or the openembedded supplied llvm_18.1.6.bb enough for scarthgap?

I didn't use meta-clang in my build for Qt/QML and mesa 24.3.1 Only LLVM from Poky.

[crl-manoj]

@danielfdickinson @BassemMohsen Thanks I will try that. One thing I'm not clear about is does pull request require the meta-clang layer also or the openembedded supplied llvm_18.1.6.bb enough for scarthgap?

I didn't use meta-clang in my build for Qt/QML and mesa 24.3.1 Only LLVM from Poky.

That's strange. Would you mind me asking if QT/QML is run in -platform eglfs or wayland? (also Im using qt6)

[BassemMohsen]

@danielfdickinson @BassemMohsen Thanks I will try that. One thing I'm not clear about is does pull request require the meta-clang layer also or the openembedded supplied llvm_18.1.6.bb enough for scarthgap?

I didn't use meta-clang in my build for Qt/QML and mesa 24.3.1 Only LLVM from Poky.

That's strange. Would you mind me asking if QT/QML is run in -platform eglfs or wayland? (also Im using qt6)

I have skipped wayland, and using EGLFS directly, here's my qtbase_git.bbappend configs for RPI with EGLFS

PACKAGECONFIG += "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', ' kms', '', d)}"

PACKAGECONFIG_GL:rpi = "${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'gl', \
                        bb.utils.contains('DISTRO_FEATURES',     'opengl', 'eglfs gles2', \
                                                                       '', d), d)}"
PACKAGECONFIG_GL:append:rpi = "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', ' kms', '', d)}"
PACKAGECONFIG_GL:append:rpi = " gbm"
PACKAGECONFIG_FONTS:rpi = "fontconfig"
PACKAGECONFIG:append:rpi = " libinput examples tslib xkbcommon"
PACKAGECONFIG:remove:rpi = "tests"

OE_QTBASE_EGLFS_DEVICE_INTEGRATION:rpi = "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', 'eglfs_brcm', d)}"
EGLFS_DEVICE_INTEGRATION += " eglfs_brcm"

do_configure:prepend:rpi() {
    # Add the appropriate EGLFS_DEVICE_INTEGRATION
    if [ "${@d.getVar('OE_QTBASE_EGLFS_DEVICE_INTEGRATION')}" != "" ]; then
        echo "EGLFS_DEVICE_INTEGRATION = ${OE_QTBASE_EGLFS_DEVICE_INTEGRATION}" >> ${S}/mkspecs/oe-device-extra.pri
        echo "EGLFS_DEVICE_INTEGRATION = ${EGLFS_DEVICE_INTEGRATION}" >> ${S}/mkspecs/oe-device-extra.pri
    fi
}
RDEPENDS:${PN}:append:rpi = "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', ' userland', d)}"
DEPENDS:append:rpi = "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', ' userland', d)}"

What's strange? or what's your blocker?

[crl-manoj]

@danielfdickinson @BassemMohsen Thanks I will try that. One thing I'm not clear about is does pull request require the meta-clang layer also or the openembedded supplied llvm_18.1.6.bb enough for scarthgap?

I didn't use meta-clang in my build for Qt/QML and mesa 24.3.1 Only LLVM from Poky.

That's strange. Would you mind me asking if QT/QML is run in -platform eglfs or wayland? (also Im using qt6)

I have skipped wayland, and using EGLFS directly, here's my qtbase_git.bbappend configs for RPI with EGLFS

PACKAGECONFIG += "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', ' kms', '', d)}"

PACKAGECONFIG_GL:rpi = "${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'gl', \
                        bb.utils.contains('DISTRO_FEATURES',     'opengl', 'eglfs gles2', \
                                                                       '', d), d)}"
PACKAGECONFIG_GL:append:rpi = "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', ' kms', '', d)}"
PACKAGECONFIG_GL:append:rpi = " gbm"
PACKAGECONFIG_FONTS:rpi = "fontconfig"
PACKAGECONFIG:append:rpi = " libinput examples tslib xkbcommon"
PACKAGECONFIG:remove:rpi = "tests"

OE_QTBASE_EGLFS_DEVICE_INTEGRATION:rpi = "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', 'eglfs_brcm', d)}"
EGLFS_DEVICE_INTEGRATION += " eglfs_brcm"

do_configure:prepend:rpi() {
    # Add the appropriate EGLFS_DEVICE_INTEGRATION
    if [ "${@d.getVar('OE_QTBASE_EGLFS_DEVICE_INTEGRATION')}" != "" ]; then
        echo "EGLFS_DEVICE_INTEGRATION = ${OE_QTBASE_EGLFS_DEVICE_INTEGRATION}" >> ${S}/mkspecs/oe-device-extra.pri
        echo "EGLFS_DEVICE_INTEGRATION = ${EGLFS_DEVICE_INTEGRATION}" >> ${S}/mkspecs/oe-device-extra.pri
    fi
}
RDEPENDS:${PN}:append:rpi = "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', ' userland', d)}"
DEPENDS:append:rpi = "${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', ' userland', d)}"

What's strange? or what's your blocker?

Ok. Using your config for qt I was also able to generate the yocto image without error (and not using meta-clang also) but the sdk populating error is failing with same error:

| DEBUG: Python function extend_recipe_sysroot finished | DEBUG: Executing shell function do_configure | NOTE: Executing meson -Dshared-glapi=enabled -Dglx-read-only-text=true -Dplatforms=x11 -Degl=enabled -Dgallium-drivers=swrast,i915,iris,crocus,virgl -Dllvm=disabled -Dgbm=enabled -Dgles1=enabled -Dgles2=enabled -Dglvnd=disabled -Dimagination-srv=false -Dlmsensors=disabled -Dgallium-opencl=disabled -Dopencl-spirv=false -Dopengl=true -Dosmesa=false -Dperfetto=false -Dtools= -Dlibunwind=disabled -Dgallium-va=disabled -Dgallium-vdpau=disabled -Dvideo-codecs=all_free -Dvulkan-drivers= -Dvulkan-beta=false -Dgallium-xa=disabled... | The Meson build system | Version: 1.3.1 | Source dir: /data/x86_64-nativesdk-pokysdk-linux/nativesdk-mesa/24.3.1/mesa-24.3.1 | Build dir: /data/x86_64-nativesdk-pokysdk-linux/nativesdk-mesa/24.3.1/build | Build type: cross build | Project name: mesa | Project version: 24.3.1 | C compiler for the host machine: x86_64-pokysdk-linux-gcc -march=x86-64 --sysroot=/data/x86_64-nativesdk-pokysdk-linux/nativesdk-mesa/24.3.1/recipe-sysroot (gcc 13.4.0 "x86_64-pokysdk-linux-gcc (GCC) 13.4.0") | C linker for the host machine: x86_64-pokysdk-linux-gcc -march=x86-64 --sysroot=/data/x86_64-nativesdk-pokysdk-linux/nativesdk-mesa/24.3.1/recipe-sysroot ld.bfd 2.42.0.20240723 | C++ compiler for the host machine: x86_64-pokysdk-linux-g++ -march=x86-64 --sysroot=/data/x86_64-nativesdk-pokysdk-linux/nativesdk-mesa/24.3.1/recipe-sysroot (gcc 13.4.0 "x86_64-pokysdk-linux-g++ (GCC) 13.4.0") | C++ linker for the host machine: x86_64-pokysdk-linux-g++ -march=x86-64 --sysroot=/data/x86_64-nativesdk-pokysdk-linux/nativesdk-mesa/24.3.1/recipe-sysroot ld.bfd 2.42.0.20240723 | C compiler for the build machine: gcc (gcc 11.4.0 "gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0") | C linker for the build machine: gcc ld.bfd 2.38 | C++ compiler for the build machine: g++ (gcc 11.4.0 "g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0") | C++ linker for the build machine: g++ ld.bfd 2.38 | Build machine cpu family: x86_64 | Build machine cpu: x86_64 | Host machine cpu family: x86_64 | Host machine cpu: x86_64 | Target machine cpu family: x86_64 | Target machine cpu: x86_64 | Checking for size of "void*" : 8 | ../mesa-24.3.1/meson.build:178: WARNING: gallium-drivers=swrast is a deprecated alias for gallium-drivers=softpipe,llvmpipe and will be removed in version 25.0 | ../mesa-24.3.1/meson.build:516: WARNING: cannot auto-detect -mtls-dialect when cross-compiling, using compiler default | Dependency libglvnd skipped: feature glvnd disabled | Dependency vdpau skipped: feature gallium-vdpau disabled | Program glslangValidator found: NO | Dependency libva skipped: feature gallium-va disabled | Found pkg-config: YES (/data/x86_64-nativesdk-pokysdk-linux/nativesdk-mesa/24.3.1/recipe-sysroot-native/usr/bin/pkg-config) 0.29.2 | Found CMake: NO | Run-time dependency libclc found: NO (tried pkgconfig) | | ../mesa-24.3.1/meson.build:815:12: ERROR: Dependency "libclc" not found, tried pkgconfig |

[danielfdickinson]

../mesa-24.3.1/meson.build:815:12: ERROR: Dependency "libclc" not found, tried pkgconfig

This is where you need to do modify the DEPENDS so it has:

${@bb.utils.contains('PACKAGECONFIG', 'opencl', 'libclc', '', d)}

instead of just bare libclc. It's an error in OE-Core.

[danielfdickinson]

This also may need the same kind of thing (not 100% sure if this part matters).

PACKAGES =+ "libegl-mesa libegl-mesa-dev \
             libosmesa libosmesa-dev \
             libgl-mesa libgl-mesa-dev \
             libglx-mesa libglx-mesa-dev \
             libgbm libgbm-dev \
             libgles1-mesa libgles1-mesa-dev \
             libgles2-mesa libgles2-mesa-dev \
             libgles3-mesa libgles3-mesa-dev \
             ${@bb.utils.contains('PACKAGECONFIG', 'opencl', 'libopencl-mesa libopencl-mesa-dev', '', d)} \
             libxatracker libxatracker-dev \
             mesa-megadriver mesa-vulkan-drivers \
             mesa-vdpau-drivers mesa-tools \
            "

[crl-manoj]

../mesa-24.3.1/meson.build:815:12: ERROR: Dependency "libclc" not found, tried pkgconfig

This is where you need to do modify the DEPENDS so it has:

${@bb.utils.contains('PACKAGECONFIG', 'opencl', 'libclc', '', d)}

instead of just bare libclc. It's an error in OE-Core.

@danielfdickinson Did you meant in the mesa_%.bbappend file?

[danielfdickinson]

@crl-manoj I copied and edited the .bb file. I guess you could do (untested):

DEPENDS:remove = "${@bb.utils.contains('PACKAGECONFIG', 'opencl', '', 'libclc', d)}"

in a .bbappend. That removes libclc from the DEPENDS when there is no opencl in PACKAGECONFIG.

[BassemMohsen]

I will fix this today in my mesa bbappend today. Building SDK as we speak to replicate your error.

[crl-manoj]

@crl-manoj I copied and edited the .bb file. I guess you could do (untested):

DEPENDS:remove = "${@bb.utils.contains('PACKAGECONFIG', 'opencl', '', 'libclc', d)}"

in a .bbappend. That removes libclc from the DEPENDS when there is no opencl in PACKAGECONFIG.

I tried with this no luck, even did cleansstate just to see if previous cache was causing something. Also tried: ${@bb.utils.contains('PACKAGECONFIG', 'opencl', 'libclc', '', d)}

[crl-manoj]

@BassemMohsen @danielfdickinson It turns out the libclc package was getting pulled because of qemu. I just removed the qemu related stuffs and everything works for me. I don't know how this would be fixed but it's good for me as I don't use qemu.

Can put this in machine file or local.conf RDEPENDS:nativesdk-packagegroup-sdk-host:remove = "nativesdk-qemu nativesdk-qemu-helper"