Graphics drivers and the BSDs

At one time, the BSDs and Linux shared a fair amount of graphics code, in the form of direct rendering manager (DRM) drivers. There was a common core that could be used by both Linux and various BSD flavors, along with operating-system-specific parts, all housed in the same tree. That changed in 2008, when the DRM tree moved into the Linux kernel tree; that move was done to rationalize DRM development, but had the side effect of cutting the BSDs adrift to some extent. Representatives from three of the BSDs came to the X.Org Developers Conference (XDC) to talk about where things stand with DRM drivers for their flavor.

FreeBSD

First up was Jean-Sébastien Pédron, who described the state of the FreeBSD graphics stack. After the DRM drivers moved into the Linux kernel, kernel mode setting (KMS) became mandatory, which added more changes to the drivers. In addition, over time newer hardware was only supported by the Linux drivers—at least for Intel and, later, AMD. NVIDIA provides a binary driver for FreeBSD, but Intel and AMD do not target any of the BSDs with their open-source drivers. FreeBSD did not participate in the development of those drivers since they are essentially Linux-only.

In 2012, the Intel i915 KMS driver from the 3.2 (or, possibly, 3.4) Linux kernel was imported into FreeBSD. As part of that, the developers made a copy of the old DRM code into a new drm2 directory in the FreeBSD kernel tree. Features that were required to support the i915 hardware were added to the DRM device-independent code. The use of Linux-specific APIs and data structures was converted to use FreeBSD equivalents. That driver was available in FreeBSD 9.1.

Similarly, the AMD Radeon KMS driver from Linux 3.8 was imported into FreeBSD's tree, along with the Translation Table Maps (TTM) memory-management layer for DRM. Pédron, who did the port, made some additions to the DRM device-independent code and changed Linux-isms to their FreeBSD counterparts. That was released as part of FreeBSD 9.3.

Those two drivers suffered from a number of problems, the biggest of which was the "gratuitous changes all over the place", he said. The use of FreeBSD APIs and data structures, variable renaming, and an incomplete implementation of DRM all make it difficult to import new code from the Linux drivers.

Recently, he has been working on updating the i915 code. That work is close to completion. He has also synchronized the device-independent DRM code with the version in Linux 3.8. In the longer term, he plans to use a Linux API wrapper to make it easier to bring changes over from Linux, but he will need to convince the other FreeBSD developers in order to do so. He would also like to get rid of the code duplication by merging the drm and drm2 source trees.

That was the major problem with graphics in the FreeBSD kernel, Pédron said, but there is a second problem: it lives in the ports tree that is used to package third party applications for the distribution. The ports tree is a repository of makefiles and patches that can be built and installed with a single make command, though there are higher-level tools available as well. One of the great features of the ports tree is that all of the packages can be installed for any version of FreeBSD that is still being supported, he said. So older FreeBSD versions still have access to recent versions of applications. But there is a downside to that: the package needs to be able to handle missing features in earlier releases.

The differences in the driver support for FreeBSD releases has led to problems in the ports tree. New X server and Mesa versions require certain i915 and Radeon driver versions, but the ports tree is not set up to handle those kinds of dependencies. A hack was made using a build-time flag in the tree, WITH_NEW_XORG, to build the more recent versions of the graphics stack.

That hack caused a number of problems; it was a "nightmare" to maintain and test, and was confusing for users. That led to fewer updates in the graphics stack to try to reduce the complexity. It also caused unrelated packages (the X server and Mesa) to be upgraded in lockstep, which should have been unnecessary. It was, in short, a "fiasco", he said.

Recently, a problem cropped up with version 1.12 of the cairo graphics library and the older Intel driver that would crash the X server. That, it appears, was the straw that broke the camel's back; the older graphics stack has been dropped from FreeBSD. It took a lot of work to convince the developers to do so, however.

The FreeBSD graphics team is small, with just two kernel and two ports developers, not all of whom are fully dedicated to graphics work. There is a lack of X11 expertise and of understanding of the graphics stack, Pédron said. Users are scared of graphics updates, as are the developers. Those updates tend to be "large and tricky", jumping over multiple versions, rather than smaller, incremental changes. Another problem is that many FreeBSD developers do not use the graphics stack for their development systems; they often use Mac OS X instead.

There has been little effort to work with the X community, but Pédron and others are trying to change that. There is an effort to participate more on the mailing lists, for example. His XDC talk is another attempt to reach out to the community. The wiki page on the graphics stack is the best place for those interested to see where things stand. A quarterly report of progress and plans for FreeBSD graphics will also be published.

In the future, there are plans to sync the FreeBSD drivers with those in a more recent Linux kernel (3.10 perhaps). As time allows, he would like to work on adding DMA-buf support as well as working on udev and an alternative to systemd-logind to be able to run X as a non-root user. Wayland is in the plans as well. He finished by noting that the FreeBSD graphics developers wanted to work more closely with X.Org in the future, which was an idea that seemed to be well-received by those in attendance.

DragonFly BSD

Up next was François Tigeot from the DragonFly BSD project. He has worked on the project since 2011. DragonFly was forked from FreeBSD in 2003 and aims to be "high performance and scalable".

The first "tentative" effort at porting the Linux DRM/KMS drivers to DragonFly was a Google Summer of Code (GSoC) project in 2010. The project was not well managed, but the student eventually got something to work using a Linux compatibility layer. Tigeot was never able to reproduce the results and suspects it only worked on the student's hardware.

So, in 2012, he started working on porting the i915 driver from FreeBSD, which shares some kernel APIs with DragonFly. By the end of 2012 it was mostly ported, but it took until mid-2013 to actually get it working. It required some cache management changes to the DragonFly kernel. After that, he switched to porting the Radeon driver and TTM layer, which was mostly ported by October 2013. By July 2014 the Radeon driver was working reliably, he said.

FreeBSD dropped the ball, though, Tigeot said, and there were no significant updates to the i915 driver after 2012. The latest supported hardware was Ivy Bridge. He started rebasing on the Linux i915 driver in September 2013 with a goal of providing Haswell support for DragonFly.

He chose the Linux 3.8.13 i915 driver as the basis for his work. 3.8 has the first known working Haswell support in Linux, but there were other reasons to choose that version. The Radeon port was based on 3.8, as was OpenBSD's Intel driver. Since OpenBSD has the best DRM implementation of the BSD family, using the same version made sense, he said.

There are a number of problems with the FreeBSD i915 driver, including having two DRM directories (as Pédron mentioned) with most of the code duplicated between them. In addition, the FreeBSD developers rewrote the entire driver to conform to FreeBSD's coding style, which resulted in lots of white space differences. Functions were renamed and moved around, file names were changed, and so on. He cleaned a lot of that up, reducing the diff size from 50K lines of code to 22K.

Much like the GSoC student's approach, Tigeot chose to use a Linux compatibility layer. Many of the linux/*.h header files were taken from the FreeBSD InfiniBand stack, which also has a Linux compatibility layer. Some APIs were taken from OpenBSD and others were implemented specifically for DragonFly.

Graphics drivers are a complex and fast-moving target, so it makes more sense to just use the Linux APIs. In a way, he said, he was porting DragonFly to the DRM drivers, rather than porting the drivers to the OS. There is not enough developer time to do otherwise. The major exception is for locking primitives, which are best converted to the DragonFly equivalents.

There were a number of trouble spots, including the Graphics Execution Manager (GEM) layer, which is quite different in the FreeBSD driver vs. Linux. By August of this year, he had the driver working reliably on Haswell hardware.

On the user-space side, DragonFly switched to using the FreeBSD ports tree (with an adaption layer) in 2013. It is "much better" than the previous package management system and brings more up-to-date code with it (e.g. X server 1.12). Unfortunately, the FreeBSD ports tree is beginning to lag a bit. It took years to go from cairo 1.10 to 1.12, for example.

The current state is that the i915 driver is mostly in sync with the Linux 3.8.13 version, except for the GEM code. It is "functionally equivalent to Linux on most paths", Tigeot said. In addition, the Radeon DRM driver is mostly in sync with Linux 3.8 and TTM with Linux 3.9. The generic DRM code is "a mess", with a few parts up to 3.8.13 and other parts much older (< 2.6.26).

Future plans are to bring the generic DRM code up to Linux 3.8, then to start upgrading both DRM and drivers to more recent versions. With TTM working properly, Nouveau could be ported to DragonFly fairly easily as well. Either restoring text mode or adding a graphical TTY layer is another task that needs some work; currently exiting the X server goes to a blank screen or frozen image. In answer to a question from the audience, Tigeot said that he did not have any benchmarks of the drivers, but that the performance was not a problem for day-to-day use.

OpenBSD

The final *BSD representative was Matthieu Herrb, who gave a presentation about the status of the OpenBSD graphics stack. OpenBSD split off from NetBSD (which was the only major BSD variant not represented at XDC) in 1996. One of its claims to fame is its support for many different architectures including some that are not particularly mainstream any more (VAX and Sequent, for example).

OpenBSD already supports bitmap consoles, which makes it easier for it to adopt KMS, he said. Another difference for the project is that it includes X as part of the base system, rather than in its ports tree, which means that it is more closely integrated with the kernel and the rest of the system. Like the other BSD variants, OpenBSD has a ports tree for third party software like GNOME, KDE, Firefox, LibreOffice, and so on.

Herrb last gave a status report at FOSDEM in early 2013, so this talk was an update since then. Most of the user-space components are more recent versions than those used by the other BSDs (e.g. Mesa 10.2.7, X server 1.16.1, etc.), though the DRM/KMS drivers for Intel and Radeon are also based on the Linux 3.8 versions. One downside to importing Linux code is that it won't be reviewed by OpenBSD kernel developers because they won't read code that does not conform to the BSD coding style.

The OpenBSD graphics stack (aka Xenocara) has more features than other systems, he said, including support for graphics on non-x86 architectures. The wscons console driver is integrated with KMS. It has hotplug support for input devices, though there is no keyboard support in the wscons X driver (xf86-input-ws). The X server runs with privilege separation, so the main server does not run with privileges and there is no aperture driver for KMS. OpenBSD uses the CWM window manager, which only uses BSD-licensed libraries; that requirement rules out most other window managers.

There are a number of "missing parts". OpenBSD is planning to switch away from GCC for building the base system, but that has not yet happened, so there is no LLVM package available. That means there is no support for Gallium software rendering. Even when the base system gets LLVM, it will be an older version, while Mesa uses the most recent, so there may need to be two versions supported.

Thread local storage (TLS) is not supported in the GLX driver and there are some issues with futexes and shared-memory fences (xshmfence) that need to be resolved. There is no support for multi-touch, yet, nor any Nouveau support. The latter should be easier since TTM support was added for the Radeon driver.

All of those things are on the radar for future work, as is updating to later versions of the Linux drivers, which "should not be too hard", Herrb said. Moving the input drivers to be more similar to the Linux evdev model is also planned at some point.

He noted a few difficulties, including that some of the KMS drivers are GPL-licensed. There is also a perception in the BSD community that Linux is slowly drifting away from the traditional Unix model with projects like systemd and Wayland. That scares some BSD users, he said. Lastly, there is a lack of developer time to work on these projects.

The latter seems to be a common concern among the three presenters. Graphics is a complex area that requires a lot of developer time to keep up with new hardware support, but the BSDs are fairly small projects—and there are at least four of them. The tone in the room suggested that the X developers are willing to help, to the extent they can, but that there are a number of political, social, licensing, and technical hurdles that only the BSD projects themselves can surmount.

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