In the first part of this series of posts, I presented a brief overview of the history behind the various X drivers available for Unichrome hardware. I’ll continue with an overview of the major differences between the three most relevant drivers on modern Linux distributions: the in-tree X.org driver, the Unichrome driver, and the openChrome driver.
Before diving into driver details, I wanted to cover a few relevant technical bits.
XvMC is an extension to Xv, which is itself an extension to the X server. Wikipedia has a nice page on this, which I don’t mind quoting for you:
X-Video Motion Compensation (XvMC), is an extension of the X video extension (Xv) for the X Window System. The XvMC API allows video programs to offload portions of the video decoding process to the GPU video-hardware. In theory this process should also reduce bus bandwidth requirements. Currently, the supported portions to be offloaded by XvMC onto the GPU are motion compensation (mo comp) and inverse discrete cosine transform (iDCT) for MPEG-2 video. XvMC also supports offloading decoding of mo comp, iDCT, and VLD (“Variable-Length Decoding”, more commonly known as “slice level acceleration”) for not only MPEG-2 but also MPEG-4 ASP (H.263) and MPEG-4 AVC (H.264) video on VIA Unichrome (S3 Graphics Chrome Series) hardware.
Right. So what does that mean, exactly?
Well, XvMC provides access to certain hardware acceleration features under X. These features critically aid the playback of MPEG video. Without it, MPEG video playback causes much higher CPU utilization, and some systems may not be able to cope, resulting in poor quality video playback and general performance issues while playing video. It is a fair bet that, without XvMC, a lot of systems will not be able to reliably play high-definition video satisfactorily.
I hope to elaborate on XvMC and the other pieces that have to be in place to take advantage of it, including support by individual multimedia applications, in a future blog post.
DRI is the Direct Rendering Infrastructure. DRI makes it possible for client software to talk directly to the video hardware, thereby permitting high-performance graphics operations that are a necessary function for hardware-accelerated 3D graphics. DRM, or the Direct Rendering Manager, is a critical piece of DRI. DRM takes form as two kernel drivers that function cooperatively to achieve the necessary functionality. One of these drivers is generic (drm.ko), while the other is hardware-specific (via.ko).
The hardware-specific DRM drivers are currently maintained by the Mesa project. However, the X driver needs to have been written to use DRI in order to be compatible with it. I believe that all of the drivers I’m covering here should function correctly with DRI; however, I do not intend to cover the VIA DRM driver itself (although I may do just that in a future post), which may not necessarily support all hardware or features.
The In-Tree X.org Driver
Several years ago, prior to the controversial fork, the Unichrome project regularly pushed features and bug fixes to the X.org VIA driver. Thus, the Unichrome project largely represented the development codebase for the stable X.org driver. The core Unichrome developers were significantly involved with X.org development as well, so changes could easily be ushered from one tree to the other, and vice-versa.
After the fork, the situation changed. The correct flow of code became ambiguous, as the Unichrome and openChrome drivers grew apart, making their respective code incompatible. Since there was more than one potential source for code to be merged into the X.org tree, merges slowed drastically. Some fixes and features still make it through, but (largely due to the now uncomfortable political landscape surrounding the rift) the in-tree driver does not see the quick pace of development that it once did.
As you can imagine then, this driver is by far the least bleeding-edge X.org driver for Unichrome hardware. The advantages are probably clear:
- It is stable.
- Installation and maintenance effort is close to none, since it is included with all standard X.org installs.
However, the disadvantages are also obvious: Support for new features and new devices is added slowly, if at all. Generally, then, users with CLE266-based mainboards and some users on other chips without the need for XvMC will likely find this driver suitable. Many users, though, will likely need to choose an alternative.
The Unichrome Driver
The Unichrome Project is largely maintained and developed by Luc Verhaegen. The primary goals of the project are perhaps best represented by Luc’s stated personal mission:
As a driver developer, my focus is on clean and well-structured code and modesetting. Modesetting is the most fundamental functionality and tough to get right.
One of the project’s fundamental goals is total independence from the VGA BIOS. The project developers intend to accomplish this by employing full algorithmic modesetting.
The motivation for reducing dependence on the VGA bios, like many decisions made in the world of open-source software, is likely a mix of technical and ideological assertions:
- Many problems are ultimately caused by incorrect operation of the VGA BIOS. By eliminating the VGA BIOS, fewer problems will arise.
- A computer utilizing the VGA BIOS is not completely Free (as in Freedom), as the VGA BIOS itself is proprietary software. Obviously, this point is surrounded by the usual free/non-free controversy.
- Since the VGA BIOS represents a “black box” in the graphics support stack, debugging is necessarily more difficult.
So, you might be wondering what’s wrong with the VGA BIOS? Is it really that much of a problem?
BIOS’s (VGA and otherwise) are generally regarded as some of the most buggy software in wide use today. BIOS’s are inherently difficult to test; they work closely with the hardware (making them vulnerable to subtle hardware compatibility issues) and implement features for which the definition of success can include a lot of gray areas. They are product-specific, which means they have a relatively short useful lifetime that doesn’t justify a lot of extra developer time spent testing for or fixing glitches. They are proprietary and closed to an extreme; many BIOS’s feature code not viewed or tested by anyone outside of a small team of BIOS developers. All of this leads to a software product that suffers higher-than-average bug counts.
Despite all of their failings, however, most VGA BIOS’s do work correctly most of the time. It is worth noting that, first and foremost, the Unichrome project is in pursuit of good code, and has dropped significant features in favor of maintaining a quality code base. While programmers probably harbor some empathy for the project on these grounds, many users have found that the loss of certain critical features makes the current iteration of the Unichrome driver less than satisfactory for their systems.
Undoubtedly, the most notable feature missing from the Unichrome driver is XvMC support, which was removed due to the code being viewed as having quality or architectural issues. Reimplementation is planned; however, the project has limited development resources, and it may be some time before the remove functionality is replaced.
The openChrome Driver
The openChrome project came into existence largely due to disagreement over the goals of the Unichrome project. This rift becomes very evident when comparing the drivers these projects have produced. The openChrome project makes every reasonable effort to avoid regressions in functionality, and continues to add support for new features and hardware despite an imperfect code base. This represents a significantly different development philosophy than that of the Unichrome project.
Perhaps most notably, the openChrome project retained support for XvMC. That, combined with the fact that it has support for newer hardware than the in-tree X.org driver, makes the openChrome driver the favorite of users requiring decent MPEG performance on newer Unichrome hardware.
The openChrome project continues to rely on the VGA BIOS for modesetting and, consequently, is likely to be occasionally vulnerable to the mysterious glitches that can result. Also, since there has been no orchestrated purge of legacy code, it is probably safe to say that the openChrome driver is (at least slightly) more bug-prone than the Unichrome driver (which has seen aggressive cleaning up).
Choosing a Driver
I hope that the driver choice is much more clear now than it previously was. To summarize, a decision is probably best made as follows:
- If your hardware works satisfactorily with the in-tree X.org driver, use that.
- Otherwise, if you need XvMC (MPEG video acceleration), the openChrome driver is probably a good choice.
- Alternatively, if you do not need XvMC, and especially if you agree strongly with the Unichrome project’s development philosophy, use the Unichrome driver.