Hi Dmitry,
On 12/4/25 1:57 PM, Dmitry Baryshkov wrote:
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://eur02.safelinks.protection.outlook.com/?
url=https%3A%2F%2Fdocs.mesa3d.org%2Frelnotes%2F25.3.0.html&data=05%7C02%7Cquentin.schulz%40cherry.de%7Cef95f0cf2aab4bf8340e08de3334a83f%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C639004498472249154%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CZj4op1xrwDAMi1uspOBLiY61%2BrWXhNTEDVSmrWk2HI%3D&reserved=0 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://
eur02.safelinks.protection.outlook.com/?
url=https%3A%2F%2Farchive.mesa3d.org%2Fmesa-
&data=05%7C02%7Cquentin.schulz%40cherry.de%7Cef95f0cf2aab4bf8340e08de3334a83f%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C639004498472262840%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UQEWyxA4x0kstzptuUFUZwbmd1c0ca76SxYl7IUjZN0%3D&reserved=0 ${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.
I don't like the PACKAGECONFIG choice mechanism for mesa we have today,
it's both too complex and doesn't allow enough flexibility. I don't need
to be building stuff I won't be using anyway. I see Yocto as a way to
build my embedded system where I control almost all of it, not as a
distro where you want everything you can imagine work. I would like to
revamp the whole PACKAGECONFIG thing for the mesa recipe but I don't
have anything in mind right now and I'll probably have shinier things to
chase :/
I'm also unsure how much it is true it's specific to a given vendor.
Rockchip has used/sold the same/similar IP for its ISP as used on some
recent IMX SoCs, maybe they'll have the same idea for their NPU and then
I'll have to select rockchip when I want to build Amlogic's NPU for example.
For Intel / AMD / NVIDIA it historically went somewhat okay, having just
a single vendor config entry.
Maybe because those systems are typically less constrained in terms of
RAM (initramfs) or storage space? But we did have some people complain
about it, c.f.
https://lore.kernel.org/poky/[email protected]/
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 would rather not. I for sure don't need Ethos NPU driver for my
Rockchip-based devices :) (considering Rockchip "made" their "own" NPU
IP, I assume they're going to keep it and not switch to Ethos for the
next-gen SoC).
Cheers,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#227295):
https://lists.openembedded.org/g/openembedded-core/message/227295
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]]
-=-=-=-=-=-=-=-=-=-=-=-
