The Rust DRM changes queued for the Linux 7.3 merge window landed in DRM-Next this week, and Nova, the successor to Nouveau for NVIDIA hardware, is the largest item in them. Three things stand out: the GPU System Processor boot process has been consolidated, vGPU boot support was added, and the driver now understands the TLV firmware image format. There are also improvements to the Hopper and Blackwell support code. None of it produces a benchmark you can quote. All of it is the plumbing that decides whether an open source NVIDIA driver is usable on the hardware people actually run. Phoronix reported it on August 10, 2026.
The short answer
The Rust DRM changes for Linux 7.3 were sent to DRM-Next this week, and Nova, the Rust successor to Nouveau for NVIDIA GPUs, carries most of them. The GPU System Processor boot process was consolidated, vGPU boot support was added, TLV firmware image handling landed, and the Hopper and Blackwell support code was improved. Work on Tyr, the in development Arm Mali driver, continues alongside. Reported by Phoronix on August 10, 2026.
There is a category of kernel news that produces no benchmark, no screenshot and no reason for anyone to upgrade. This is squarely in it, and it is still the most consequential graphics item of the week.
The Rust DRM core and driver changes for the Linux 7.3 merge window were sent to DRM-Next, and Nova carries the bulk of them. Nova is the next generation open source kernel driver for NVIDIA GPUs and the designated successor to Nouveau. What landed: a consolidated GPU System Processor boot process, vGPU boot support, TLV firmware image format handling, and improvements to the Hopper and Blackwell support code. Tyr, the in development Rust driver for Arm Mali, continues in parallel.
Why Nova exists as a separate project
Nouveau spent two decades reverse engineering NVIDIA silicon, and the reason it always trailed was structural rather than a matter of effort. A great deal of what a GPU driver does was, on that hardware, logic that lived in the proprietary driver and had to be rediscovered rather than read.
The GPU System Processor changed that. NVIDIA moved most of that logic onto a processor inside the card, running firmware the vendor ships, reached through a command interface. On a GSP equipped card the kernel driver's job stops being reimplementation and becomes something closer to a protocol client: load the right firmware, boot it, and talk to it correctly.
That is a fundamentally more tractable problem, and it is why a new driver written in Rust was worth starting rather than continuing to carry Nouveau forward. The architecture reflects it. nova-core is the base layer that abstracts the hardware and firmware interfaces. Second level drivers sit on top: nova-drm for graphics, and a vGPU manager VFIO driver for handing pieces of a card to virtual machines.
The three items, in order of how much they matter
GSP boot consolidation sounds like refactoring and mostly is. It is also the item that decides how much work the next GPU generation costs. If every architecture brings its own boot sequence, the driver accumulates variants until nobody can safely change any of them. Consolidating the path early, while there are only a few generations to support, is the difference between a driver that absorbs new silicon and one that fractures under it. The Hopper and Blackwell improvements in the same pull are what that consolidation is being tested against.
TLV firmware image support is small and quietly important. Type, length, value means each element in the image announces what it is and how long it is, so a parser can skip what it does not recognise rather than refusing to load. For firmware that is close to a requirement, because the driver will be asked to read images built by tooling that postdates it. The alternative, a fixed layout, means every field the vendor adds breaks every driver that has not caught up.
vGPU boot support is the one that says the most about intent. On the proprietary stack, GPU virtualisation arrived long after the driver, as a separately licensed product fitted to a design that had not anticipated it. Nova is getting the path while the driver is still young, which makes carving a card between virtual machines a case the architecture accounts for rather than one it tolerates. Anyone running GPUs in a hypervisor or a shared cluster should read that ordering as good news, even though the code is not usable yet.
What this does not mean
Nova is not a drop in replacement for anything today, and treating this pull as a release would be a mistake. The changelog is full of boot processes and firmware parsing precisely because the driver is still building its foundations. There is no frame rate here to compare against.
If you need an open source stack on NVIDIA hardware right now, Nouveau with NVK for Vulkan is the combination that exists, and it has been moving too: NVDEC video decode support arrived for NVK in the same 7.3 cycle. The proprietary driver remains the one with full feature coverage. Nova is something to plan around, on a horizon measured in kernel releases rather than weeks.
What is worth noticing is the pattern. Two of the more significant new DRM drivers in the tree, Nova for NVIDIA and Tyr for Arm Mali, are both Rust, both new rather than rewrites, and both being built against hardware that exposes a firmware interface instead of raw registers. That is a different way of writing graphics drivers than the last twenty years produced, and 7.3 is one more release of evidence that it works.
Sources and further reading
- Open-Source NVIDIA "Nova" Driver Sees More Functionality For Linux 7.3, Phoronix, August 10, 2026
- nova NVIDIA GPU drivers, the Linux Kernel documentation
- Nova GPU Driver, Rust for Linux
- Nova task list, the Linux Kernel documentation
Frequently asked questions
What is Nova and how does it differ from Nouveau?
Nova is the next generation open source kernel driver for NVIDIA GPUs, written in Rust, and it is positioned as the successor to Nouveau. The architectural difference is what it targets. Nouveau grew up reverse engineering hardware directly, which meant reimplementing a great deal of logic that the proprietary driver kept to itself. Nova targets GPUs that carry a GPU System Processor, the generation boundary at which NVIDIA moved most of that logic into GPU resident firmware with a documented command interface. That changes the job from reverse engineering silicon to driving a firmware interface, which is a far more tractable problem and the reason Nova exists as a separate effort rather than a rewrite of Nouveau.
What are nova-core and nova-drm, and why are there two?
nova-core is the base driver. It provides an abstraction over the hardware and firmware interfaces of GSP based GPUs and is deliberately not a graphics driver. On top of it sit second level drivers with different jobs: nova-drm is the one that presents a DRM device for graphics and display, and the vGPU manager VFIO driver is the one that carves the card up for virtual machines. Splitting them means the firmware handling is written once and the consumers can evolve separately, which matters because a virtualisation host and a workstation want very different things from the same card.
Why does vGPU boot support matter if I only have one machine?
It probably does not, and it is worth being honest about that. The reason it is notable is what it says about sequencing. Virtualisation support on the proprietary stack arrived years after the basic driver, as a licensed product bolted onto a design that had not planned for it. Building the vGPU path into the open source driver while the driver is still young means multi tenant GPU is a first class case rather than a retrofit. If you run GPUs in a hypervisor or a shared cluster, that ordering is the difference between a feature you can eventually use and one you fight.
What is the TLV firmware image format and why did it need code?
TLV means type, length, value: a container in which each element declares what it is and how long it is before its contents. The practical property is that a parser can skip elements it does not recognise instead of failing, which makes the format forward compatible. For a firmware image that matters a great deal, because the alternative is a fixed layout where every new field a vendor adds breaks every driver that has not been updated. Supporting TLV is a bet that the driver will be reading firmware images produced by tooling it has never seen, which is exactly the situation an in tree driver lives in.
Can I use Nova today instead of the proprietary driver?
Not as a replacement, no. Nova is under active development and the work described here is foundational rather than user facing, which is why the changelog talks about boot processes and firmware parsing instead of frame rates. Treat 7.3 as a milestone in a multi release effort. If you need a working open source stack on NVIDIA hardware right now, Nouveau plus NVK for Vulkan remains the combination that exists, and the proprietary driver remains the one with full feature coverage. Watching Nova is currently a planning activity, not a deployment one.