An advantage to free software is that it is an environment where competition can thrive, choice is always available and different solutions exist for the same problem. However, it’s also fair to say that free software is disadvantaged where competition breeds, choices are forced on unsuspecting users and diverse technologies fight each other.
Examples of this are GNOME vs KDE, PostgreSQL vs MySQL, VI vs EMACS, and even GNU/Linux vs the BSDs. On the face of it, another flame war seems to be looming, in this case in the domain of the accelerated desktop, that is one of SuSE’s XGL vs RedHat’s AIGLX. Various commentators and observers have caught onto this and there are hints at the beginnings of a press feeding frenzy here. However, upon closer inspection of these technologies, I have discovered that they are not quite as confrontational as it would first appear.
To explain, I need to go into the background of the current (or old as it may be now) relationship between the X Windows System and accelerated 3D graphics.
The story so far
The X Windows System was originally designed really as a mechanism for 2D graphics of the type needed for web browsing or word processing. It works on a “client-server” relationship—the terminal (screen, keyboard and mouse) being a “server” process, and the X programs (browser, word processor, card games, etc.) being “clients” that connect to the terminal server, creating windows the user can use to interact with the program. It does this using a protocol designed for the purpose. (I have described the X Windows System in quite a lot of detail in my article “What is X”.)
X-Windows also has the capacity of being able to run the X-Server (screen, keyboard and mouse) on one machine, while the X-Clients (word-processor, browser, etc.) can run on another; the communication between the two uses the aforementioned protocol and is carried over a TCP/IP network.
Then along came 3D accelerated graphics. This, in short, transferred the processing required to display graphical detail from the main processor to the processor on the graphics card, or the GPU. To facilitate this, the GPU exposes a series of APIs or functions to the program that, when called, performs the necessary operations needed for the user to play first-person shooter games and blow up the appropriate baddies. Or, for the more serious, it would enable you to represent three-dimensional models of certain architectures using computer aided design programs.
In the Unix and POSIX world, the set of APIs used is the OpenGL functionality, originally from Silicon Graphics.
To facilitate this a library suite called “libGL” was created. This was implemented in a number of ways. One was the birth of the Mesa library. This included a sort of wrapper library, which exposes a set of OpenGL functions to the graphical program, simply translates them to X calls, and then transmits the data to the X-Server using the X protocol. Although this provides the logical functionality of OpenGL, you lose all of the performance enhancements of a proper 3D renderer, making it too slow to use for the majority of applications requiring graphical acceleration. However, it is still useful, because it implements the entire OpenGL API. Therefore, any small functionality of OpenGL, which isn’t provided by a method described later, can use this library to implement it. In short, it can now be seen as a fall-back library to guarantee compliance with OpenGL.
The second is the use of a mechanism in X called an extension, which enables add-on features to be included in the protocol. An extension intercepts OpenGL calls and generates special packets, which mirror the functions generated by the client processes (such as CAD programs or 3D games). The extension then encodes them and passes them to the server (screen, keyboard), where a module in the X-Server process reads these packets and calls the appropriate process on the real 3D rendering GPU.
This extension is called “GL-X”, and the mechanism described is known as “Indirect Rendering”. Be careful not to confuse “GL-X” with “XGL”, they are two different things.
Although this functionally produces a solution, for many applications it isn’t always a practical one. When you’re in the pits of hell with monsters coming at you from all directions, your ammo down to a handful of rockets, a couple of machine-gun clips and maybe a banana, the game program needs to instruct the screen to update countless thousands of polygons a second or else the game is simply unplayable. The program needs to stream directly to the GPU. Indirect rendering, even when the display is on the same machine as the game program, is simply too slow. And, you will get eaten.
A means of “Direct Rendering” needed to be incorporated into the X windows environment. And it was.
To achieve this the “networking” functionality of X was put aside. Direct rendering occurs when GPU functionality is called directly from application programs. Memory could well be shared between the renderer and the application. But, this is not feasible over a network; and, if an X-program was run on a separate machine, acceleration either did not occur or the GL-X method was used.
The way this works is the GPU vendor provides both the X-Server display driver and their own version of the “libGL” library. Windows are created, destroyed and manipulated using the existing X protocol, but when the meat of the program is required to manipulate the polygons rapidly within the window itself then the modified “libGL” library accesses the functionality in the GPU directly.
This involves a fairly sophisticated infrastructure to work, especially when considering the current X protocol mechanisms. To standardise this, something called the Direct Rendering Infrastructure (DRI) has been created. The idea behind it is that this would give a base from which independent hardware vendors could build 3D accelerated graphical drivers for X.
It is worth noting that hardware providers who support OpenGL for X in any way almost certainly would support the Direct Rendering method. As the vast majority of X-Servers run on the same physical machine as the X-Clients or programs that connect to it, GL-X is currently the exception rather than the rule.
Demand for composite managers
The current accelerated solution stated above would provide the functionality to allow a game to be run in full-screen mode, or the body of the window to display accelerated graphics. However, as machine power and expectations rise, there is a demand for the windows management itself to be accelerated. This would provide effects like: placing realistic shadows behind drop down menus and having the menus themselves fade in and out of existence; or for control to be switched from one virtual window to another while giving the impression the windows are on the face of a cube and you are turning the cube. Even things like: having the background of a window being transparent, enabling you to see what is happening in windows behind it; or for scaling windows, that is making it, and its contents, larger and smaller and zooming in and out of it.
To achieve this the “window manager” needs to be replaced by a “composite window manager”, and greater interaction is required between the X protocol and the 3D renderer to allow this. Two free software solutions have come forward: XGL (X-to-OpenGL) which is sponsored by SuSE/Novell; and AIGLX (Accelerated Indirect GL-X) which is championed by RedHat.
When I first heard about these two competing solutions my immediate response was “Oh no! Not ANOTHER flame war...”. But once I examined the two of them, I found that they’re not as mutually exclusive as it first seemed. To explain why I’ll go through a summary of how each works and the differences and similarities between them.
Both achieve their goals by making good use of the “composite” extension of the X protocol. This allows windows to be drawn to pixmaps in memory rather than to the screen directly. Once this is done, another program can then take the pixmaps and do wonderful manipulations with them, such as: blending a window with its background window, giving the appearance of transparency and translucency; performing three dimensional manipulations, giving the appearance of rotating and flipping; or even simple things like making the entire window bigger and smaller effectively “zooming” it.
XGL
XGL is conceptually the simpler of the two, though probably the more technically complex. It’s a “traditional” X server that, instead of displaying its results on a monitor, interprets the display and calls the appropriate OpenGL APIs; the OpenGL driver physically interacts with the screen, keyboard and mouse.
The current implementation of XGL is XGLX. This is both an X server and an X client. To use it you need a “real” X server running that supports accelerated OpenGL rendering, and the only program (or X client) that connects to it is XGL—which is acts as an X server for all of the other X programs to connect to. In the future however, the project plan is to replace XGLX with XEGL. This replaces the “real” X-server with a process that writes directly to the Linux frame buffer.
SuSE/Novell have created a special “composite window manager” that interacts with XGL so that composites of the windows can be displayed on the screen using the accelerated graphics.
AIGLX
Rather than recreate the wheel—as XGL does by rewriting the X-Server—this project attempts to modify the current X-server mechanism so that it can handle accelerated windows management. This appears to take less work than you might think (though it’s still substantial).
In this model, the “composite window manager” calls a special OpenGL API, which translates into a slightly extended GL-X protocol, even if direct rendering is installed. These are then transmitted to a slightly modified X-server, which handles the actual composites itself and performs all of the fancy effects.
The extensions to GL-X to create AIGLX largely seems to involve the composite elements. At the moment, to create a composite, the X-client program transmits windows and contents to the X-server display, which then generates the composite. This is transmitted back to the X-client program, manipulated, then transmitted back again (usually through the DRI if OpenGL is supported) to be displayed.
An extension that AIGLX provides is the ability to transmit just the pixmap manipulation commands to the X-server display so the manipulation can occur there, eliminating the need for data to be carried back and forth, significantly improving performance.
Advantages and disadvantages
There are in fact more similarities between the two architectures than differences. The two projects “borrow” code off each other to a very large extent. Both support new effects for composite window managers using resources in the GPU. Both support legacy 2D applications. In short, both have great promise.
At the moment, “compiz” is the composite window manager for SuSE/Novell’s XGL, and a modified “metacity window manager” to include composite functionality is earmarked for the RedHat’s AIGLX solution. However, once any problems are sorted out and they’re complete, any composite window manager should work with either solution. Standards rule here. Both development processes are making use of the free software model, and both will probably be included in the X.ORG framework.
At the time of writing, a test version of XGL has been released into the wild while AIGLX is still very much in the developer’s corner. At the time of reading, that situation may have changed. XGL has probably been widely welcomed, and is liked.
XGL was designed from the beginning to be as easy as possible for an existing OpenGL graphical card vendor to implement. Currently, as long as the card’s driver can be connected to by an X-client that opens a full screen X window with OpenGL support for the body of the window, it can run XGL. In the future, it’s possible the vendor won’t need to produce an X-server at all, just a means of interpreting OpenGL APIs onto a display and from a keyboard and mouse. I believe it runs on all cards that currently support OpenGL acceleration through the X windows system.
AIGLX is far more an incremental improvement of the existing X-server drivers rather than a rewrite of them. However, for it to function correctly, alterations often need to be made in the vendor’s OpenGL drivers themselves, many of which are proprietary so it’s harder to implement there than the XGL solution.
Both, as I previously mentioned, support legacy 2D X-client applications. But, currently, only AIGLX can take advantage of OpenGL Direct Rendering for games and the such. XGL is limited to the GL-X mechanism here. The reason for this is that the X-Server and the DRI mechanism need to co-operate with each other. However, in the GL-X solution, the X-Server that the X-client connects to is (currently) not the one that does the actual displaying. It’d probably be a very major hack to include this, and could simply be unfeasible. AIGLX wouldn’t have a problem here because X could implement DRI the same way as it does on systems now.
AIGLX also has the advantage of giving the hardware vendor opportunities to implement more goodies such as FrameLock, Quad-Buffered stereo, Workstation Overlays or SLI. By the way, I got that list from a presentation by Andy Ritger from Nividia for the 2006 XdevConf. I don’t know exactly what they are or their relevance, but Nividia obviously want to take this route toward creating a richer experience for GNU/Linux desktop users.
Another kid on the block
Before signing off with a conclusion I would like to draw attention to yet another project that is not unrelated. This is the “Virtual GL” project, which is working at supporting GL accelerated applications through a TCP network. The way this works is that a GL application running on a central server uses its GPU to perform 3D rendering, but rather than displaying the resulting pixmap on a screen there (which could be thousands of miles from the person running the program) it decodes and compresses it and streams the display to the remote user’s machine which uncompresses it and encodes it on the screen.
This project is still in its development phase, but it looks promising. Running full blown shoot-em-all, fast-car, wizzing OpenGL games on a remote machine may be possible after all!
Conclusion
Going back to the XGL vs AIGLX confrontation, the news is there really isn’t one. Both compliment each other and help each other; and not just in the extensive code sharing the developers are involved in. They share far more similarities than there are differences. XGL is easier to implement for hardware vendors who want to exercise minimal development effort in GNU/Linux solutions, and AIGLX is good for those who wish to take the desktop experience to new heights.
I am looking forward to witnessing GNU/Linux being taken to new places by both projects.