From VPE 2.0 to Hardware-Accelerated Video Processing on AMD Linux

Learn to set up AMD VPE 2.0 hardware-accelerated video scaling, tone-mapping & color conversion on Linux using Mesa, VA-API, and standard tools.

The Radeon Open‑Source (“RadeonSI”) driver in Mesa recently gained support for AMD’s next‑generation Video Processing Engine, VPE 2.0. VPE is a fixed‑function hardware block designed for energy‑efficient video post‑processing, including scaling, colour conversion, HDR tone‑mapping, gamut mapping, and rotation. 

Unlike a general‑purpose GPU, which can perform these tasks but with a higher power cost, VPE’s dedicated circuitry handles them more efficiently—an important benefit for laptops, embedded devices, and any system where battery life or thermal headroom matters.

Support for VPE 2.0 in Mesa means that future AMD GPUs (likely based on the RDNA 5 architecture) will be able to expose these capabilities through standard Linux video APIs. This post explains how the VPE stack works, how to verify VPE support on your system, and how to start using it with existing applications.

What VPE Actually Does

VPE is a copy engine, not a full video encoder/decoder. It sits alongside dedicated encoding (VCN) and decoding (UVD/VCN) blocks. Its primary job is to process video frames in memory—for example, converting an HDR frame to SDR, scaling a 4K frame down to 1080p, or rotating an image by 90 degrees. Key operations include:

• Pixel re‑gamma (gamma correction)

• Scaling (up/down)

• Colour space conversion (CSC)

• Gamut remapping

• Tone mapping (e.g., HDR‑to‑SDR, including 3DLUT‑based conversion)

• Programmable gamma correction

Future VPE iterations will also add blending, mirroring, and more advanced rotations.

VPE 1.0 first appeared in Ryzen AI 300 series (RDNA 3.5 iGPUs), VPE 1.1 followed with RDNA4, and VPE 2.0 is now being wired up in Mesa for next‑gen RDNA 5 hardware. The Mesa merge that introduces VPE 2.0 adds features such as RGB 3‑planar support and additional video rotation options.

The Software Stack for VPE-Accelerated Video

VPE does not work in isolation—it requires a complete software stack from kernel to application. The following diagram shows the key layers:

Example:

Application (e.g., GStreamer, FFmpeg, Chromium)
         │
         ▼
    VA-API / Vulkan Video
         │
         ▼
   Mesa (RadeonSI / RADV)
         │
         ▼
   libdrm_amdgpu (kernel)
         │
         ▼
    AMDGPU kernel driver
         │
         ▼
      VPE hardware

Most user‑space applications use VA-API (Video Acceleration API) to request hardware‑accelerated video operations. Mesa implements VA-API via its gallium/state_trackers/va/ component. 

When an application calls a VA-API function (e.g., for scaling or colour conversion), Mesa translates that request into commands that the AMDGPU kernel driver can submit to the VPE hardware.

Since Mesa version 25.1, AMD has also open‑sourced GMLIB, a library used by the RadeonSI driver to generate 3D Look‑Up Tables (3DLUT) for HDR tone‑mapping on VPE hardware. This allows applications to perform high‑quality HDR‑to‑SDR conversion with minimal CPU or GPU overhead.

Prerequisites

Before VPE acceleration can be used, the following components must be present:

 1. AMD GPU with VPE hardware – VPE 2.0 support is being prepared for future RDNA 5 GPUs. To check if your current AMD GPU includes any VPE block, see the verification section below.

 2. Linux kernel with AMDGPU VPE support – The kernel driver patches for VPE 6.1.0 were upstreamed starting in late 2023. A mainline kernel of version 6.6 or newer is recommended.

 3. Mesa with VPE support – VPE 2.0 support was merged for Mesa release 26.2. For VPE 1.0/1.1, Mesa 24.1 or later is required.

4. Appropriate firmware files – AMD GPU firmware must be installed (typically provided by the linux-firmware package in most distributions).

User‑space libraries – libva (VA-API library), libva‑mesa‑driver (the Mesa backend for VA-API), and optionally gstreamer‑vaapi or ffmpeg with VA-API support.

Step‑by‑Step: Checking VPE Support on Your System

1. Verify the Kernel Recognises VPE Hardware

bash

# List DRM devices and look for VPE-related entries
cat /sys/kernel/debug/dri/*/amdgpu_vm_info | grep -i vpe

# Alternatively, check the kernel ring buffer for VPE initialisation messages
dmesg | grep -i vpe

If your GPU contains a VPE block, you should see lines indicating that the VPE hardware was detected and initialised by the amdgpu driver.

2. Check Mesa’s VA-API Driver Capabilities

bash

# Run the VA-API information tool
vainfo

# Expected output includes lines like:
#   driver: Mesa Gallium driver  (RadeonSI) for AMD Radeon Graphics (VPE supported)
#   VAEntrypointVld, VAEntrypointEncSlice, VAEntrypointProcScale, etc.

Look for VAEntrypointProcScale – this indicates that hardware‑accelerated video post‑processing (scaling, colour conversion, etc.) is available. If VPE is working, you may also see support for VAEntrypointToneMapping depending on the exact hardware and Mesa version.

3. List Available Pixel Formats and Operations (Advanced)

The Mesa source tree includes development tools that can query the VPE capabilities more deeply. For example, the radeonsi_vpe testing utility (once built) can list supported formats and operations.

bash

# Compile Mesa from source (if needed) and run the test tool
meson build -Dgallium-drivers=radeonsi -Dvulkan-drivers=amd -Dtools=all
ninja -C build
./build/src/gallium/tools/radeonsi/radeonsi_vpe --list-formats

Step‑by‑Step: Using VPE Acceleration with Applications

Once the prerequisites are met, most media frameworks can automatically use VPE through the VA-API backend. No application code changes are required—the VA-API environment variables control which backend (radeonsi for VPE) is used.

Enabling VA-API for VPE

Set the following environment variables before launching your application:

bash

export LIBVA_DRIVER_NAME=radeonsi
export GST_VAAPI_DRM_DEVICE=/dev/dri/renderD128   # adjust the render node number as needed

Testing with GStreamer

bash

# Perform hardware‑accelerated scaling from 1920x1080 to 1280x720
gst-launch-1.0 videotestsrc ! video/x-raw,width=1920,height=1080 ! \
    vaapipostproc ! video/x-raw,width=1280,height=720 ! autovideosink

# Convert an HDR sample to SDR using VPE tone‑mapping (when available)
gst-launch-1.0 filesrc location=/path/to/hdr_video.mkv ! \
    matroskademux ! vaapih264dec ! vaapipostproc \
    tonemap=1 target-colorspace=bt709 ! videoconvert ! autovideosink

Testing with FFmpeg

bash

# Encode a video with VA-API (using VPE for scaling if needed)
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 \
       -i /path/to/input.mp4 \
       -vf "scale_vaapi=1280:720" \
       -c:v h264_vaapi \
       -b:v 2M \
       output.mp4

Testing with a Web Browser (Chromium)

Launch Chromium with VA-API support:

bash

chromium --use-gl=egl --enable-features=VaapiVideoDecoder,VaapiVideoEncoder \
         --disable-features=UseChromeOSDirectVideoDecoder

Navigate to chrome://gpu and verify that “Video Acceleration” is marked “Enabled” for your AMD GPU.

Verification Commands

After running a VPE‑accelerated workload, you can confirm that the VPE engine was actually used:

Check VPE Engine Statistics

bash

# Display GPU engine usage (requires kernel 5.15+)
cat /sys/kernel/debug/dri/*/amdgpu_pm_info | grep -i "vpe"

# Monitor real‑time engine utilisation
watch -n 1 'cat /sys/kernel/debug/dri/*/amdgpu_pm_info | grep -i "vpe"'

Trace VA-API Calls to Confirm VPE Usage

bash

# Enable VA-API logging
export LIBVA_TRACE=/tmp/va_trace.log
export LIBVA_DRIVERS_PATH=/usr/lib/dri
your_application

# Search the log for VPE references
grep -i vpe /tmp/va_trace.log

Check Power Consumption During VPE Workload

VPE is designed to be power‑efficient compared to using the 3D engine for the same task. Compare power draw when performing scaling with and without VPE:

bash

# Install power monitoring tools
sudo apt install powertop   # Debian/Ubuntu
sudo dnf install powertop   # Fedora

# Monitor power consumption while running a video scaling test
sudo powertop

Common Pitfalls and How to Avoid Them

1. “VPE Engine Not Found” in dmesg

Cause: The kernel driver does not recognise the VPE hardware, often because the kernel is too old or the firmware is missing.

Solution: Upgrade your kernel to a version containing the VPE patches (6.6 or newer) and ensure the linux-firmware package is up to date. Reboot and check dmesg | grep vpe again.

2. vainfo Shows No VAEntrypointProcScale or Reports “Unknown”

Cause: Mesa was built without the RadeonSI video processing front‑end, or the VA-API driver is pointing to the incorrect backend.

Solution: Install the full Mesa package with VA-API support (package names vary by distribution: mesa-va-drivers on Debian/Ubuntu, mesa‑va‑drivers on Fedora). Set LIBVA_DRIVER_NAME=radeonsi and verify that the radeonsi_drv_video.so exists in /usr/lib/dri/.

3. Application Crashes or Hangs When Using VA-API

Cause: Some older GPU models do not fully support Vulkan Video or VA-API, and forcing the environment variable can cause instability.

Solution: Check your exact GPU model against the supported hardware list. For older GPUs, use the software fallback (LIBVA_DRIVER_NAME=i965 for Intel, or no variable for software decoding) instead of forcing VPE.

4. HDR Tone‑Mapping Looks Incorrect

Cause: Early VPE implementations may lack full 3DLUT support, or the application is not passing the correct colour metadata.

Solution: Ensure you are using Mesa 25.1 or newer, which includes the GMLIB library for VPE tone‑mapping. 

Verify that your input video contains proper HDR metadata (e.g., using ffprobe or mediainfo). Some applications may require explicit tone‑mapping settings (as shown in the GStreamer example above).

Further Reading

• man radeonsi – Driver‑specific options for the AMD RadeonSI Gallium driver

• man libva – Overview of the VA-API library and environment variables

• man ffmpeg – VA-API encoder and filter documentation

• Arch Linux Wiki: Hardware video acceleration – Detailed configuration for all distributions

• Gentoo Wiki: VAAPI – Additional troubleshooting and build instructions

• Kernel documentation: Documentation/gpu/amdgpu.rst (in the kernel source tree)

LPC 2025 presentation: Enabling AMD 2D Hardware Acceleration for Video API and Applications – Video and slides available from the LPC archives

Final Notes

VPE 2.0 support in Mesa is a forward‑looking feature for next‑generation AMD GPUs. For existing RDNA 3.5 and RDNA4 hardware, VPE 1.0 and 1.1 already work in Mesa 24.1 and later. 

By standardising on VA-API, applications written today will automatically benefit from VPE acceleration on future hardware without code changes. 

Testing with current hardware helps ensure that when VPE 2.0‑capable GPUs arrive, your workflow and applications are ready to take advantage of their power‑efficient video processing capabilities.

Note:   As an Amazon Associate, I earn from qualifying purchases. This helps me keep writing