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-opencl:
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
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,
llvmpipeis 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 asnouveau,r300,r600,radeonsi,svga,virgl,i915,zink, andsoftpipe.mesa-vulkan-plain: non-CLC Vulkan drivers we are willing to promise by default, conservativelyamdandvirtio(plusoverlayif desired).mesa-software: software tier containingllvmpipeand Vulkanswrast/Lavapipe`. This tier needs LLVM, but not the full CLC/Clang stack.mesa-clc-tools: optional helper package providingmesa_clcandvtn_bindgen2when we decide to externalize Mesa helper compilers via-Dmesa-clc=systemand-Dprecomp-compiler=system.mesa-intel-modern: dedicated Intel CLC-backed tier containingcrocus,iris, Vulkanintel,intel_hasvk, andintel-nullhw, withintel-elk=true.mesa-arm-modern: CLC-backed ARM tier for families such aspanfrostandasahi.mesa-nvk: CLC-backed package for Vulkannouveau/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-softwaremesa-intel:mesa-plain,mesa-intel-modernmesa-arm:mesa-plain,mesa-arm-modernmesa-nouveau-full:mesa-plain,mesa-nvkmesa-opencl:mesa-plain,mesa-rusticlNaming 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 asmesa. If we wantmesato remain the default policy package, then it should be the fuller policy package andmesa-plainshould 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=autoandprecomp-compiler=auto; the software tier enables LLVM/shared-LLVM; CLC-backed tiers enable LLVM/shared-LLVM plusmesa-clc=system,precomp-compiler=system, andintel-elk=truewhere required.Open questions:
overlaybelongs inmesa-vulkan-plainwaylandshould be enabled alongsidex11-Dvideo-codecs=all, since that may drag patent-sensitive codecs into redistributable buildsmesa-clc-toolscan 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 insteadAcceptance criteria:
mesa-libs, with driver packages acting as overlays and avoiding file overlapmesa