| Message ID | c64ef50a-10d3-4fe0-8025-96defb817e53@cherry.de |
|---|---|
| State | New |
| Headers | show |
| Series | How to fix Panfrost support in mesa? | expand |
Thank you for your submission. Patchtest identified one or more issues with the patch. Please see the log below for more information: --- Testing patch /home/patchtest/share/mboxes/How-to-fix-Panfrost-support-in-mesa.patch FAIL: test Signed-off-by presence: Mbox is missing Signed-off-by. Add it manually or with "git commit --amend -s" (test_mbox.TestMbox.test_signed_off_by_presence) FAIL: test commit message user tags: Mbox includes one or more GitHub-style username tags. Ensure that any "@" symbols are stripped out of usernames (test_mbox.TestMbox.test_commit_message_user_tags) FAIL: test mbox format: Series has malformed diff lines. Create the series again using git-format-patch and ensure it applies using git am (test_mbox.TestMbox.test_mbox_format) FAIL: test shortlog format: Commit shortlog (first line of commit message) should follow the format "<target>: <summary>" (test_mbox.TestMbox.test_shortlog_format) PASS: test author valid (test_mbox.TestMbox.test_author_valid) PASS: test commit message presence (test_mbox.TestMbox.test_commit_message_presence) PASS: test max line length (test_metadata.TestMetadata.test_max_line_length) PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade) PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length) PASS: test target mailing list (test_mbox.TestMbox.test_target_mailing_list) SKIP: pretest pylint: Python-unidiff parse error (test_python_pylint.PyLint.pretest_pylint) SKIP: pretest src uri left files: No modified recipes, skipping pretest (test_metadata.TestMetadata.pretest_src_uri_left_files) SKIP: test CVE check ignore: No modified recipes or older target branch, skipping test (test_metadata.TestMetadata.test_cve_check_ignore) SKIP: test CVE tag format: Parse error Unexpected hunk found: @@ -173,12 +173,13 @@ GALLIUMDRIVERS:append = SKIP: test Signed-off-by presence: Parse error Unexpected hunk found: @@ -173,12 +173,13 @@ GALLIUMDRIVERS:append = SKIP: test Upstream-Status presence: Parse error Unexpected hunk found: @@ -173,12 +173,13 @@ GALLIUMDRIVERS:append = SKIP: test bugzilla entry format: No bug ID found (test_mbox.TestMbox.test_bugzilla_entry_format) SKIP: test lic files chksum modified not mentioned: No modified recipes, skipping test (test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned) SKIP: test lic files chksum presence: No added recipes, skipping test (test_metadata.TestMetadata.test_lic_files_chksum_presence) SKIP: test license presence: No added recipes, skipping test (test_metadata.TestMetadata.test_license_presence) SKIP: test pylint: Python-unidiff parse error (test_python_pylint.PyLint.test_pylint) SKIP: test series merge on head: Merge test is disabled for now (test_mbox.TestMbox.test_series_merge_on_head) SKIP: test src uri left files: No modified recipes, skipping pretest (test_metadata.TestMetadata.test_src_uri_left_files) SKIP: test summary presence: No added recipes, skipping test (test_metadata.TestMetadata.test_summary_presence) --- Please address the issues identified and submit a new revision of the patch, or alternatively, reply to this email with an explanation of why the patch should be accepted. If you believe these results are due to an error in patchtest, please submit a bug at https://bugzilla.yoctoproject.org/ (use the 'Patchtest' category under 'Yocto Project Subprojects'). For more information on specific failures, see: https://wiki.yoctoproject.org/wiki/Patchtest. Thank you!
On Wed, 11 Jun 2025 at 18:33, Quentin Schulz <quentin.schulz@cherry.de> wrote: > > Hi all, > > I've been trying to add support for Panthor (Panfrost for Mali Valhall > and later as far as I understood) to meta-rockchip a few months ago > already and attempting again. > > I had managed to do something for an old mesa release but it doesn't > work anymore. Worse, it seems that the current Panfrost support is broken :) That's an interesting claim. I hope you mean 'broken in OE-Core', not 'broken in Mesa'. > > For starters, the build doesn't succeed unless we have both panfrost and > libclc PACKAGECONFIG enabled. I believe this is due to 20970bcd9652 > ("panfrost: Add base of OpenCL C infrastructure") merged in 25.1.0. So > there are some changes required in mesa recipe to force libclc > PACKAGECONFIG *in addition* to the panfrost PACKAGECONFIG for the whole > thing to build. This shouldn't be too difficult though. This seems almost correct. > > However, reading the aforementioned commit revealed something else (or > maybe I misunderstood :) ). It appears that LLVM is now required at > build time for the Gallium driver, so that would make panfrost part of > GALLIUMDRIVERS_LLVM now. The issue is that it builds with and without > gallium-llvm PACKAGECONFIG, and it seems to be running glmark2-es2-drm > just fine on RK3588 (G610; Valhall). So I'm not sure what to do here? If I understand correctly, panfrost requires at least mesa-clc / panfrost-compile to be built for the build system. We support building the former, but we don't support building the latter. The quoted commit has the options to be passed to the meson when building the 'host' binaries aka mesa-native and when cross-building mesa. Though I'm really surprised that building of panfrost works w/o gallium-llvm in the current mesa.inc > Making it part of gallium-llvm drivers brings in clang{,-native} among > other things which is horrifyingly long to compile. I think clang-native would be required at least. If you implement precomp-compilers in some way, the correct build options would be: PACKAGECONFIG:append:pn-mesa-native = " panfrost libclc gallium-llvm" PACKAGECONFIG:append:pn-mesa = " panfrost" Note, currently we don't pass -Dmesa-clc=system if libclc is disabled. Most likely that needs to be changed too. > > Additionally, according to the same previously mentioned commit, there's > *some* OpenCL support now through rusticl for Panfrost. I wasn't able to > compile it though (seems like Zoltan is trying to fix it already but the > patches didn't work for me though I am testing on top of poky master > 5b006dbc3d8669e0530ec3d633982617923ae215 due to meta-rockchip not having > migrated to the new kernel-fit-image mechanism just yet). > I see that we recently forced the opencl dependency on Asahi Vulkan and > Gallium drivers, though I couldn't decipher from mesa git repo whether > that is actually required or if it's just to bring in OpenCL always. > I assume we could be doing something similar to Panfrost but I'm not > sure it is worth it (especially considering that the commit listed above > says they are only planning to support Bifrost and Valhall versions, > which doesn't cover the Txxx (Midgard) Mali generation. I think the commit requiring OpenCL to build the Asahi driver is incorrect. > > So.. what to do with this panthor/panfrost driver for mesa in OE-Core? > > My attempt at making panthor a gallium-llvm driver: > [skipped] This looks correct from the code POV, but I'm not sure if moving panfrost to gallium-llvm drivers is correct. If I have time, I will try to review the whole gallium-llvm story. > > On a side note, I'm also not entirely sure why we need > softpipe,llvmpipe,r300,nouveau always enabled? > Can't we make softpipe the default only when llvmpipe isn't enabled? > Do we really need r300 and nouveau always compiled? Can't we have a > PACKAGECONFIG for those too? I see there's an amd PACKAGECONFIG already, > maybe we can use that for r300 as well? For nouveau, a new nvidia > PACKAGECONFIG maybe? This is really a good idea. Please send those, idepdendently of your panfrost / panvk work. > > Thanks! > Quentin
Hi Dmitry, On 6/11/25 10:08 PM, Dmitry Baryshkov wrote: > On Wed, 11 Jun 2025 at 18:33, Quentin Schulz <quentin.schulz@cherry.de> wrote: >> >> Hi all, >> >> I've been trying to add support for Panthor (Panfrost for Mali Valhall >> and later as far as I understood) to meta-rockchip a few months ago >> already and attempting again. >> >> I had managed to do something for an old mesa release but it doesn't >> work anymore. Worse, it seems that the current Panfrost support is broken :) > > That's an interesting claim. I hope you mean 'broken in OE-Core', not > 'broken in Mesa'. > Yes, I meant in the OE-Core recipe :) >> >> For starters, the build doesn't succeed unless we have both panfrost and >> libclc PACKAGECONFIG enabled. I believe this is due to 20970bcd9652 >> ("panfrost: Add base of OpenCL C infrastructure") merged in 25.1.0. So >> there are some changes required in mesa recipe to force libclc >> PACKAGECONFIG *in addition* to the panfrost PACKAGECONFIG for the whole >> thing to build. This shouldn't be too difficult though. > > This seems almost correct. > >> >> However, reading the aforementioned commit revealed something else (or >> maybe I misunderstood :) ). It appears that LLVM is now required at >> build time for the Gallium driver, so that would make panfrost part of >> GALLIUMDRIVERS_LLVM now. The issue is that it builds with and without >> gallium-llvm PACKAGECONFIG, and it seems to be running glmark2-es2-drm >> just fine on RK3588 (G610; Valhall). So I'm not sure what to do here? > > If I understand correctly, panfrost requires at least mesa-clc / > panfrost-compile to be built for the build system. We support building Not sure? I believe panfrost-compile is always used (either by taking it from the host or building it) whenever the gallium or vulkan dirver (or tools) for panfrost is enabled? > the former, but we don't support building the latter. > The quoted commit has the options to be passed to the meson when > building the 'host' binaries aka mesa-native and when cross-building > mesa. > > Though I'm really surprised that building of panfrost works w/o > gallium-llvm in the current mesa.inc > For the target recipe, gallium-llvm isn't selected right now, and adding libclc is enough to make it pass the build. But we also set it for both target (by adding it manually) and native (already there, c.f. PACKAGECONFIG:append:class-native) recipes. For the native recipe, gallium-llvm is always there (c.f. PACKAGECONFIG:append:class-native). So that might explain why you're surprised. >> Making it part of gallium-llvm drivers brings in clang{,-native} among >> other things which is horrifyingly long to compile. > > I think clang-native would be required at least. > > If you implement precomp-compilers in some way, the correct build > options would be: > I'm not sure it's necessarily worth it as one would need to have precomp-compilers + all drivers guarding this precomp-compilers (right now panfrost and asahi it seems) in the native recipe as well so that the target recipe could use it. > PACKAGECONFIG:append:pn-mesa-native = " panfrost libclc gallium-llvm" libclc and gallium-llvm are already part of the mesa-native PACKAGECONFIG, I don't have panfrost there though and I would need it to make use of precom-compiler=system on the target recipe. Considering we would need panfrost in mesa-native (+ precomp_compiler) to be able to build panfrost on target, does it mean we should always have panfrost in native (in OE-Core) to avoid having to figure this is required from target recipe's perspective? or in BSP layers? > PACKAGECONFIG:append:pn-mesa = " panfrost" > > Note, currently we don't pass -Dmesa-clc=system if libclc is disabled. > Most likely that needs to be changed too. > The issue is that if mesa-clc=system when libclc PACKAGECONFIG is disabled, we still need mesa-native (with libclc PACKAGECONFIG) otherwise it won't be found. However, maybe with this we can lighten up the dependencies in the target recipe in PACKAGECONFIG[libclc] to essentially only mesa-native? It seems like maybe some PACKAGECONFIG (e.g. libclc, the upcoming precomp_compiler, etc...) should be native-only? What's the point of libclc for the target recipe for example? Is there even a point making those PACKAGECONFIG options maybe we could simply hardcode them in EXTRA_OEMESON for example for the target (always =system for mesa-clc and precomp-compiler for the target recipe for example?) I "quickly" hacked something together that would make panfrost build without requiring to add libclc to the target PACKAGECONFIG. This does a few things like using precomp-compilers from mesa-native and mesa-clc from mesa-native without requiring either PACKAGECONFIG in target recipe, forcefully adds mesa-native as dependency of target recipe (though maybe should only be added when libclc or precomp-compilers is not in target's PACKAGECONFIG?) and removes libclc spirv-tools spirv-llvm-translator from build dependencies for the target (panfrost builds fine, but is it correct?). """ diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc index 9b41955132..746b5f7be9 100644 --- a/meta/recipes-graphics/mesa/mesa.inc +++ b/meta/recipes-graphics/mesa/mesa.inc @@ -97,7 +97,7 @@ INHIBIT_DEFAULT_RUST_DEPS = "${@bb.utils.contains('PACKAGECONFIG', 'opencl', '', PACKAGECONFIG:append:x86 = " libclc gallium-llvm intel amd svga" PACKAGECONFIG:append:x86-64 = " libclc gallium-llvm intel amd svga" PACKAGECONFIG:append:i686 = " libclc gallium-llvm intel amd svga" -PACKAGECONFIG:append:class-native = " libclc gallium-llvm amd svga" +PACKAGECONFIG:append:class-native = " libclc gallium-llvm amd svga asahi panfrost precomp_compiler" # "gbm" requires "opengl" PACKAGECONFIG[gbm] = "-Dgbm=enabled,-Dgbm=disabled" @@ -194,10 +194,18 @@ INSTALL_MESA_CLC = "false" INSTALL_MESA_CLC:class-native = "true" MESA_NATIVE = "mesa-native" MESA_NATIVE:class-native = "" +MESA_PRECOMP_COMPILER = "system" +MESA_PRECOMP_COMPILER:class-native = "enabled" +INSTALL_MESA_PRECOMP_COMPILER = "false" +INSTALL_MESA_PRECOMP_COMPILER:class-native = "true" +MESA_CLC_DEPS = "mesa-native" +MESA_CLC_DEPS:class-native = "libclc spirv-tools spirv-llvm-translator" PACKAGECONFIG[gallium] = "-Dgallium-drivers=${@strip_comma('${GALLIUMDRIVERS}')}, -Dgallium-drivers='', libdrm" PACKAGECONFIG[gallium-llvm] = "-Dllvm=enabled -Dshared-llvm=enabled, -Dllvm=disabled, llvm llvm-native elfutils" -PACKAGECONFIG[libclc] = "-Dmesa-clc=${MESA_CLC} -Dinstall-mesa-clc=${INSTALL_MESA_CLC} -Dmesa-clc-bundle-headers=enabled,,libclc spirv-tools spirv-llvm-translator ${MESA_NATIVE}" +DEPENDS:append:class-target = "mesa-native" +PACKAGECONFIG[libclc] = "-Dmesa-clc=${MESA_CLC} -Dinstall-mesa-clc=${INSTALL_MESA_CLC} -Dmesa-clc-bundle-headers=enabled,-Dmesa-clc=system,${MESA_CLC_DEPS}" +PACKAGECONFIG[precomp_compiler] = "-Dprecomp-compiler=${MESA_PRECOMP_COMPILER} -Dinstall-precomp-compiler=${INSTALL_MESA_PRECOMP_COMPILER},-Dprecomp-compiler=system,${MESA_NATIVE}" PACKAGECONFIG[va] = "-Dgallium-va=enabled,-Dgallium-va=disabled,libva-initial" PACKAGECONFIG[vdpau] = "-Dgallium-vdpau=enabled,-Dgallium-vdpau=disabled,libvdpau" """ To be honest, at this point it's quite difficult for me to understand what's going on. I have zero experience with mesa, very little with meson and somehow panfrost builds with wildly different configurations and seems to run fine as well with glmark2-es2-drm/kmscube, so not sure when things are supposed to fail when misconfigured at build time :/ I'm not sure everything I'm writing here makes sense. [...] >> >> On a side note, I'm also not entirely sure why we need >> softpipe,llvmpipe,r300,nouveau always enabled? >> Can't we make softpipe the default only when llvmpipe isn't enabled? >> Do we really need r300 and nouveau always compiled? Can't we have a >> PACKAGECONFIG for those too? I see there's an amd PACKAGECONFIG already, >> maybe we can use that for r300 as well? For nouveau, a new nvidia >> PACKAGECONFIG maybe? > > This is really a good idea. Please send those, idepdendently of your > panfrost / panvk work. > OK, will try to come up with something :) Cheers, Quentin
On 12/06/2025 14:21, Quentin Schulz wrote: > Hi Dmitry, > > On 6/11/25 10:08 PM, Dmitry Baryshkov wrote: >> On Wed, 11 Jun 2025 at 18:33, Quentin Schulz >> <quentin.schulz@cherry.de> wrote: >>> >>> Hi all, >>> >>> I've been trying to add support for Panthor (Panfrost for Mali Valhall >>> and later as far as I understood) to meta-rockchip a few months ago >>> already and attempting again. >>> >>> I had managed to do something for an old mesa release but it doesn't >>> work anymore. Worse, it seems that the current Panfrost support is >>> broken :) >> >> That's an interesting claim. I hope you mean 'broken in OE-Core', not >> 'broken in Mesa'. >> > > Yes, I meant in the OE-Core recipe :) > >>> >>> For starters, the build doesn't succeed unless we have both panfrost and >>> libclc PACKAGECONFIG enabled. I believe this is due to 20970bcd9652 >>> ("panfrost: Add base of OpenCL C infrastructure") merged in 25.1.0. So >>> there are some changes required in mesa recipe to force libclc >>> PACKAGECONFIG *in addition* to the panfrost PACKAGECONFIG for the whole >>> thing to build. This shouldn't be too difficult though. >> >> This seems almost correct. >> >>> >>> However, reading the aforementioned commit revealed something else (or >>> maybe I misunderstood :) ). It appears that LLVM is now required at >>> build time for the Gallium driver, so that would make panfrost part of >>> GALLIUMDRIVERS_LLVM now. The issue is that it builds with and without >>> gallium-llvm PACKAGECONFIG, and it seems to be running glmark2-es2-drm >>> just fine on RK3588 (G610; Valhall). So I'm not sure what to do here? >> >> If I understand correctly, panfrost requires at least mesa-clc / >> panfrost-compile to be built for the build system. We support building > > Not sure? I believe panfrost-compile is always used (either by taking it > from the host or building it) whenever the gallium or vulkan dirver (or > tools) for panfrost is enabled? Yes. The idea is to build it only for the host, removing the need for the target libclc / llvm / clang. > >> the former, but we don't support building the latter. >> The quoted commit has the options to be passed to the meson when >> building the 'host' binaries aka mesa-native and when cross-building >> mesa. >> >> Though I'm really surprised that building of panfrost works w/o >> gallium-llvm in the current mesa.inc >> > > For the target recipe, gallium-llvm isn't selected right now, and adding > libclc is enough to make it pass the build. But we also set it for both > target (by adding it manually) and native (already there, c.f. > PACKAGECONFIG:append:class-native) recipes. Okay, you are selecting gallium-llvm manually (for the target build). Then it makes sense that the build passes. > > For the native recipe, gallium-llvm is always there (c.f. > PACKAGECONFIG:append:class-native). So that might explain why you're > surprised. > >>> Making it part of gallium-llvm drivers brings in clang{,-native} among >>> other things which is horrifyingly long to compile. >> >> I think clang-native would be required at least. >> >> If you implement precomp-compilers in some way, the correct build >> options would be: >> > > I'm not sure it's necessarily worth it as one would need to have > precomp-compilers + all drivers guarding this precomp-compilers (right > now panfrost and asahi it seems) in the native recipe as well so that > the target recipe could use it. I was thinking about enabling corresponding options in the BSP layer. But... then came the second thought. In the BSP layer we can use target overrides to select options for the target mesa, but we can't similarily change class-native PACKAGECONFIG. > >> PACKAGECONFIG:append:pn-mesa-native = " panfrost libclc gallium-llvm" > > libclc and gallium-llvm are already part of the mesa-native > PACKAGECONFIG, I don't have panfrost there though and I would need it to > make use of precom-compiler=system on the target recipe. > > Considering we would need panfrost in mesa-native (+ precomp_compiler) > to be able to build panfrost on target, does it mean we should always > have panfrost in native (in OE-Core) to avoid having to figure this is > required from target recipe's perspective? or in BSP layers? It seems so...I can't find a better way to handle it, provided we want BSP layers to pass yocto-check-layer requirements. > >> PACKAGECONFIG:append:pn-mesa = " panfrost" >> >> Note, currently we don't pass -Dmesa-clc=system if libclc is disabled. >> Most likely that needs to be changed too. >> > > The issue is that if mesa-clc=system when libclc PACKAGECONFIG is > disabled, we still need mesa-native (with libclc PACKAGECONFIG) > otherwise it won't be found. Yes, this is expected. > > However, maybe with this we can lighten up the dependencies in the > target recipe in PACKAGECONFIG[libclc] to essentially only mesa-native? Yes. > > It seems like maybe some PACKAGECONFIG (e.g. libclc, the upcoming > precomp_compiler, etc...) should be native-only? What's the point of > libclc for the target recipe for example? Is there even a point making > those PACKAGECONFIG options maybe we could simply hardcode them in > EXTRA_OEMESON for example for the target (always =system for mesa-clc > and precomp-compiler for the target recipe for example?) libclc is required for RustiCL support. But then you can simply fold libclc into opencl. > > I "quickly" hacked something together that would make panfrost build > without requiring to add libclc to the target PACKAGECONFIG. This does a > few things like using precomp-compilers from mesa-native and mesa-clc > from mesa-native without requiring either PACKAGECONFIG in target > recipe, forcefully adds mesa-native as dependency of target recipe > (though maybe should only be added when libclc or precomp-compilers is > not in target's PACKAGECONFIG?) and removes libclc spirv-tools spirv- > llvm-translator from build dependencies for the target (panfrost builds > fine, but is it correct?). > > """ > diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes- > graphics/mesa/mesa.inc > index 9b41955132..746b5f7be9 100644 > --- a/meta/recipes-graphics/mesa/mesa.inc > +++ b/meta/recipes-graphics/mesa/mesa.inc > @@ -97,7 +97,7 @@ INHIBIT_DEFAULT_RUST_DEPS = > "${@bb.utils.contains('PACKAGECONFIG', 'opencl', '', > PACKAGECONFIG:append:x86 = " libclc gallium-llvm intel amd svga" > PACKAGECONFIG:append:x86-64 = " libclc gallium-llvm intel amd svga" > PACKAGECONFIG:append:i686 = " libclc gallium-llvm intel amd svga" > -PACKAGECONFIG:append:class-native = " libclc gallium-llvm amd svga" > +PACKAGECONFIG:append:class-native = " libclc gallium-llvm amd svga > asahi panfrost precomp_compiler" > > # "gbm" requires "opengl" > PACKAGECONFIG[gbm] = "-Dgbm=enabled,-Dgbm=disabled" > @@ -194,10 +194,18 @@ INSTALL_MESA_CLC = "false" > INSTALL_MESA_CLC:class-native = "true" > MESA_NATIVE = "mesa-native" > MESA_NATIVE:class-native = "" > +MESA_PRECOMP_COMPILER = "system" > +MESA_PRECOMP_COMPILER:class-native = "enabled" > +INSTALL_MESA_PRECOMP_COMPILER = "false" > +INSTALL_MESA_PRECOMP_COMPILER:class-native = "true" > +MESA_CLC_DEPS = "mesa-native" > +MESA_CLC_DEPS:class-native = "libclc spirv-tools spirv-llvm-translator" > > PACKAGECONFIG[gallium] = "-Dgallium- > drivers=${@strip_comma('${GALLIUMDRIVERS}')}, -Dgallium-drivers='', libdrm" > PACKAGECONFIG[gallium-llvm] = "-Dllvm=enabled -Dshared-llvm=enabled, - > Dllvm=disabled, llvm llvm-native elfutils" > -PACKAGECONFIG[libclc] = "-Dmesa-clc=${MESA_CLC} -Dinstall-mesa- > clc=${INSTALL_MESA_CLC} -Dmesa-clc-bundle-headers=enabled,,libclc spirv- > tools spirv-llvm-translator ${MESA_NATIVE}" > +DEPENDS:append:class-target = "mesa-native" > +PACKAGECONFIG[libclc] = "-Dmesa-clc=${MESA_CLC} -Dinstall-mesa- > clc=${INSTALL_MESA_CLC} -Dmesa-clc-bundle-headers=enabled,-Dmesa- > clc=system,${MESA_CLC_DEPS}" > +PACKAGECONFIG[precomp_compiler] = "-Dprecomp- > compiler=${MESA_PRECOMP_COMPILER} -Dinstall-precomp- > compiler=${INSTALL_MESA_PRECOMP_COMPILER},-Dprecomp-compiler=system, > ${MESA_NATIVE}" I'm not sure if we need a separate option here. I like your idea of folding this into EXTRA_OEMESON. > PACKAGECONFIG[va] = "-Dgallium-va=enabled,-Dgallium-va=disabled,libva- > initial" > PACKAGECONFIG[vdpau] = "-Dgallium-vdpau=enabled,-Dgallium- > vdpau=disabled,libvdpau" > """ > > To be honest, at this point it's quite difficult for me to understand > what's going on. I have zero experience with mesa, very little with > meson and somehow panfrost builds with wildly different configurations > and seems to run fine as well with glmark2-es2-drm/kmscube, so not sure > when things are supposed to fail when misconfigured at build time :/ > > I'm not sure everything I'm writing here makes sense. It definitely does make sense for me. > > [...] > >>> >>> On a side note, I'm also not entirely sure why we need >>> softpipe,llvmpipe,r300,nouveau always enabled? >>> Can't we make softpipe the default only when llvmpipe isn't enabled? I forgot to comment here. I'd say, please don't turn it off automatically (or at least allow it to be reenabled). I've seen several times the case when llvmpipe crashes, but softpipe works. I don't remember what was the cause, but it's nice to have both available. >>> Do we really need r300 and nouveau always compiled? Can't we have a >>> PACKAGECONFIG for those too? I see there's an amd PACKAGECONFIG already, >>> maybe we can use that for r300 as well? For nouveau, a new nvidia >>> PACKAGECONFIG maybe? >> >> This is really a good idea. Please send those, idepdendently of your >> panfrost / panvk work. >> > > OK, will try to come up with something :) > > Cheers, > Quentin
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc index 4b1e427ad5..8880330c9c 100644 --- a/meta/recipes-graphics/mesa/mesa.inc +++ b/meta/recipes-graphics/mesa/mesa.inc @@ -110,17 +110,17 @@ PACKAGECONFIG[wayland] = ",,wayland-native wayland libdrm wayland-protocols" VULKAN_DRIVERS_AMD = "${@bb.utils.contains('PACKAGECONFIG', 'amd', ',amd', '', d)}" VULKAN_DRIVERS_ASAHI = "${@bb.utils.contains('PACKAGECONFIG', 'asahi libclc opencl', ',asahi', '', d)}" VULKAN_DRIVERS_INTEL = "${@bb.utils.contains('PACKAGECONFIG', 'intel libclc', ',intel', '', d)}" +VULKAN_DRIVERS_PANFROST = "${@bb.utils.contains('PACKAGECONFIG', 'libclc panfrost', ',panfrost', '', d)}" VULKAN_DRIVERS_SWRAST = ",swrast" # Crashes on x32 VULKAN_DRIVERS_SWRAST:x86-x32 = "" -VULKAN_DRIVERS_LLVM = "${VULKAN_DRIVERS_SWRAST}${VULKAN_DRIVERS_AMD}${VULKAN_DRIVERS_ASAHI}${VULKAN_DRIVERS_INTEL}" +VULKAN_DRIVERS_LLVM = "${VULKAN_DRIVERS_SWRAST}${VULKAN_DRIVERS_AMD}${VULKAN_DRIVERS_ASAHI}${VULKAN_DRIVERS_INTEL}${VULKAN_DRIVERS_PANFROST}" VULKAN_DRIVERS = "" VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG',
Hi all, I've been trying to add support for Panthor (Panfrost for Mali Valhall and later as far as I understood) to meta-rockchip a few months ago already and attempting again. I had managed to do something for an old mesa release but it doesn't work anymore. Worse, it seems that the current Panfrost support is broken :) For starters, the build doesn't succeed unless we have both panfrost and libclc PACKAGECONFIG enabled. I believe this is due to 20970bcd9652 ("panfrost: Add base of OpenCL C infrastructure") merged in 25.1.0. So there are some changes required in mesa recipe to force libclc PACKAGECONFIG *in addition* to the panfrost PACKAGECONFIG for the whole thing to build. This shouldn't be too difficult though. However, reading the aforementioned commit revealed something else (or maybe I misunderstood :) ). It appears that LLVM is now required at build time for the Gallium driver, so that would make panfrost part of GALLIUMDRIVERS_LLVM now. The issue is that it builds with and without gallium-llvm PACKAGECONFIG, and it seems to be running glmark2-es2-drm just fine on RK3588 (G610; Valhall). So I'm not sure what to do here? Making it part of gallium-llvm drivers brings in clang{,-native} among other things which is horrifyingly long to compile. Additionally, according to the same previously mentioned commit, there's *some* OpenCL support now through rusticl for Panfrost. I wasn't able to compile it though (seems like Zoltan is trying to fix it already but the patches didn't work for me though I am testing on top of poky master 5b006dbc3d8669e0530ec3d633982617923ae215 due to meta-rockchip not having migrated to the new kernel-fit-image mechanism just yet). I see that we recently forced the opencl dependency on Asahi Vulkan and Gallium drivers, though I couldn't decipher from mesa git repo whether that is actually required or if it's just to bring in OpenCL always. I assume we could be doing something similar to Panfrost but I'm not sure it is worth it (especially considering that the commit listed above says they are only planning to support Bifrost and Valhall versions, which doesn't cover the Txxx (Midgard) Mali generation. So.. what to do with this panthor/panfrost driver for mesa in OE-Core? My attempt at making panthor a gallium-llvm driver: """ 'freedreno', ',freedreno', '', d)}" VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'broadcom', ',broadcom', '', d)}" VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'gallium-llvm', '${VULKAN_DRIVERS_LLVM}', '', d)}" VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'imagination', ',imagination-experimental', '', d)}" -VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'panfrost', ',panfrost', '', d)}" PACKAGECONFIG[vulkan] = "-Dvulkan-drivers=${@strip_comma('${VULKAN_DRIVERS}')}, -Dvulkan-drivers='',glslang-native vulkan-loader vulkan-headers" # mesa development and testing tools support, per driver @@ -173,12 +173,13 @@ GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'zink', ',zink', GALLIUMDRIVERS_ASAHI = "${@bb.utils.contains('PACKAGECONFIG', 'asahi libclc opencl', ',asahi', '', d)}" GALLIUMDRIVERS_IRIS = "${@bb.utils.contains('PACKAGECONFIG', 'intel libclc', ',iris', '', d)}" +GALLIUMDRIVERS_PANFROST = "${@bb.utils.contains('PACKAGECONFIG', 'libclc panfrost', ',panfrost', '', d)}" GALLIUMDRIVERS_RADEONSI = "${@bb.utils.contains('PACKAGECONFIG', 'amd', ',radeonsi', '', d)}" GALLIUMDRIVERS_LLVMPIPE = ",llvmpipe" # llvmpipe crashes on x32 GALLIUMDRIVERS_LLVMPIPE:x86-x32 = "" GALLIUMDRIVERS_SVGA = "${@bb.utils.contains('PACKAGECONFIG', 'svga', ',svga', '', d)}" -GALLIUMDRIVERS_LLVM = ",r300,nouveau${GALLIUMDRIVERS_LLVMPIPE}${GALLIUMDRIVERS_ASAHI}${GALLIUMDRIVERS_IRIS}${GALLIUMDRIVERS_RADEONSI}${GALLIUMDRIVERS_SVGA}" +GALLIUMDRIVERS_LLVM = ",r300,nouveau${GALLIUMDRIVERS_LLVMPIPE}${GALLIUMDRIVERS_ASAHI}${GALLIUMDRIVERS_IRIS}${GALLIUMDRIVERS_PANFROST}${GALLIUMDRIVERS_RADEONSI}${GALLIUMDRIVERS_SVGA}" PACKAGECONFIG[amd] = "" PACKAGECONFIG[svga] = "" @@ -212,7 +213,6 @@ PACKAGECONFIG[lima] = "" GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima', '', d)}" PACKAGECONFIG[panfrost] = "" -GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'panfrost', ',panfrost', '', d)}" PACKAGECONFIG[tegra] = "" GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'tegra', ',tegra,nouveau', '', d)}" """ On a side note, I'm also not entirely sure why we need softpipe,llvmpipe,r300,nouveau always enabled? Can't we make softpipe the default only when llvmpipe isn't enabled? Do we really need r300 and nouveau always compiled? Can't we have a PACKAGECONFIG for those too? I see there's an amd PACKAGECONFIG already, maybe we can use that for r300 as well? For nouveau, a new nvidia PACKAGECONFIG maybe? Thanks! Quentin