Mirror of video feed https://git-03.infra.openwrt.org/feed/video/atom?h=master 2026-05-17T11:46:41Z 2026-05-17T11:46:41Z Daniel Golle 2026-05-09T00:37:16Z urn:sha1:9e78fb7a91ed66ff62a6b315d74584e2a4e604ea 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>