I decided to give the Mesa-glx package a try (for those who don't know,
the original Mesa provided the OpenGL-like API locally; Mesa-glx moves the
GLX support out of Mesa proper and into an X server extension where it
``belongs'').

First, in order to even use it, I found that I could not longer use
XF86_S3V (the X driver targeted for my S3-based ``ViRGE'' STB Nitro-3D
card).  (I gather that for some reason, the S3V driver is being
deemphasized in favor of the generic SVGA driver.)

If I tried to continue using the old X server, after installing Mesa-glx
and modifying XF86Config per the docs, I got error messages and X refused
to start.

Okay, I figured, I'd just modify the setup to use the SVGA driver/server.


Problem:

With ``startx -- -bpp 24'', Mesa doesn't seem to treat my display as quite
truecolor; it does fairly obvious dithering, reducing the image quality
and (I assume) taking more time.  The quality improves (but still falls
short of the original Mesa 3.0) if I use ``startx -- -bpp 32'', but then I
have to bump my resoultion down due to the memory constraints of my video
card.


It seems like the Mesa-glx might be rendering a fraction faster (I gather
that they do some MMX support, etc., even for cards like mine that aren't
directly supported).  However, it's hard to tell.

Can someone suggest something obvious in configuring/using Mesa to make
better use of a 24-bit display?  Or does SVGA not really do 24-bit
displays (effectively downgrading them to a 16-bit, maybe)?  Also, have
others noticed the inferior displays coming out of the Mesa-glx, as
opposed to the original Mesa 3.0?


Comments?  If I don't need to remotely run ``real'' OpenGL binaries,
should I just re-install Mesa 3.0 and wait for the SGI-based GLX to work
its way into our X server?


  "I probably don't know what I'm talking about."  --rkr@rkr.kcnet.com