Bump mesa from 25.2.4 to latest stable point release in the 26.0.x
series.
Drop 001-gallivm-support-LLVM-21.patch which has been merged
upstream. Refresh the remaining downstream patches
(100-meson-allow-using-LLVM-as-embedded-project,
200-panfrost-Enable-cross-compilation-of-precompilers-on) for
the new upstream context.
Add +libdisplay-info to the DEPENDS of every libvulkan-* package
(broadcom, imagination, intel, intel-hasvk, lvp, panfrost, radeon,
virtio): Mesa 26.0 unconditionally pulls libdisplay-info into the
WSI Vulkan path on Linux (gated only by host_machine.system() ==
'windows'), so every ICD now NEEDED-links libdisplay-info.so.3
and OpenWrt's shlibs check rejects packages without the explicit
dependency. libvulkan-nouveau is @BROKEN (needs Rust) so it does
not get touched.
The 'imagination-experimental' vulkan-drivers value got renamed to
plain 'imagination' in Mesa 26; update the VULKAN_DRIVERS entry
accordingly.
Add 'imagination' to the host build's -Dtools= list so the
PowerVR pco_clc precompiler is built and installed into
$(STAGING_DIR_HOSTPKG)/bin/ during the host-build stage. The
target vulkan variant uses -Dprecomp-compiler=system and looks
the binary up there via find_program('pco_clc', native:true);
without this, the target configure stage fails with
"Program 'pco_clc' not found or not executable" as soon as the
imagination vulkan driver enters the gallium tree.
New packages:
* libvulkan-virtio: the venus virtio-gpu Vulkan ICD, useful for
VM/container guests forwarding Vulkan to a host GPU. Mirrors the
libvulkan-lvp install pattern. Wired via VULKAN_DRIVERS+=virtio.
* libteflon-rocket and libteflon-etnaviv: two flavours of mesa's
"teflon" TensorFlow Lite delegate. teflon links one or more NPU
back-ends from gallium into a libteflon.so that TFLite loads as
an external delegate. The two variants here cover the NPU silicon
found on OpenWrt-supported hardware:
- rocket: Rockchip RKNPU on RK3566 / RK3568 / RK3588(s)
(rockchip/armv8 target).
- etnaviv: VeriSilicon VIP9000-class NPU on NXP i.MX 8M Plus and
i.MX 95 (imx/cortexa53 target).
The Arm Ethos-U back-end is omitted; it targets Cortex-M55 MCUs
which OpenWrt does not run on.
Each variant is its own VARIANT= mesa build with
-Dgallium-drivers=<rocket|etnaviv> -Dteflon=true; both produce
/usr/lib/libteflon.so so the two packages declare each other as
CONFLICTS (typical OpenWrt mesa-variant pattern).
A small downstream patch (300-teflon-conditional-npu-drivers.patch)
adjusts src/gallium/targets/teflon/meson.build so that the
driver_etnaviv / driver_rocket / driver_ethosu link_with entries
are conditional on with_gallium_<X> instead of unconditional.
Without it, building libteflon with only one back-end fails because
the other driver_X meson variables are undefined when the
corresponding gallium-driver is not selected.
Add 400-gallivm-lp-bld-misc-auto-iter-llvm22.patch to fix the
32-bit ARM build with the new LLVM 22. lp_bld_misc.cpp's
DETECT_ARCH_ARM branch (only reached on ARM-32) iterates the
feature StringMap with an explicit 'llvm::StringMapIterator<bool>'
type, which LLVM 22 renamed to 'llvm::StringMapIterBase<T, bool>'.
Use 'auto' for the iterator declaration so the code works
regardless of the LLVM major. Other targets (aarch64, x86,
x86_64, mips, ppc, riscv) are unaffected because the failing
loop is gated on DETECT_ARCH_ARM.
Disable -Dllvm and -Ddraw-use-llvm in the per-variant MESON_ARGS
for the gallium drivers where the aux 'draw' module is *dead
code*: softpipe, broadcom (vc4/v3d), lima, etnaviv,
teflon-rocket and teflon-etnaviv. Confirmed by inspecting
26.0.6 source: each of v3d, vc4, lima, etnaviv, panfrost (and
the NPU-only rocket/etnaviv teflon paths) registers its own
pipe_context->draw_vbo and never calls any draw_* aux-module
function (0 draw_create, 0 draw_set_so_targets, 0
draw_set_indirect_buffer, 0 draw_*_geometry, 0 src includes of
draw/*.h apart from one unused header in pan_screen.c).
Transform feedback, geometry shaders and indirect draws are
handled either in hardware or via the driver's own compute path,
never through the aux-draw module. softpipe and llvmpipe are the
only consumers of the aux-draw module; mesa.meson.build also
forces draw-use-llvm=true for llvmpipe/lavapipe/i915/r300-x86.
Net effect on libgallium-26.0.6.so, measured on
arm_cortex-a7+neon-vfpv4 (mediatek/mt7623):
variant libgallium before libgallium after .apk after
----------------------------------------------------------------
softpipe 57.7 MB 16 MB 2.9 MB
broadcom 57.7 MB 16 MB 3.2 MB
lima 57.7 MB 16 MB 3.0 MB
etnaviv 57.7 MB 16 MB 2.9 MB
teflon-rocket ~57 MB ~16 MB varies
teflon-etnaviv ~57 MB ~16 MB varies
llvmpipe 57.9 MB 55-56 MB 15 MB (unchanged - keeps LLVM)
LLVM-related strings in the LLVM-disabled variants drop from
208/220 to 5 (just stub strings that survive in the no-LLVM
draw path). The 41 MB removed from each was statically-linked
LLVM JIT that no code path in those drivers ever executed.
Relax the build-time dependency on llvm-mesa: a user who
selects only LLVM-free Mesa variants (softpipe/broadcom/lima/
etnaviv/teflon-*) no longer needs to build the entire llvm-mesa
package (which can take 30+ minutes from source). MESA_USE_LLVM
remains a user-visible toggle (defaults y for backward compat).
With CONFIG_MESA_USE_LLVM=n:
* HOST_BUILD_DEPENDS drops the unconditional 'llvm' (now
MESA_USE_LLVM:llvm), matching PKG_BUILD_DEPENDS.
* MESON_HOST_ARGS skips -Dllvm/-Dmesa-clc/-Dprecomp-compiler/
-Dstatic-libclc/-Dinstall-mesa-clc/-Dinstall-precomp-compiler
and trims -Dtools to just 'nir'.
* Host/Configure factors its LLVM-subproject linkage into a
Host/Configure/LLVMMesa hook, mirroring the existing
Build/Configure/LLVMMesa pattern.
Tested locally on arm_cortex-a7+neon-vfpv4 (mediatek/mt7623):
* MESA_USE_LLVM=y, libmesa-softpipe + libmesa-llvmpipe: builds
llvm-mesa, then mesa softpipe (38s, no-LLVM libgallium) and
llvmpipe (42s, LLVM-linked libgallium 56 MB). All correct.
* MESA_USE_LLVM=n, libmesa-softpipe only: 0 llvm/compile
invocations, 0 mesa/host-compile invocations, total mesa
build time 38s. libmesa-softpipe .apk identical (2.9 MB) to
the MESA_USE_LLVM=y case.
Link: https://docs.mesa3d.org/relnotes/26.0.6.html
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Mesa 25.2.4 configuration fails on Python 3.14+ because 'distutils'
has been removed. Adding 'packaging' ensures the version check
for Mako succeeds without falling back to the missing distutils.
Relates to https://github.com/openwrt/video/issues/61
Signed-off-by: Tito Brasolin <tito.brasolin@gmail.com>
The mesa package currently can't compile as Cython dependency fails to
compile with Python >= 3.13 version.
To fix this, bump all the host pip requirements tools to latest stable
version.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Mesa 25.2 brings a bunch of new features, especially the Panfrost Vulkan
driver saw many improvements.
See https://docs.mesa3d.org/relnotes.html for details about what has
happened since Mesa 25.1.6.
Note that OSMesa as well as the old OpenCL 1.1 support has been dropped.
The new Rusticl OpenCL implementation cannot be supported yet as OpenWrt's
meson integration still lacks support for Rust at this point.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Trying to express the dependency on libatomic conditionally didn't work
well and the effort also simply isn't worth it: given the size of mesa
itself, libatomic is negligable.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Add dependency on libatomic also for non-ARMv6 ARM targets as well as
big-endian ARM (xscale). Obviously they are all unlikely to ever
actually use Mesa.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Support for off-screen rendering ("libOSMesa") has been dropped upstream.
In order to still be able to cross-compile the panfrost driver also on
non-Linux buildhosts, or Linux hosts without libdrm, a patch has been
applied.
This patch has also been submitted upstream via
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36170
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Fix build errors on the noted platforms. Builds were failing with:
Package libmesa-amd is missing dependencies for the following
libraries:
libatomic.so.1
Signed-off-by: W. Michael Petullo <mike@flyn.org>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
mesa-clc set to 'system' requires the system tool 'mesa-clc' which gets
built as part of the mesa/host build.
The mesa/host build however depends on LLVM and others - hence we're
trying to avoid pulling this in where possible if target configuration
allows.
meson option 'mesa-clc' allows for 3 options: enabled, system, auto.
While 'auto' sounds like it will only automagically go for either
'enabled' or 'system', it will also disable CLC support entirely, if
only drivers are enabled which don't need it (resulting in
`with_clc=false`) - which is exactly what we want.
This relies on only drivers being selectable, which don't automatically
enable CLC - if LLVM support is disabled.
Clover only implements OpenCL API for nouveau, r600 and radeon-si GPUs.
Remove OpenCL library packages for targets which anyway implement 0% of
the API and are hence useless.
See also https://mesamatrix.net
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Define all CONFIG_PACKAGE_* symbols which may change build configuration
and only build broadcom drivers on ARM targets with FPU.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Make sure build dependency to mesa/host is set for x86 and x86/64 builds,
add missing dependency on Python ply and make sure to always prefer LLVM
subproject to avoid picking up LLVM from the build host (which may not
match SPIR-V converter tool version).
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Configure build to never link against libunwind or valgrind.
Prevents accidental linkage against those libraries in case they are
present.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Apart from switching to a newer upstream version, also improve the
build:
* introduce build-variants for each kind of hardware
* use LLVM
* build more Gallium drivers
* build Vulkan drivers
* build Clover OpenCL library
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Add missing dependencies on libzstd and libsensors which some libraries
link against if detected during build.
Fixes: #27
Reported-by: @dreirund
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* build vulkan drivers only if selected
* disable broadcom vulkan driver as it causes meson-related
build troubles (unrelated to the version bump)
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Daniel Golle