Sean's Technological Journeys

A desirable goal for the Free Desktop is to have our own 3d games that we can play. Just because it takes special talents and tremendous amounts of effort to develop 3d games doesn't mean that we can not achieve this lofty goal.

Today there are only two types of hardware for which there are decent Free/Open Source drivers (and by "drivers" I mean 2D as well as OpenGL, and all that entails, such as an in-kernel graphics memory manager): oldish ATI Radeon cards, and all recent Intel integrated graphics chipsets.

I don't own any Radeons, but I've heard positive feedback on recent improvements there. However, by far the most advanced and featureful open source graphics stack is the one put together primarily by Tungsten Graphics (now a part of VMware), Intel, and Red Hat. This consists of a user-mode device driver that runs inside the X Server; the Mesa 3d OpenGL library, which communicates with the X server using DRI2 to make its rendered frames available for compositing and management; and the kernel and user-mode management routines consisting of the Direct Rendering Manager, a large component of which is the Graphics Execution Manager.

This set of components inter-operates to provide Radeon and Intel cards with the latest in open source display technology.

Today I built the entire stack above from source, checking out the latest components from git. The difference between the current "stable" stack (what Intel calls the Q4 2008 package) and today is primarily the new support for GLSL version 1.20. Version 1.10 has been standard for several releases.

The stack runs fairly stably, for a development version; I only noticed a few glitches. For the most part, things work as you would want them to, and you can set your expectations rather high. Unlike the past, today you can enable a composited desktop via AIGLX and continue to render 3d applications with a negligible performance impact. In fact, my tests indicated a qualitative performance decrease without a composited desktop.

I tested out four open source 3d games, and two proprietary 3d games. All of them have fairly demanding hardware requirements. My hardware is a ThinkPad X61T 7764-CTO. This laptop has a Core 2 Duo L7700 clocked at 1.8GHz, with 4MB of cache; 4GB of RAM; SATA-2 7200RPM 200GB disk; the Intel "Santa Rosa" mobile chipset; and an Intel Crestline GM965 integrated graphics controller with 128MB of reserved VRAM. An interesting tidbit is that the Intel guys have tuned their driver to actually claim 256MB of VRAM, which is the maximum amount of system memory that the controller is allowed to claim. I'm not sure why Lenovo advertises it as having half of that. When I look at my 'free' system memory, it is indeed 256MB lower than the advertised 4GB, because 256MB is reserved for graphics.

Here are the results when testing these games:

1. Second Life. It runs perfectly and smoothly at 10 - 20 fps. You will notice a performance hit if you start other processes that are heavy on the CPU, because both the rendering and the Second Life engine are rather CPU-intensive. To keep the frame rate up, you should give SL lots of available RAM and CPU. Note that performance in Second Life has traditionally been low, and on many driver builds I've tested, Second Life also tends to crash a lot. The resolution has been to simply wait for Intel to finish their work on the Graphics Execution Manager, as well as some welcome improvements to the Mesa 3d renderer.

2. Vegastrike. It runs very smoothly, but requires some settings tweaking. Vegastrike attempts to guess your video card model from a list that is extremely outdated, as it stops at the GeForce 3. If you have none of the cards it recognizes, then it defaults certain settings to ridiculous levels: high-quality fonts are disabled, which means that you can hardly read any in-game text, and Vertex Buffer Objects (VBO), a feature that is well-supported by now on the Mesa stack, is also disabled, reducing performance. After enabling these features, performance is excellent, and in-game text is readable again. My main gripe here is that there is one rendering glitch: as you change position relative to objects in your camera view, the old position of the objects will remain on the screen every few seconds. It feels like the graphics stack operates as an "inch worm"; it periodically goes behind itself and cleans up old garbage, and then it has a few seconds of correctly-rendered frames, and then it again starts rendering "trails" of the frames that came before the current one. To see this effect in action on any hardware, download a game based on the Quake 3 engine, turn on the "no clipping" feature, and walk into a wall or off the map.

3. Chromium B.S.U.: This one runs perfectly, both performance and correctness-wise, with default settings and graphics detail set to high. The requirements here aren't very demanding, but it's good to know that it is still supported.

4. Planeshift: The game starts, and the basic GUI elements show up; however, all rendered world objects (such as characters during character selection, and the entire 3d world once you enter the game) do not render at all; they are completely black.

And now, the proprietary games.

5. Savage 2: Crashes to desktop. The crash is caused by a function call in the Mesa library (libGL). I'd be happy to provide the info to Mesa developers to improve their stack, because according to the developers of Savage 2, they don't support Intel graphics cards at all. Considering this decision, any fix would have to be on Mesa's side, not Savage 2's. Note that this game is a proprietary native 64-bit Linux application, so there is no emulation.

6. Audiosurf, running through Wine: Freezes the entire X server, or crashes gently to the desktop, depending on whether you have compositing enabled or not. The issue here could be any number of places, but if it's with Wine, Mesa, or the Wine-Mesa interfacing, then there's hope that open source developers can work on it. If the issue is inherent in Audiosurf, though, it would be very difficult to work around it in the Wine code, and unlikely.

All things considered, it's not too bad. Savage 2 is extremely demanding of the hardware, and Audiosurf is running under Wine emulation, which slows it down considerably. Also, the proprietary nature of these games means that if your card isn't officially supported, there is little you can do to convince the developers to get it working with your hardware.

Here we can clearly conclude that open source games run much better with the open source graphics stack than proprietary games. I plan to test additional games later, as well as any future versions of the Intel Linux graphics stack.

The website for Intel's Linux Graphics effort is http://www.intellinuxgraphics.org.