Mesa 26.2 Brings Experimental AV1 Encoding to WSL — Here’s What You Need to Know

Mesa 26.2, the latest quarterly release of the open-source graphics driver stack, shipped with an experimental new feature: AV1 video encoding support for the Gallium Direct3D 12 driver. This means Linux applications running inside Windows Subsystem for Linux can now tap into your PC’s hardware AV1 encoder through DirectX 12—but the capability is rough around the edges and strictly for testing, not production work.

For the first time, WSL users can fire up a Linux video encoder like FFmpeg and have it pass AV1 encode jobs to the host GPU’s dedicated media engine, all without leaving the Linux environment. The catch? Performance can be inconsistent, quality settings are limited, and the driver itself may crash or produce garbled output. Microsoft, hardware vendors, and Mesa developers all characterize it as a prototype, not a ready-to-use feature.

If you regularly compress video to AV1, the practical advice today hasn’t changed: stick to native Windows applications for any work you intend to keep. But if you’re curious about the future of GPU-accelerated workloads in WSL, Mesa 26.2 offers a compelling glimpse of what’s coming.

What Actually Changed

Available now via Mesa’s standard release channels (and likely to appear in rolling distributions like ArchWSL or custom PPA builds), the new encode functionality is built into the d3d12 Gallium driver. That’s the same driver WSL uses to translate Linux GPU calls—OpenGL, Vulkan, and now video—into DirectX 12 commands for the Windows host.

Specifically, Mesa 26.2 exposes the DirectX 12 Video Encode API through a VA-API frontend. On the Linux side, any application that speaks VA-API (the Video Acceleration API) can now request AV1 encoding. Under the hood, the call chain looks like this:

1. A Linux app, such as FFmpeg with vaapi support, opens an AV1 encoder via VA-API.
2. The Mesa driver intercepts that request and translates it into a DirectX 12 video encode session.
3. The Windows GPU driver (from Intel, AMD, or NVIDIA) runs the encode on the hardware media block.
4. The encoded bitstream is passed back to the Linux application as if it had been generated natively.

There are some prerequisites. First, your Windows host must be running Windows 11 24H2 (build 26100 or later) because that’s when Microsoft added AV1 encode capabilities to the DirectX 12 Video acceleration stack. Earlier Windows versions lack the necessary OS-level plumbing. Second, your GPU and its Windows driver must support hardware-accelerated AV1 encoding via DirectX 12. At this stage, that means:

• Intel Arc GPUs (Alchemist and later) and Iris Xe Graphics in 11th Gen CPUs or newer.
• AMD Radeon RX 7000 series (RDNA 3) and later.
• NVIDIA GeForce RTX 40 series (Ada Lovelace) and later.

Older cards, even if they have AV1 decode, lack the encoding hardware block required here. You’ll also need the latest GPU drivers from your vendor; the inbox Windows drivers don’t expose the full DX12 Video feature set.

It’s important to note that this isn’t some hack or third-party plugin. The code was contributed and reviewed through the Mesa project’s standard processes, and Microsoft engineers have been involved in the ongoing integration of WSL with graphics APIs. Still, the developers label it experimental. In the Mesa 26.2 release notes, the feature is tagged as “early support” with a warning that performance and stability are not guaranteed. The “known issues” list is long: frame cadence can be irregular, rate control modes beyond constant QP are untested, and some encoders fail entirely with certain input resolutions.

What It Means for You

The impact depends entirely on who you are and what you do with video. Let’s break it down.

For Enthusiast Tinkerers and Linux Power Users

If you enjoy pushing the boundaries of WSL, this is a fun milestone. You can install the latest Mesa build inside your WSL2 distribution, compile or download a VA-API-capable FFmpeg binary, and run an AV1 encode job that uses the Windows GPU. It’s a great way to see where the technology stands and to provide feedback to the Mesa and WSL teams on GitHub.

Be prepared for rough edges. The encoder might produce a corrupt file, run slower than software encoding, or crash your WSL session. But for short test clips, it usually works. The real value is that every test run helps improve the driver, smoothing the path toward a production-grade feature.

For Content Creators and Video Professionals

There is zero reason to switch your workflow to the WSL AV1 path today. Native Windows encoders are dramatically more reliable, faster, and offer fine-grained control over encoding parameters. Tools like:

• HandBrake (nightly builds with SVT-AV1 and hardware AV1 encoding)
• FFmpeg on Windows (with the h264_amf, h264_nvenc, or av1_qsv encoders)
• OBS Studio (for live streaming with AV1)
• DaVinci Resolve (native AV1 export on supported GPUs)

...all deliver rock-solid results. They’ve been tuned by their respective teams for the Windows driver stack and support full rate control, two-pass encoding, and proper color management. The Mesa 26.2 d3d12 driver is nowhere near that level of maturity.

In fact, using the experimental path could waste hours of your time if an encode fails silently, or if the output file has glitches that aren’t apparent until you review playback. For any work that matters—client deliverables, archival copies, or content you’re uploading to YouTube—stay on the well-lit Windows path.

For Developers and ISVs

This release is a significant building block. If you maintain a cross-platform application that targets Linux and Windows, the ability to run the exact same code path for GPU-accelerated AV1 encoding on both platforms—without platform-specific branches—is tantalizing. You could develop and test your Linux encoding pipeline inside WSL, then deploy to Linux headlessly. Or, you could run a CI/CD pipeline that validates encoding quality on a Windows machine pretending to be a Linux server.

However, the experimental status means no commercial software should ship with a dependency on this feature. The Mesa driver can change incompatibly between releases, and the encode APIs are not yet frozen. Keep an eye on the Mesa release train; once the feature graduates from experimental to stable—likely in a 26.3 or 26.4 release later this year—it’ll be time to seriously evaluate the integration.

For IT Administrators and DevSecOps

If you manage a fleet of Windows workstations where developers use WSL for building and testing media code, you’ll want to update your GPU driver packages to the latest releases from Intel/AMD/NVIDIA so that the DX12 Video encode surfaces are available. But don’t change your default WSL images yet. The experimental encoder path is not something you enable without explicit opt-in (a user must install a newer Mesa release than the one shipped by default in Ubuntu or Debian WSL distributions).

Standard WSL Ubuntu 22.04/24.04 releases come with Mesa 23.x or earlier; they won’t see this feature at all. Only users who manually add a PPA or compile their own Mesa stack will encounter it. That limits the blast radius considerably, and it means you can safely ignore the new functionality unless a team explicitly requests it for testing.

How We Got Here

This moment has been years in the making. Let’s rewind to see how WSL evolved from a text-mode curiosity into a capable GPU playground.

• 2019: WSL2 introduced a real Linux kernel and full system call compatibility, but GPU access was limited to basic DirectX compute through the d3d12 kernel driver.
• 2020: Microsoft released GPU compute support, allowing Linux tools to tap into CUDA, DirectX compute shaders, and OpenCL via the user-mode GPU driver (libdxg and d3d12.so). This enabled ML workloads but not graphics or video.
• 2021: Mesa’s Gallium D3D12 driver emerged as the bridge, translating OpenGL and Vulkan commands to DirectX 12. Suddenly, Linux GUI apps could run accelerated inside WSL.
• 2022: DirectX 12 Video decode capabilities appeared in Windows 11 22H2, and Mesa followed suit with VA-API decode support. You could do hardware-accelerated video playback in WSL, but encoding remained software-only.
• 2024: Windows 11 24H2 added the long-awaited AV1 Video Encode extension to the DirectX 12 Video API. This was part of Microsoft’s broader push to support next-gen video codecs for streaming, Teams, and content creation. GPU vendors shipped updated drivers to expose the new encode hardware.
• March/April 2025 (as rumored by Phoronix and confirmed in the release notes): Mesa 26.2 integrated the DX12 Video encode path, wiring the new Windows capability into the Linux VA-API stack. The merge request landed after months of review and collaboration between Microsoft, Intel, and the Mesa community.

The result is that, for the first time, the entire pipeline—graphics, compute, decode, and encode—now has a path through the Microsoft-backed d3d12 driver. It’s not yet seamless, but the architectural pieces are all in place.

What to Do Now

Your next steps depend on your curiosity and your risk tolerance.

If You Want to Test Mesa 26.2’s AV1 Encode on WSL

1. Confirm your Windows version: Press Win+R, type winver, and ensure you’re on Windows 11 24H2 (OS build 26100.x). If not, update via Windows Update.
2. Update your GPU drivers: Grab the latest driver package directly from Intel, NVIDIA, or AMD. Do not rely on the driver Windows Update delivers; those often lag in video API support.
3. Install a fresh WSL2 distro (optional but recommended to avoid breaking your daily driver). You can use Ubuntu 24.04 from the Microsoft Store.
4. Add the Mesa PPA: The canonical Ubuntu repositories are behind. Run:
   bash sudo add-apt-repository ppa:kisak/kisak-mesa sudo apt update sudo apt upgrade sudo apt install mesa-va-drivers
   Or, if you’re comfortable, compile Mesa 26.2 from source. Expect compilation to take an hour or more.
5. Install a VA-API-enabled FFmpeg:
   bash sudo apt install ffmpeg
   Or build a custom FFmpeg with hardware VA-API support enabled (--enable-vaapi).
6. Run a test encode (this sample command uses the VA-API encoder with AV1):
   bash ffmpeg -vaapi_device /dev/dri/card0 -i input.mp4 -vf 'format=nv12,hwupload' -c:v av1_vaapi -global_quality 30 -b:v 2M output.mp4
   If you see an error about unsupported profiles or the device not found, double-check your GPU driver and Mesa installation.

Expect non-deterministic results. Some clips will encode flawlessly; others may crash the WSL VM. Treat this as a technology preview.

If You Need Reliable AV1 Encoding Right Now

Use native Windows tools. Here’s a cheat sheet for common scenarios:

Each of these tools has been battle-tested and will produce consistent, artifact-free output that you can confidently use for production.

Looking Ahead

The experimental AV1 encode feature in Mesa 26.2 is a harbinger of deeper integration between Linux graphics and the Windows host. In the coming months, we expect:

• Stabilization: Mesa 26.3 will likely swallow dozens of bug fixes for the d3d12 encoder, tackling the most common crashes and quality issues.
• Vulkan Video extensions: Parallel work is ongoing to support AV1 encode through Vulkan Video within WSL. That may provide a more reliable and feature-rich path than VA-API, especially for real-time applications.
• Intel ANV driver support: For systems with integrated Intel Arc GPUs, Intel’s ANV Vulkan driver inside the Linux guest might eventually talk directly to the hardware via GPU-passthrough or paravirtualized interfaces, bypassing the d3d12 translation layer. Don’t hold your breath, but it’s on roadmaps.
• Microsoft’s WSL + AI story: AV1 encoding is computationally heavy, and Microsoft is investing heavily in on-device AI. Some of the same infrastructure that enables hardware encode also supports efficient AI inference. That’s a topic for another piece.

For now, the Mesa 26.2 release is a milestone worth celebrating—but more as a proof of concept than a production-ready tool. It shows that the WSL graphics stack can handle the entire media pipeline, and that’s an achievement that benefits everyone working at the intersection of Linux and Windows.