Status updates for three graphics drivers

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

Drivers for graphics hardware are an important part of the graphics stack, so it was not unexpected that the 2015 X.Org Developers Conference had several status updates for free graphics drivers. Three projects had talks: the Nouveau driver for NVIDIA devices, the amdgpu driver for AMD hardware, and the Etnaviv driver for Vivante GPUs. Each presented an update on its progress and plans. Something of a summary for each presentation follows; those interested in more detail can consult the program page for links to the slides and videos from each of the talks.

Nouveau

Alexandre Courbot of NVIDIA and Martin Peres of Intel started their talk by clarifying the role their companies play in the project. For Peres, the Nouveau work is strictly done in his spare time and has no connection to Intel at all. Courbot is paid by NVIDIA to work on Nouveau, but that work is mostly focused on supporting Tegra devices, so NVIDIA has "not taken over Nouveau development", he said.

They noted that the last status update was at FOSDEM in 2014 (more than a year and a half earlier) and that there have been many improvements since then. A big refactoring of the kernel driver core architecture that had been started back in the Linux 3.7 days was completed. The effort was led by Ben Skeggs and will be finished as of the upcoming Linux 4.3 kernel.

In addition, support for the NVIDIA virtualization interface has been added. The goal is to allow GPU virtualization with low performance impact. Samuel Pitoiset has added support for performance counters to the driver (which was the subject of another talk). Reclocking support, which allows for different performance levels of the hardware, has been added for more GPUs. That has mostly been for Kepler GPUs, but Maxwell reclocking had been added that morning, Peres said.

There are some proposals from NVIDIA that have been merged or are in progress. Explicit handling of coherent objects between the CPU and GPU has been added to the driver. Objects can be marked so that the driver will keep them cache-coherent between the two processors even on buses that are not guaranteed to be coherent. There is a new submit ioctl() that allows user space to handle synchronization, which is not yet merged but would bring performance improvements, Courbot said.

Peres noted that NVIDIA releases a lot of graphics cards, which makes it hard to keep up on the user-space (Mesa) side. Maxwell support was added to Mesa back in mid-2014. Beyond that, support for OpenGL 3.3 for NVIDIA hardware came in Mesa 10.1, and OpenGL 4.1 support came in Mesa 11. Upcoming work includes more graphics-related performance counter support, including an API to expose the counters to other programs.

On the device-dependent X (DDX) side of things, xf86-video-nouveau has dropped support for the Glamor 2D driver. Those who want that support should use the xf86-video-modesetting driver instead.

Courbot said that support for the Tegra K1 (GK20A) was released in January 2014. That code came from NVIDIA and surprised many people at the time. By October 2014, there was "out of the box" Mesa support for the hardware and the patches for the kernel driver are now upstream. Basic kernel support for the Tegra X1 (GM20B) was merged for 4.3 and more features are planned.

Applications that use kernel mode setting (KMS), such as Weston and X, assume that the display components (which send graphical data to the screen) and render components (which produce off-screen data from the graphics commands) are the same device. That is generally true for discrete GPUs (dGPUs), but is not true for mobile devices like Tegra. That means that there is still work to do before applications will display properly on those devices. Courbot suggested that render nodes, which were added a few years back, should be used, though that doesn't completely solve the problems.

First-generation Maxwell GPUs (GM107) were supported initially back in March 2014 using NVIDIA's firmware. By April 2015, open-source firmware had been released and was supported by the driver. But support for the second generation (GM204+) has been stalled for all of 2015, waiting for the release of signed firmware by NVIDIA. Those GPUs will not load firmware unless it is signed with an NVIDIA key.

The problem is wider than just Maxwell, as newer Tegra GPUs also have this requirement. Courbot said that NVIDIA will be releasing signed firmware but that it hasn't happened yet. The code to load signed firmware is mostly working at this point, but there is an internal workflow issue at NVIDIA that needs to be resolved in order to release the firmware. It is normally linked into the binary driver, but there needs to be a separate release of the firmware for Nouveau.

There has been a lot more cooperation between NVIDIA and Nouveau over the last few years. Beyond official support for Tegra GPUs, there is ongoing work to provide generated header files with proper register names and descriptions from the NVIDIA documentation. In addition, there is some open documentation [FTP] available, though it is "still pretty scarce", Courbot said. There is a (non-public) mailing list where Nouveau developers can ask questions and get answers, which sometimes results in additional documentation being written and released. There is still room for improvement, but the relationship between NVIDIA and Nouveau has gotten better and better over the years.

amdgpu

Alex Deucher and Jammy Zhou from AMD gave an overview of the status of the amdgpu project, which is meant to unify AMD's Linux driver offerings. The driver is taking advantage of the existing open-source infrastructure, such as the TTM memory manager, direct rendering manager (DRM) subsystem, Glamor, and so on.

The amdgpu driver is based on the current upstream Radeon driver. There will effectively be two versions of the driver, one that is all open source and a "pro" version that contains some closed-source components. The closed components are an OpenGL user-mode driver (UMD) and two pieces that will eventually become open source: OpenCL and Vulkan support. There is already Gallium3D-based OpenCL support for the open-source driver.

The amdgpu driver has ioctl() interfaces based on those in the Radeon driver for command submission and memory management. It uses the common mode-setting ioctl() interface. There is a libdrm_amdgpu library that provides a common interface for both the open and closed versions of the driver. The FirePro add-on, which adds "workstation class" features, will be open source (though it may not be accepted upstream) and will only be used by the driver if "absolutely necessary". There is a Mesa user-space driver for OpenGL support.

The initial driver was merged into Linux 4.2, supporting Volcanic Islands GPUs and with experimental support for Sea Islands hardware. Support for Fiji GPUs was added in Linux 4.3. Initial OpenGL support for Volcanic Islands hardware was merged for Mesa 11.0. In addition, initial support for libdrm_amdgpu was merged into libdrm 2.4.63.

Plans for the future include enabling the software GPU scheduler by default, adding a new display component, and adding a new power component called PowerPlay. Support for more graphics hardware is also planned. Both the currently closed OpenCL and Vulkan components will be turned into open-source projects that will be run by AMD. They will share their code bases with the closed-source versions for other operating systems, so they will likely remain as standalone projects.

Etnaviv

Lucas Stach, a kernel and graphics developer at Pengutronix, presented on the Etnaviv project, which supports the Vivante IP core used by multiple different systems-on-chip (SoCs). There are several hardware vendors that are using the Vivante core, but probably the most interesting are Marvell and Freescale, both of which have multiple SoC lines using those GPUs.

The project started as a reverse-engineering effort by Wladimir J. van der Laan with contributions from Christian Gmeiner and others. A lot of the commands and the instruction set are known at this point, so Stach did not have to do any reverse engineering of his own.

Vivante hardware has separate cores for 2D, 3D, and vector graphics, which can be combined in various ways on a particular SoC. The 3D core is straightforward; it is modeled after the DirectX 9 pipeline with the addition of unified shaders. Newer and bigger models of the hardware add the ability to run programs using the OpenCL embedded profile.

The different ways that the cores can be arranged makes a difference in how the kernel driver is implemented. One configuration would have a single fetch engine (FE), which is just a "fancy DMA engine", that feeds all three cores. That single FE is exposed to user space as a single channel for rendering.

Another configuration has three FEs, one per core, so 3D acceleration could be handled in parallel with 2D or vector graphics rendering. Each FE is exposed as a separate channel, but that makes synchronization trickier. There may also be multiple "pixel pipes"—the component that runs shader programs and writes out the data. That allows for parallelism and better performance in rendering; it is somewhat akin to the scalable link interface multi-GPU support from NVIDIA. Stach has never seen hardware that has that capability, but the obfuscated GPL driver that Vivante has released supports it.

There are a number of reasons to want a FOSS driver for Vivante GPUs beyond the obvious "FOSS drivers are awesome" reason, Stach said. Integrating vendor drivers is a serious pain point for his customers (and others). The obfuscated kernel driver is huge and only works with Linux 3.14; it also requires closed-source user-space libraries. No security audit is possible for the code and fixes do not necessarily come in a timely fashion.

For these reasons, his customers demand open drivers where they can fix bugs on their own. The Freescale i.MX6, for example, is used in a lot of automotive and industrial applications. It has a fifteen-year guaranteed availability, so the last newly-built devices using the chip may ship in 2027, as it was introduced in 2012. Running the vendor driver may well be impossible by then.

The kernel driver work was started by Gmeiner in 2014 as a clone of the freedreno driver adapted to the Vivante hardware. Stach cleaned it up and sent it out as an RFC in April 2015. That received some comments that have been addressed and it is now out for additional comments.

Since the first version, the user-space API has been significantly reworked to avoid a problem where the command stream could be changed after the driver had validated it. The cache handling for non-cache-coherent architectures has been fixed. GPU suspend and resume are now working and there have been lots of stability improvements. Etnaviv can now replace the "fat and obfuscated" Vivante kernel driver with one that has readable code and is much smaller—instead of 60,000 lines of code, Etnaviv is around 6,500.

There is still work to be done on the kernel side, including using the dynamic voltage and frequency scaling (DVFS) available in the cores. The command-stream validation needs to be improved and support for per-client MMU contexts needs to be added; both have security implications. If support for the MMUv2 interface on some hardware can be added, it would remove the need for the command-stream validation on those platforms. Exposing the performance counters to user space is needed as well.

Russell King has gotten the xf86-video-armada driver working using libetnaviv on top of the Vivante kernel driver. That uses the 2D GPU and provides acceleration for some common operations. Gmeiner started a libdrm for Etnaviv (etna-drm) as another freedreno clone. It has been updated for the new user-space API and some cleanups have been done, so it is ready for review. There is also a Mesa driver that is able to run simple applications—including Quake 3.

As can be seen, there has been quite a bit of progress in the world of free drivers. It is not all that long ago that open-source graphics drivers were essentially non-existent, but that has changed substantially—and that process appears to be accelerating. Some surprising vendors are participating and even the world of mobile graphics is seeing major progress these days. It is all rather heartening to see.

[I would like to thank the X.Org Foundation for travel assistance to Toronto for XDC.]

