Daniel Golle 9e78fb7a91 mesa: update to 26.0.6, add virtio + teflon (rocket / etnaviv)
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>
2026-05-17 12:46:41 +01:00
2026-05-11 12:30:30 +01:00
2025-07-14 22:00:33 +01:00
2015-06-10 11:16:53 +02:00

Video packages feed

Description

This is an OpenWrt package feed containing video / graphics (as in 'higher than just curses') related libraries and applications which are not considered to be so called "core" packages.

Usage

To use these packages, add the following line to the feeds.conf in the OpenWrt buildroot:

src-git video https://github.com/openwrt/video.git

This feed should be included and enabled by default in the OpenWrt buildroot. To install all its package definitions, run:

./scripts/feeds update video
./scripts/feeds install -a -p video

The video packages should now appear in menuconfig in section 'Video'.

S
Description
OpenWrt Video Packages
Readme 913 KiB
Languages
Makefile 96.9%
C 2%
Shell 1.1%