High level architecture of Utah-GLX By John Carmack -- 2000 March 10 ----------------------------------- Four different shared object files are produced by the utah-glx cvs tree. The main utah-glx module "glx.so" is built from the files in glx/servGL/* and installed in /usr/X11R6/lib/modules. A separate donwload of an apropriate mesa codebase (3.2) is required, and will be linked to glx/servGL/mesaglx/ by the configure script. It must be explicitly loaded by adding lines to your XF86Config file: Section "Module" Load "glx.so" EndSection The OpenGL client library "libGL.so" is built from the files in glx/libGL/* and installed in /usr/X11R6/lib. Originally, the only duty of this library was to implement the glx wire protocol to pass the client's OpenGL commands on to the X server where they were interpreted and executed. Keith's implementation of direct rendering now allows the client library to load the glx.so server module and program the hardware directly in some cases. This is a fairly hairy setup, but was done with minimal impact on the code and performs quite well. The OpenGL utilitiy and toolkit libraries libGLU.so and libglut.so are unmodified copies of the standard mesa files. They should be completely interoperable with any OpenGL library, and are just build for convenience. Two additional programs will be involved with actually using utah-glx. An XFree86 X server must load the module before anything, including direct rendering, will work. We support XF86_SVGA for mga and s3virge, XF86_Mach64 for mach64, and XF86_Fbdev for mach64 on ppc. An application that uses OpenGL must link to libGL.so and use it. Our most common test programs are the mesa demos, the various Quakes, and xscreensaver modules. ------------ ---------- | X server |---| glx.so | ------------ ---------- | root priveledges ==|====================================== | user priveledges ----------- ??????????????????????????????????????? | xlib.so | ? glx.so (only when direct rendering) ? ----------- ??????????????????????????????????????? | | | | ------------ | | libGL.so |-------------- | ------------ | | | | | | | ------------- -------------- | | | libGLU.so |--| libglut.so | | | ------------- -------------- | | | | --------- | | | gears |--------------------- --------- glx.so can be divided into three major parts: the main mesa library, the hardware drivers, and the infrastructure. The main mesa code is basically the same as in any other use of mesa. <SOMEONE: what exactly is changed based on the defines we compile mesa with> We hardly ever have to touch anything in the mesa code. The hardware drivers servGL/hwglx/mga|mach64|i810|s3virge perform the actual programming of the different 3D chips. They interact with mesa through mesa's ctx->Driver structure, and with the infrastructure through the GLXProcs structure. Due to some more clever hacking on Keith's part, we are able to compile a single glx.so with all hardware drivers included, even when they rely on X servers that aren't present. The infrastructure will determine which one to actually initialize. The infrastructure is in servGL/serverglx. This is the messiest part of the entire project, due to the way things evolved. The original codebase was designed to parse the glx wire protocol, make the apropriate calls into mesa, and implement a software driver for mesa that would draw to X windows. The addition of hardware drivers with software fallback and direct rendering haven't meshed all that well with parts of it. A lot of stuff is lying around for the old software based rendering that we step on every now and then and explode because of. See my "PLEASE COMMENT" email of a few days ago for a look at how I would like to rewrite the infrastructure to driver interface. The current interface is similar enough that it can give you some information, but beware hidden landmines... (this post is available through the list archives as http://lists.sourceforge.net/pipermail/utah-glx-dev/2000-March/001464.html) John Carmack
