Hi -
I've just switched my laptop to modular xorg from pkgsrc. It has
some Intel i945 chipset graphics, not supported by the xfree86
sources in the NetBSD main tree, so something had to be done.
(I had tried to use xfree-4.6 within NetBSD's reachover build
structure which worked basically, but since I'm not able to
maintain this further I've given up on this. See an earlier
post on this list.)

The modular xorg server in pkgsrc doesn't build the GLX extension
for now. This is mostly a technical issue because Mesa sources
are required at build time which is not straightforward in pkgsrc.
It is easy to do anyway, so I've built an X server with GLX right
now, using the xorg 1.1.1  server and Mesa-6.5.1 sources.
(Mesa-6.5.2 looks harder because there are some assembler files
which need changes to the Makefiles, but this might be fixed in
newer, unstable xorg sources. I didn't want to go that far.)

DISCLAIMER: I'm mostly clueless about OpenGL/glx/etc issues.
Please correct me if I'm talking nonsense.

Now I've got an X server which does support GLX as did the xfree
server built within NetBSD's main tree. Next question is what
performance gain I get.
What I found is that the Mesa library from pkgsrc doesn't make
use of the GLX extension at all. GL rendering is always done
at the client side. The Mesa library built within NetBSD's
xfree framework does support GLX, but it is not used by any
pkgsrc application, and it is relatively old. (It identifies
itself as "OpenGL version string: 1.2 (1.5 Mesa 6.2.1)" in
the "glxinfo" tool.)

It is not so hard to get GLX support into MesaLib again - just
build the code within srx/glx/x11. I've done this to pkgsrc's
version 6.4.2.
The libGL I'm getting out of this does appearently support GLX.
(If I run some benchmark application like glxgears (from
fkgsrc/glx-utils) or glclock I'm seeing that with GLX support
almost all CPU utilisation goes to the X server, while without
GLX the bigger part goes to the client application.)

There are two questions now:
1. Is it desirable at all for the X server to offer a GLX extension
   if there is no real hardware support? If the clients are doing
   the hard work, there is a chance that the load is spread among
   multiple CPUs or cores, while the singlethreaded X server would
   be a bottleneck if multiple clients are using it. There is
   probably less data to be transferred with GLX but for a local
   client this doesn't matter much. I didn't see a difference in
   alsolute performance with glxgears or glclock.
2. Mesa's GL libraries as the xorg one built in NetBSD's tree or
   the 6.4.2 built in pkgsrc with glx support appearently don't
   support a fallback to Mesa's client-side GLX emulation. So an
   application trying glx fails completely if the X display doesn't
   support GLX. The Mesa code appearently has some means to switch
   the backend dynamically, but for some reason it is not used.
   So is this a build failure? I can't believe that this was
   done deliberately. Strange that this happens with both the
   NetBSD tree's build and the modified pkgsrc, but perhaps some
   magic option was missed in both cases.

best regards
Matthias