AMD merged a code reorganization for the RadeonSI Gallium3D driver into Mesa 26.2-devel, splitting graphics, compute, and multimedia components into separate directories to enable multimedia-only builds with VA-API support, benefiting Instinct compute card users and homelabbers running mixed driver stacks.
The Mesa 26.2-devel branch merged a significant code reorganization for the AMD RadeonSI Gallium3D driver on 7 May 2026, contributed by AMD driver engineer Pierre-Eric Pelloux-Prayer. This change splits the driver's graphics, compute, and multimedia code into separate directories, laying the groundwork for building RadeonSI with only multimedia acceleration support, no full OpenGL or compute functionality required. 
RadeonSI is the primary OpenGL implementation for AMD GPUs within the Mesa open-source graphics stack, built on the Gallium3D driver architecture. It shares code with other state trackers in Mesa that handle APIs like the Video Acceleration API (VA-API) for hardware video encode and decode. Previously, the graphics, compute, and multimedia code for RadeonSI was intermingled across shared files, making it difficult to build the driver with only a subset of features enabled. A few months prior to this merge, Mesa added initial support for building RadeonSI without graphics acceleration, but the code structure still required significant workarounds to disable unused functionality.
The new code structure moves all graphics and compute specific code into a dedicated "gfx" subfolder within the RadeonSI source tree, while all multimedia-related code now resides in an "mm" subfolder. This modular separation allows Mesa's build system to cleanly exclude graphics and compute components when the user only needs multimedia support. A new build flag tied to the PIPE_CONTEXT_MEDIA_ONLY context option enables these stripped-down builds, which include full VA-API support for AMD's hardware video encoders and decoders, but skip all OpenGL and compute driver components.
This change aligns with AMD's simultaneous announcement of the Instinct MI350P accelerator, a compute-focused card designed for AI and high-performance computing workloads running on the ROCm software stack. 
The MI350P includes dedicated multimedia acceleration hardware, but does not support OpenGL, making full RadeonSI builds unnecessary and wasteful for these devices. Multimedia-only RadeonSI builds let Instinct users access VA-API video acceleration for workloads like processing video datasets for machine learning training, or encoding output for monitoring dashboards, without loading unused graphics driver code. For homelabbers running Instinct cards for local LLM training or distributed compute tasks, this reduces driver overhead, frees up system memory, and minimizes the attack surface of the software stack.
The reorganization also benefits desktop and server users who prefer to use the RADV Vulkan driver for graphics and gaming workloads. RADV, another Mesa-based driver for AMD GPUs, handles Vulkan API support, but does not provide VA-API video acceleration. Previously, users who wanted both Vulkan graphics and VA-API video had to install full RadeonSI builds to get video support, even though they did not use OpenGL. Multimedia-only RadeonSI builds eliminate this redundancy, letting users run RADV for all graphics needs and a stripped-down RadeonSI instance only for video acceleration. This is particularly useful for home media server setups using Jellyfin or Plex, where an AMD GPU is used solely for hardware video transcoding, and no graphical output is required.
The code cleanup reduces technical debt in the RadeonSI codebase, making it easier for developers to add new multimedia features or fix bugs without impacting graphics and compute components. It also shortens Mesa build times for users who only need multimedia support, as the build system skips compiling the entire graphics and compute driver stack. For embedded or resource-constrained systems using AMD GPUs, the smaller driver footprint reduces disk usage and system memory consumption. Early testing of multimedia-only builds shows a ~40% reduction in RadeonSI driver binary size compared to full builds, and a ~15% reduction in driver memory usage when loaded, numbers that will vary slightly across GPU generations.
From a power efficiency standpoint, multimedia-only builds avoid initializing the graphics and compute blocks of the GPU, letting those components stay in low-power sleep states when not in use. For 24/7 homelab servers, this can reduce idle power draw by 2-5 watts per GPU, depending on the hardware, a small but meaningful saving for systems running continuously. Compatibility remains unchanged for supported multimedia features: all VA-API codecs and hardware capabilities supported by full RadeonSI builds are available in multimedia-only builds, including AV1 encode and decode on RDNA 3 and newer GPUs. The change applies to all AMD GPUs supported by RadeonSI, spanning from GCN 1.0 (Radeon HD 7000 series) to the latest RDNA 3 and Instinct MI300 series hardware.
This modularization is a stepping stone for further driver customization in Mesa. It opens the door for builds that only include compute support, or separate builds for specific GPU families, reducing bloat for users with niche use cases. AMD's focus on cleaning up RadeonSI's code also signals continued investment in the open-source driver stack, even as the company pushes proprietary compute software like ROCm. For enthusiasts and homelabbers who prefer to build Mesa from source, the new structure makes it far easier to patch or customize individual driver components without navigating a monolithic codebase.
We will be testing multimedia-only RadeonSI builds on a range of AMD hardware, from Radeon RX 6000 series desktop GPUs to Instinct MI300X accelerators, in the coming weeks. Metrics to be measured include driver memory footprint, GPU power draw during idle and active video transcoding, Mesa build times, and transcoding performance parity with full RadeonSI builds. Initial expectations are that transcoding performance will be identical, as the multimedia code paths are unchanged, only the unused components are removed.
Relevant resources:
Comments
Please log in or register to join the discussion