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>
Bump the Mesa-internal LLVM (kept in feeds/video/libs/llvm/) from
21.1.3 to 22.1.5, and the matching SPIRV-LLVM-Translator from
21.1.1 to 22.1.2.
The SPIRV-LLVM-Translator's major version tracks LLVM's major,
so it caps which LLVM major we can move to. Khronos has now
shipped v22.1.2 (latest in the 22.x series), allowing the LLVM
major bump.
Mesa 26.0.6 sets only a minimum LLVM (>= 18 / 15 / 8 depending
on the requested driver set); no upper bound, so LLVM 22.x is
acceptable.
Two LLVM 22 build-system changes need adapting in the Makefile:
1. LIBCLC_TARGETS_TO_BUILD got stricter target name validation:
'amdgcn--amdhsa' is rejected in favour of 'amdgcn-amd-amdhsa',
and the 32-bit nvptx ('nvptx--', 'nvptx--nvidiacl') targets
were dropped (the 64-bit equivalents remain).
2. libclc bytecode now installs under
'usr/lib/clang/<major>/lib/libclc/' rather than the previous
'usr/share/clc/'. Adjust the SPIR-V .spv copy in Build/Install
to source from the new location (a glob on the major version
avoids re-touching this on the next bump).
The downstream 100-allow-arc-target.patch still applies unchanged.
Link: https://github.com/llvm/llvm-project/releases/tag/llvmorg-22.1.5
Link: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/releases/tag/v22.1.2
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Overview of changes in 1.56.4, 27-06-2025:
* fontconfig: Improve the add_font_file implementation
* fontconfig: Combine font features and style variants
* fontconfig: Make sure font faces stay alive
* win32: Drop some caching
* win32: Make sure font faces stay alive
* win32: Modernize and simplify the code
* win32: Stop synthesizing fonts
* win32: Implement list models
* coretext: Support synthetic small caps
* layout: Avoid assertions in line breaking
* build: Require GLib 2.82
Link: https://gitlab.gnome.org/GNOME/pango/-/raw/1.56.4/NEWS
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Bug fix release with various build/CI improvements and minor
fixes since 6.0.2.
LTO triggers internal compiler errors when building libassimp
against gcc-14 (with the OpenWrt fortify headers in the LTO
unit). Switch PKG_BUILD_FLAGS to 'gc-sections no-lto' to
unblock the build.
Link: https://github.com/assimp/assimp/releases/tag/v6.0.5
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Bump from 15.4.0 to 16.2.0. Upstream glslang ships the same commit
under two equivalent tags:
* 16.2.0 (semver tag)
* vulkan-sdk-1.4.341.0 (Vulkan SDK release tag)
Both tags resolve to commit f0bd0257c308b9a26562c1a30c4748a0219cc951.
We pick the semver tag here so package-manager version comparisons
stay monotonic relative to the previous 15.4.0 packaging; pinning
to vulkan-sdk-1.4.341.0 would otherwise look like a downgrade to
'1.4.341.0'.
This keeps glslang in lockstep with the rest of the Vulkan SDK
component group (vulkan-headers, vulkan-loader, spirv-headers,
spirv-tools all at vulkan-sdk-1.4.341.0).
Disable LTO via PKG_BUILD_FLAGS:=gc-sections no-lto - upstream
hits a 'inlining failed in call to always_inline vsnprintf:
function body can be overwritten at link time' error during
LTO with the OpenWrt fortify headers in 16.x.
Link: https://github.com/KhronosGroup/glslang/releases/tag/16.2.0
Link: https://github.com/KhronosGroup/glslang/releases/tag/vulkan-sdk-1.4.341.0
Link: https://vulkan.lunarg.com/sdk/home
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>
Bump libdouble-conversion to 3.3.1 and backport upstream patch for CMake
>= 4.0 version support.
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>
/usr/share/X11/xkb should point to ../xkeyboard-config-2
Remove the stray extra '../' to fix the symlink.
Fixes: 7873464 ("libxkbcommon: update to 1.10.0")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Unfortunately there is no way to disable running the Python/Jinja2-based
tests, so patch mesion.build in order to not fail in case of Python
dependency problems on the host.
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>
Daniel Golle