Skip to content

mesa: split packages by driver/toolchain class and replace autodetected policy with explicit package policy #3

@sighook

Description

@sighook

The current Mesa packaging is deriving policy from ambient build state. In practice, the Pkgfile probes what happens to be installed, then opportunistically expands or shrinks driver coverage around that accident. That was survivable when the dependency surface was flatter, but Mesa now has a much sharper boundary between plain drivers, LLVM-backed software drivers, CLC-backed driver families, and Rusticl. We should stop inferring policy from toolchain accidents and model it explicitly in packaging.

At the moment, llvmpipe is the LLVM-backed software OpenGL path, while Softpipe is the reference interpreter path. A separate class of drivers crosses the current CLC boundary and pulls in LLVM, libclc, SPIRV-Tools, and Clang libraries. Rusticl is another tier again, adding Rust, bindgen, LLVM/libclc, SPIRV-Tools, and the SPIR-V LLVM translator. Mesa also hard-errors on LTO unless we explicitly allow a broken-LTO build. The package layout should acknowledge those membranes instead of hiding them behind opportunistic detection.

Proposed split:

  • mesa-libs: canonical base package. Owns common GL/EGL/GLX/GBM libraries and shared userspace bits.
  • mesa-plain-dri: non-CLC Gallium/DRI drivers such as nouveau, r300, r600, radeonsi, svga, virgl, i915, zink, and softpipe.
  • mesa-vulkan-plain: non-CLC Vulkan drivers we are willing to promise by default, conservatively amd and virtio (plus overlay if desired).
  • mesa-software: software tier containing llvmpipe and Vulkan swrast/Lavapipe`. This tier needs LLVM, but not the full CLC/Clang stack.
  • mesa-clc-tools: optional helper package providing mesa_clc and vtn_bindgen2 when we decide to externalize Mesa helper compilers via -Dmesa-clc=system and -Dprecomp-compiler=system.
  • mesa-intel-modern: dedicated Intel CLC-backed tier containing crocus, iris, Vulkan intel, intel_hasvk, and intel-nullhw, with intel-elk=true.
  • mesa-arm-modern: CLC-backed ARM tier for families such as panfrost and asahi.
  • mesa-nvk: CLC-backed package for Vulkan nouveau/NVK.
  • mesa-rusticl: separate OpenCL tier, kept out of the default graphics stack.

Proposed meta packages:

  • mesa-plain:
    • mesa-libs, mesa-plain-dri, mesa-vulkan-plain, mesa-software
  • mesa-intel:
    • mesa-plain, mesa-intel-modern
  • mesa-arm:
    • mesa-plain, mesa-arm-modern
  • mesa-nouveau-full:
    • mesa-plain, mesa-nvk
  • mesa-opencl:
    • mesa-plain, mesa-rusticl

Naming should stay honest. If the default package intentionally excludes modern Intel, Asahi, Panfrost, or NVK, then that reduced policy should probably be called mesa-plain, not quietly shipped as mesa. If we want mesa to remain the default policy package, then it should be the fuller policy package and mesa-plain should be the austerity variant. Upstream’s current build logic is explicit enough that we should not pretend the CLC-backed drivers are still a minor optional tail.

The build logic should also be simplified. We do not need runtime probing of installed packages followed by mutation of giant CSV variables. We should define static driver classes per package and build each class explicitly. Common Meson options should live in one shared block, while class-specific knobs remain explicit: plain/no-CLC packages keep mesa-clc=auto and precomp-compiler=auto; the software tier enables LLVM/shared-LLVM; CLC-backed tiers enable LLVM/shared-LLVM plus mesa-clc=system, precomp-compiler=system, and intel-elk=true where required.

Open questions:

  • whether overlay belongs in mesa-vulkan-plain
  • whether wayland should be enabled alongside x11
  • how to handle -Dvideo-codecs=all, since that may drag patent-sensitive codecs into redistributable builds
  • whether mesa-clc-tools can be shipped cleanly as a helper-only package for the Mesa version we target, or whether those helpers must live in the first CLC-enabled driver package instead

Acceptance criteria:

  • the current monolithic Mesa package is split into explicit package classes aligned with actual toolchain boundaries
  • common libraries are owned only by mesa-libs, with driver packages acting as overlays and avoiding file overlap
  • driver coverage is declared statically in package sources rather than inferred from whatever compiler stack is installed
  • Rusticl remains isolated from the default graphics stack
  • naming and documentation make the default policy explicit instead of quietly shrinking mesa
  • README/handbook/package docs are updated to describe supported tiers and what is intentionally outside the default promise

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    Projects

    Status

    Packages

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions