Linux & the Unichrome Families (Part 2)

Linux & the Unichrome Families (Part 2)

Linux & the Unichrome Families (Part 2)

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.

Critical Features

Before diving into driver details, I wanted to cover a few relevant technical bits.

XvMC

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/DRM

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.

Driver Details

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.

Further Reading

DRI Wiki: DRM

Comments (5)

  1. Ford
    November 6, 2007

    Could you please provide some advice for those of us wishing to try the Unichrome and OpenChrome drivers? I personally use Debian Etch and Slackware 12 which only have the Xorg VIA driver. Try as I might I cannot get the VIA driver to work properly on either distribution. Scrolling remains slow and jerky, moving windows around causes image glitches, etc. I now really really want to try Unichome and OpenChrome drivers on Debian and Slackware, but I don’t know where to start. I have only compiled small things in the past (Apache+PHP). Do you have any links to HOWTOs or other helpful instructions? I use CLE266 on M10000 and CN400 on SP13000. Slack 12 and Deb Etch with a plain generic 19″ LCD monitor connected to the onboard VGA ports. Nothing exotic. OpenGL/MESA for fancy screensavers or a game of Quake2 would be nice, but is certainly not a priority!

  2. Forest Bond
    Forest
    November 7, 2007

    Hi Ford,

    Ubuntu has openChrome packages available for Gutsy which can easily be rebuilt for Etch. I’ve done just that, and you can download them here:

    THIS LINK IS NO LONGER AVAILABLE

    If you want, of course, you can just install from source using (THIS LINK IS NO LONGER AVAILABLE) the instructions on the openChrome site.

    That should work fine, except that it is likely your system will break during an upgrade at some point. To avoid that, you should use the package manager to install & remove software. A nifty program that lets you install software from source without stepping on your package manager’s toes is CheckInstall.

    Note that CheckInstall is available from Debian, but isn’t in Etch yet. I suggest you download the THIS LINK IS NO LONGER AVAILABLE. See also packages.debian.org THIS LINK IS NO LONGER AVAILABLE.

    Once you have checkinstall on your system, follow the openChrome source instructions, but instead of running “su -c ‘make install'” or “sudo make install”, run “checkinstall”.

    Hope that helps!

  3. Ford
    November 7, 2007

    Wow, thank you for doing that work!

    I wish I could say it worked for me… I removed my existing xserver-xorg-video-via package (which provides libviaXvMC, libviaXvMCPro, and via_drv), installed the two libs, and installed your OpenChrome package. Well, X started but looked sort of interlaced and hung the entire machine after about 3 or 4 seconds.

    Maybe it has something to do with my kernel?

    I am using a stock, up-to-date Debian Etch. EPIA M10000 w/ 1 GB ram, 1280×1024 VGA, plain PS2 mouse, nothing exotic.

  4. Ford
    November 7, 2007

    I’m not sure if this helps, but if I check the console after launching X with the default Etch Xorg VIA driver, I see the following message:
    (EE) VIA(0): [drm] drmAgpBind failed

    Does this mean something is wrong with my kernel’s DRM functionality?

  5. Forest Bond
    Forest
    November 7, 2007

    Ford,

    To be frank, I’m not entirely sure.

    Probably the best thing to do is take this to the openChrome mailing list. It sounds like it may be an issue with your xorg.conf.

    It could also be the BIOS settings (the display type should be set to CRT, even if you are using a LCD monitor connected to the VGA port).

    You can subscribe to the openChrome mailing list here THIS LINK IS NO LONGER AVAILABLE.

    Feel free to send me an e-mail, as well: forest (at) logicsupply.com.

    -Forest

Leave a Comment

Your email address will not be published.