One of the more interesting aspects of the glX interface is GLX (not to be confused with glX), which specifies a mechanism for OpenGL calls to be encapsulated within the X11 network protocol. The purpose of GLX was to provide the same network-transparency that X11 itself has and to allow OpenGL applications to run on one machine while being rendered on another (with all of the capabilities of the display machine, such as hardware-accelerated vector operations).

One of the obvious requirements of supporting GLX is that the X server must understand GLX. As a result, the X server must be able to start up and manage an OpenGL context on its own. As a result, the X server is managing the OpenGL context - meaning that the synchronization issues are taken care of.

It was with this idea that the Utah-GLX project was started. What Utah-GLX did was to split Mesa into two parts - client and server. The client portion would simply connect to the server via GLX and send OpenGL calls encapsulated in the GLX protocol. The server portion, linked into XFree86 as an extension module, would handle the display of the OpenGL calls. This also neatly solved the security issue, because the X server already runs as root or otherwise has access to the low-level hardware ports.

This setup has one major disadvantage, however: like the microkernel approach to message-passing operating systems, most of the time spent in OpenGL programs ends up being in the passing of the messages and not in the creation or execution of them. To counteract this, Utah-GLX added in the ability for a program to interact directly with the server portion, but only if the program was running as root. However, this ended up becoming quite unstable, as the synchronization with the X server and between OpenGL contexts became unreliable once again.

One thing to notice is that, although Utah-GLX had the potential for responsible, delegated control of the graphics hardware, that functionality was never really implemented to any capacity. In fact, there was never any error checking between OpenGL contexts - if two contexts were created, the most likely outcome would be the X server crashing due to corrupted memory. In a sense, Utah-GLX was basically a rough prototype for things to come, and was never intended for serious workstation-quality hardware access. Although development vaguely continues on it, it will become obsolete when XFree 4.0 becomes mainstream - there is absolutely no interest or motivation in porting Utah-GLX to XFree 4.0, because that is where the next driver system, the Direct Rendering Infrastructure, comes in.


Detailed information:

  • Utah-GLX architecture overview