XFree86/Mesa GLX 

                     ******** Known Bugs *********

   Note: unless otherwise stated, client programs mentioned are 
         from the samples directory of (also in the Mesa package): 

       ftp://sgigate.sgi.com/opengl/contrib/examples.tar.Z

1) The GLX server reports that it supports protocol version 1.0. It 
   appears to also support version 1.1. There are undoubtedly functions 
   that aren't yet implemented and some that don't work correctly. Need 
   to catalog what's implemented and what's not.

2) With version 0.4, initial render large support is implemented for 
   TexImage2D, but not yet for other potential render large requests. 
   Textures now generally seem to work on the quad and texture sample 
   programs and the sphere program works the same as client side Mesa 
   (overly magnified texture?). 

   0.5 fixes problems with 3.rgb crashing on some of the programs in 
   the above mentioned sample clients and being incorrectly scaled are 
   fixed in 0.5. 

   In 0.6 render large is implemented in the client lib for all 
   potential cases from 1.0:

     glTexImage1D, glTexImage2D, glDrawPixels. glMap1d, glMap2d, 
     glMap1f, glMap2f, glBitmap, glPolygonStipple, glCallLists, 
     glPixelMapfv, glPixelMapuiv, glPixelMapusv 

   These routines have has very little testing (primarily glTexImage2D, 
   glBitmap, and glDrawPixels). Many of the others are based on the 
   same low-level formatting routines, but the floating point 
   transfers are unique and haven't had much testing. 

   Remaining potential render large requests are the unimplemented 
   1.2 functions:        

     glDrawArrays, glPrioritizeTextures, glTexSubImage1D, glTexSubImage2D

   Version 0.3 included this patch to Mesa 2.2 that prevents the 
   server crash with improperly formatted large mipmaps, for 0.4 you 
   should back it out to enable mipmap textures:

*** Mesa/src/texture.c-2.2      Sat Apr 26 16:46:09 1997
--- Mesa/src/texture.c  Sun Apr 27 23:35:32 1997
***************
*** 3338,3343 ****
--- 3338,3348 ----
            || t->MinFilter==GL_NEAREST_MIPMAP_LINEAR
            || t->MinFilter==GL_LINEAR_MIPMAP_LINEAR) {
  
+          if (!t->Image[0]) {
+              t->Complete = GL_FALSE;
+              break;
+          }
+ 
           /* Test dimension-independent attributes */
           for (i=1; i<MAX_TEXTURE_LEVELS; i++) {
              if (t->Image[i]) {

3) Mesa 2.2's version macros result in the starup messages reporting
   Mesa 2.1. Heard from Mr. Paul that macro's aren't intended to match 
   Mesa package level, there will be package version macros in Mesa 2.3.
 
4) The sphere example program appears to have hidden surface removal 
   problems as the torus spins edge on. The client side Mesa rendering
   does not exhibit this problem. The torus looks something like this:

              ---                      ---
             (   )                    (   )
            (     )                  (     )
            |  __ /                  |     |
            |  |                     |     |
            |  |  Instead of ----->  |     |
            |  |__                   |     |
            |     \                  |     |
            (     )                  (     )
             (___)                    (___)

   This program also results in a very heavy CPU load, much higher than 
   with client side MESA, and since it's running synchronously in the
   X server it may make the it appear that the server is hung.

5) There has been a report of gaps between adjacent polygons. 

6) Thomas Mueller has reported of a brownish cast in colors: 

   > Using XF86_SVGA on a Matrox Millennium it looks as though the colors
   > produces by the glx code are a little brownish. Colors of book/tea
   > which are 7f7f/7f7f/7f7f in Mesa-2.2 are 6d6d/6d6d/5555 with glx.

   I haven't noticed any sign of this, at least visually, in 8bpp 
   psuedocolor, 16bpp 565 truecolor, 32bpp RGBX truecolor, with both 
   6 and 8 bit dac. Should be investigated at the pixel data level. 

7) Steven Parker's Web page lists several other problems, see:
  
      http://www.cs.utah.edu/~sparker/xfree86-3d

   Including: 

      _Generally fails to display programs running under Irix 6.2.

      _Selection/feedback buffers.
   
 
                      ********* TO DO ***********

1) Test, test, test....

2) Catalog what fuctions are supported and which aren't.

3) Complete render large requests. Besides editing in changes for other
   cases, this needs a lot of testing (multiple data requests, boundary 
   cases,...). See #2 in the bugs section.

4) Syncing up with latest MESA version and supporting more requests.
   Some of the problems may have to do with changes since 2.0b2 which
   version 0.1 of this package was originally released against.
   I've started working with first 2.3 beta and there are some
   changes, though mostly reorganization of files, but there have
   been changes to the calls for drawing polygons (general polygon
   renderer replaced by tri and quad specific routines).
 
5) Test and document linkkit procedure, should just be variation on 
   the stactic link procedure.

6) Mesa conversion for the new XFree86 3.9+ loadable module support.
   This involves changing stdlib routines to using XFree86 wrapper
   libs (for cross-platform portable binaries) and ifdef-ing out 
   duplicate symbols (primarily in the xmesa*.c files). Will 
   probably wait for Mesa 2.3 to undertake this.

7) Long term issues of who will archive and maintain this package will need
   to be resolved. Particular problems include the need to keep it in sync
   with Mesa, so I hope this package will eventually be folded back into
   the Mesa package. Also how to handle build and release of general
   releases.

8) Software rendering to memory in the server needs to done in another
   thread or child process to avoid blocking X-event processing for 
   extended periods. Doing this portably is the rub. 

9) To reduce the client to server overhead, it would be desireable to
   make use of shared-memory for local data transport and pixmaps. 
   More extensive direct support is problematic without special hardware 
   or lots of client/server coordination and locking overhead to handle 
   clipping for overlaying windows. Add in portablility requirements and...
   Such facilites though, would be useful for general X server speedup.

