A small Nouveau kernel patch from Red Hat's David Airlie is staged in drm-misc-next for the Linux 7.3 merge window, and it does one specific thing: it allows allocating NVDEC channels through the ABI16 interface. That is the missing piece Mesa's NVK driver needed to advertise Vulkan Video, starting with H.264 decode on Turing and newer GPUs. It is three lines of description for a change that closes a real gap in the fully open source NVIDIA graphics stack, where hardware video decode has so far meant leaving Mesa behind.
The short answer
A Nouveau patch by Red Hat's David Airlie, staged in drm-misc-next for the Linux 7.3 merge window, allows allocating NVDEC channels through the ABI16 interface. NVDEC is the fixed function video decode engine on NVIDIA hardware, and that allocation path is what Mesa's NVK Vulkan driver needs to expose Vulkan Video. NVK will advertise H.264 decode first. H.265 work exists but currently wedges the GSP. Support requires Turing generation GPUs or newer, since the implementation depends on NVIDIA GSP firmware.
Most kernel patches worth writing about are large. This one is not, and that is precisely why it is interesting: a single missing allocation path had been holding back an entire class of functionality in userspace.
The gap this closes
The open source NVIDIA graphics stack on Linux has two halves. Nouveau lives in the kernel and owns the hardware. NVK lives in Mesa and implements Vulkan on top of it. Over the last few years that pairing has gone from a curiosity to something people actually run, helped enormously by GSP firmware, which lets Nouveau delegate initialisation and clock management to the microcontroller NVIDIA ships on the card rather than reverse engineering it.
Video decode stayed outside that progress. NVDEC, the fixed function decode block, was sitting on the die unused from the open driver's point of view, because there was no supported way for a Vulkan driver to get a command submission channel pointed at it. You can implement as much of the Vulkan Video specification as you like in Mesa, and it does not matter if the kernel will not hand you a channel.
Airlie's patch supplies exactly that, through ABI16, Nouveau's older and simpler userspace interface. Once it is in, NVK can allocate what it needs and start advertising the extensions.
What Vulkan Video buys you over the alternatives
Hardware video decode on Linux has historically meant VA-API or VDPAU, both of which are separate APIs with their own vendor implementations and their own integration work in every player and browser. Vulkan Video puts decode inside the same API and the same device and queue model as rendering.
For anyone writing a compositor, a media player or a rendering pipeline, that removes an entire interop layer. The decoded frame is already a Vulkan image on the device you are drawing with, so there is no export, no import, no format negotiation between two vendor stacks that disagree about tiling. That is the part that matters more than the codec list. The same argument is driving Vulkan Video adoption across the other Mesa drivers, in the same period that has seen RADV extend well beyond its original target platform.
Expectations to keep in check
Three things are worth being clear about.
The codec support is early. H.264 is what NVK will advertise. H.265 is being worked on and is currently wedging the GSP, which means the firmware stops responding under some decode workload and recovery requires a reset. That is a firmware interaction problem, not a matter of finishing an implementation, and those tend to take time.
The hardware boundary is real. GSP means Turing and newer. Pascal and older cards do not get this, and no amount of kernel updating changes that.
The timeline is the usual two stage one. The kernel side targets Linux 7.3, whose merge window opens in the back half of August 2026, which puts the release in autumn. The Mesa side arrives on its own schedule, and Mesa 26.2 has already been landing Vulkan Video fixes and NVK performance work in its release candidates. Getting both halves at once means a rolling distribution or building yourself, and the rest of us wait for the next stable distribution refresh. That is the same pattern every feature landing in the 7.3 cycle follows.
Why it still counts
There is a version of the open source NVIDIA story that has been true for a long time: it works for the desktop, it works for games at a cost, and then you hit something that only the proprietary driver does and you install the proprietary driver. Hardware video decode has been one of those walls, and it is a particularly annoying one because it hits laptop battery life and thermals rather than frame rates, which are the things people notice on machines that are not for gaming.
One patch does not remove the wall. It does remove the reason the wall could not be worked on. That is usually how these things go in Nouveau, and it is worth noticing when it happens.
Sources and further reading
- Phoronix: Nouveau patch for Linux 7.3 allows for NVK Vulkan Video atop NVIDIA NVDEC
- Nouveau project page at freedesktop.org
- Collabora: NVK is now ready for prime time
- Igalia: Vulkan Video with the NVK driver
- Mesa 26.2.0 RC2 release notes coverage, including NVK and Vulkan Video fixes
Frequently asked questions
What does the patch actually add?
It adds the ability to allocate NVDEC channels through Nouveau's ABI16 interface. NVDEC is the fixed function video decode engine on NVIDIA GPUs, and a channel is the command submission context a client needs to feed work to it. Without that allocation path, userspace had no supported way to drive the decode engine through Nouveau, which meant Mesa's NVK Vulkan driver could not expose Vulkan Video no matter how complete its own implementation was. The patch is authored by David Airlie of Red Hat and is included in the drm-misc-next patches staged for the Linux 7.3 merge window.
When does this land, and in which kernel?
Linux 7.3. The patch sits in drm-misc-next, which is the staging branch that feeds the DRM subsystem's pull request, and the Linux 7.3 merge window opens in the back half of August 2026. Merge window inclusion is not a guarantee until the pull is accepted, but drm-misc-next is the normal path and material staged there generally lands. Practically, that puts a released 7.3 kernel in the autumn, and distribution kernels carrying it later still, unless you run a rolling distribution or build your own.
Which GPUs does it cover?
Turing and newer, because the implementation depends on NVIDIA's GSP firmware. The GPU System Processor is the on chip microcontroller that NVIDIA GPUs from Turing onward use to handle a large share of hardware initialisation and management, and Nouveau's modern support path is built around talking to it. Older cards, Pascal and earlier, do not have GSP and are not covered by this work. That is the same boundary that applies to automatic reclocking in Nouveau, so anyone who has followed that saga already knows which side of the line their card falls on.
What can NVK decode once this is in place?
H.264 initially. Phoronix reports that NVK will advertise H.264 video decoding over Vulkan Video first, with H.265 work in progress but currently wedging the GSP, which is a polite way of saying the firmware stops responding and the GPU needs a reset. That is a normal state for early video acceleration work and not a reason to expect a quick fix. The realistic expectation is H.264 first, H.265 later, and AV1 further out, on a timeline set by Mesa releases rather than by the kernel.
Do we need this if we already use the proprietary driver?
No. NVIDIA's proprietary stack has exposed hardware decode for years through its own interfaces, and this changes nothing for those installations. The audience for this work is everyone who runs the fully open source path: Nouveau in the kernel and NVK in Mesa, which is the default on distributions that do not ship out of tree modules, and the only option for people who need a kernel they can rebuild freely. For that path, hardware video decode has been a genuine gap, and closing it removes one of the last practical reasons to install the proprietary driver on a desktop that mostly plays video.