The Huge Nouveau Kernel Driver Rewrite Surfaces

Over the weekend there was the push by Red Hat's Ben Skeggs that effectively reworks/rewrites the Nouveau DRM kernel module for reverse-engineered open-source NVIDIA graphics under Linux.

Skeggs work rewrites a large portion of the Nouveau kernel driver code -- it measures in at about 50 commits and thousands of lines of code have been changed. We knew a big Nouveau DRM rewrite was happening following minimal changes for Nouveau with the Linux 3.6 kernel but on Saturday was when the code finally landed within the Nouveau project's kernel repository.

This Nouveau overhaul won't land in the mainline tree of Linus Torvalds until the Linux 3.7 kernel, but the developers are already asking interested parties to begin testing the code to look out for regressions. "I expect that for a while there will be a *lot* of stupid typos/thinkos that cause all sorts of breakage, so please test everything any anything you can and report *regressions* from the pre-rework code (vs 3.6-rc1 for example)."

The rewrite that happened so far is to basically allow for improved features to come in the future, but just sets the groundwork for now. "At this point don't expect any exciting cool functionality, the work so far is merely a restructure to allow moving forward on a number of fronts in the future."

Among the big work in this Nouveau driver re-write is porting all engines to using the Nouveau driver's new module engine format (this alone is ~14,000 lines of new code), moving code and headers around, a completely new implementation of "instmem", memory management changes, and a lot of new infrastructure. Below is the main commit that added over 4,000 lines of new code to provide new core infrastructure for the Nouveau DRM driver.

This commit provides most of the infrastructure to support a major overhaul of Nouveau's internals coming in the following commits. This work aims to take all the things we've learned over the last several years, and turn that into a cleaner architecture that's more maintainable going forward.

RAMHT and MM bits of the new core have been left out for the moment, and will be pulled in as I go through the process of porting the code to become either subdev or engine modules.

There are several main goals I wanted to achieve through this work:

-- Reduce complexity

The goal here was to make each component of the driver as independent as possible, which will ease maintainability and readability, and provide a good base for resetting locked up GPU units in the future.

-- Better tracking of GPU units that are required at any given time

This is for future PM work, we'll be able to tell exactly what parts of the GPU we need powered at any given point (etc).

-- Expose all available NVIDIA GPUs to the client

In order to support things such as multi-GPU channels, we want to be able to expose all the NVIDIA GPUs to the client over a single file descriptor so it can send a single push buffer to multiple GPUs.

-- Untangle the core hardware support code from the DRM implementation

This happened initially as an unexpected side-effect of developing the initial core infrastructure in userspace, but it turned into a goal of the whole project. Initial benefits will be the availablility of a number of userspace tools and tests using the same code as the driver itself, but will also be important as I look into some virtualisation ideas.

While this just puts down lots of new low-level code as opposed to feature commits, new Phoronix benchmarks of the latest Nouveau code will happen in the coming days to look out for any regressions.

Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via Twitter and Google+ or contacted via MichaelLarabel.com.