On 02/12/2025 12:35, Quentin Schulz wrote:
Hi Dmitry,
On 12/2/25 1:49 AM, Dmitry Baryshkov via lists.openembedded.org wrote:
Upgrade Mesa to the latest release. Drop VDPAU tracker (dropped
upstream). Add support for ethosu and rocket Gallium drivers.
Thanks for doing that!
https://docs.mesa3d.org/relnotes/25.3.0.html for the release notes and
checksum.
I'm wondering if we shouldn't add the buildpath QA check to upstream
mesa's CI so that we don't have to patch things up for every release?
[...]
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-
graphics/mesa/mesa.inc
index 420ba2032b67..106767476ccc 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -18,10 +18,12 @@ SRC_URI = "https://archive.mesa3d.org/mesa-
${PV}.tar.xz \
file://0001-meson-misdetects-64bit-atomics-on-mips-
clang.patch \
file://0001-freedreno-don-t-encode-build-path-into-
binaries.patch \
file://0001-gfxstream-don-t-dump-genvk.py-args-to-
generated-file.patch \
+ file://0001-ethosu-drop-file-names-from-the-generated-
file.patch \
+ file://0002-rocket-drop-file-names-from-the-generated-
file.patch \
"
-SRC_URI[sha256sum] =
"bb6243e7a6f525febfa1e6ab50827ca4d4bfdad73812377b0ca9b6c50998b03e"
-PV = "25.2.5"
+SRC_URI[sha256sum] =
"0fd54fea7dbbddb154df05ac752b18621f26d97e27863db3be951417c6abe8ae"
+PV = "25.3.0"
Can we first bump to 25.2.7?
We won't update mesa in whinlatter to 25.3.x I assume, so it'd be easier
if we had a commit we could backport for whinlatter right now before the
release (or right after for the first dot release).
UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P<pver>\d+(\.\d+)+)"
@@ -104,12 +106,14 @@ PACKAGECONFIG[amd] = ""
PACKAGECONFIG[asahi] = ""
PACKAGECONFIG[broadcom] = ""
PACKAGECONFIG[etnaviv] = ",,python3-pycparser-native"
+PACKAGECONFIG[ethosu] = ""
PACKAGECONFIG[freedreno] = ""
PACKAGECONFIG[imagination] = "-Dimagination-srv=true,-Dimagination-
srv=false"
PACKAGECONFIG[intel] = ""
PACKAGECONFIG[lima] = ""
PACKAGECONFIG[nouveau] = ""
PACKAGECONFIG[panfrost] = ""
+PACKAGECONFIG[rockchip] = ""
I'm not sure about the naming here. Rockchip also has Lima-supported,
Panfrost-supported, Panthor-supporter, Panvk-supported GPU in various
SoCs. I would expect that when selecting rockchip it would enable
support for "everything" one can find on SoCs from this vendor, which
isn't necessarily a good thing (c.f. amd and intel bringing in too many
drivers you may not be interested in).
Yeah, I was trying to find a balance between having a per-driver
PACKAGECONFIG entries (which would be a nightmare for GL vs VK drivers)
and just declaring a "vendor", which enables all drivers, even if one
doesn't need it.
For Intel / AMD / NVIDIA it historically went somewhat okay, having just
a single vendor config entry.
For ARM-based systems... you know. We have 'lima' for the oldest
generation (gallium only), 'panfrost', which also enables panvk, now we
are getting 'ethosu'. I was tempted to merge all of them into a single
'arm' entry.
I guess I would just name it rocket?
Why not. Ross, any opinion from your side?
PACKAGECONFIG[svga] = ""
PACKAGECONFIG[tegra] = ""
PACKAGECONFIG[v3d] = ""
@@ -129,7 +133,7 @@ VULKAN_DRIVERS .=
"${@bb.utils.contains('PACKAGECONFIG', 'asahi libclc gallium-l
VULKAN_DRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'broadcom',
',broadcom', '', d)}"
VULKAN_DRIVERS .= "${@bb.utils.contains('PACKAGECONFIG',
'freedreno', ',freedreno', '', d)}"
VULKAN_DRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'virtio',
',gfxstream', '', d)}"
-VULKAN_DRIVERS .= "${@bb.utils.contains('PACKAGECONFIG',
'imagination', ',imagination-experimental', '', d)}"
+VULKAN_DRIVERS .= "${@bb.utils.contains('PACKAGECONFIG',
'imagination', ',imagination', '', d)}"
VULKAN_DRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'intel
libclc gallium-llvm', ',intel', '', d)}"
VULKAN_DRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'intel',
',intel_hasvk', '', d)}"
VULKAN_DRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'panfrost
libclc', ',panfrost', '', d)}"
@@ -171,6 +175,7 @@ GALLIUMDRIVERS = ""
GALLIUMDRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'asahi
libclc gallium-llvm', ',asahi', '', d)}"
GALLIUMDRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'intel',
',crocus', '', d)}"
GALLIUMDRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'etnaviv',
',etnaviv', '', d)}"
+GALLIUMDRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'ethosu',
Note for myself: move this one line up.
',ethosu', '', d)}"
GALLIUMDRIVERS .= "${@bb.utils.contains('PACKAGECONFIG',
'freedreno', ',freedreno', '', d)}"
GALLIUMDRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'intel',
',i915', '', d)}"
GALLIUMDRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'intel
libclc gallium-llvm', ',iris', '', d)}"
@@ -181,6 +186,7 @@ GALLIUMDRIVERS .=
"${@bb.utils.contains('PACKAGECONFIG', 'panfrost libclc', ',pa
GALLIUMDRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'amd
gallium-llvm', ',r300', '', d)}"
GALLIUMDRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'amd',
',r600', '', d)}"
GALLIUMDRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'amd
gallium-llvm', ',radeonsi', '', d)}"
+GALLIUMDRIVERS .= "${@bb.utils.contains('PACKAGECONFIG', 'rockchip',
',rocket', '', d)}"
Only useful if you enable teflon support as well, so we need teflon in
the PACKAGECONFIG check alongside rockchip (or rocket or whatever is the
chosen name for this PACKAGECONFIG option).
Nice idea. And for ethosu too.
Haven't had the time yet to dig into the diff between 25.2.7 and 25.3.0
release, so I don't know if we've missed on something.
Cheers,
Quentin
--
With best wishes
Dmitry
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#227293):
https://lists.openembedded.org/g/openembedded-core/message/227293
Mute This Topic: https://lists.openembedded.org/mt/116568929/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
