I think that you're supposed to set LIBGL_ALWAYS_INDIRECT=true (on the
client, the one running the X server) otherwise you'll end up with software rendering.
You can check if you're getting software rendering or not with "glxinfo
| grep renderer"
But on my system I can't seem to get this to work, I'll either end up
using the clients or the servers' software renderer... A huge thanks to you for this key LIBGL_ALWAYS_INDIRECT suggestion! I cannot find a man page where LIBGL_ALWAYS_INDIRECT is documented. I looked specifically for this in the Xorg, xorg.conf, intel, and even radeon man page, and also using a google search for a man page reference. That google search did find some non-man documentation that indicated the value should be "1" rather than "true" which explains why it is not working for you. Here are some interesting LIBGL_ALWAYS_INDIRECT results on the (g33) raven machine (where the X clients like foobillard are located) from my 945GME X-terminal where the X server is running. When LIBGL_ALWAYS_INDIRECT is not set, I get the following results: irwin@raven> glxinfo |grep render direct rendering: Yes OpenGL renderer string: Software Rasterizer So it was that Software Rasterizer that was killing the speed of foobillard. When LIBGL_ALWAYS_INDIRECT is set to 1, I get very different results. irwin@raven> export LIBGL_ALWAYS_INDIRECT=1 irwin@raven> glxinfo |grep render direct rendering: No (LIBGL_ALWAYS_INDIRECT set) OpenGL renderer string: Mesa DRI Intel(R) 945GME GEM 20091221 2009Q4 x86/MMX/SSE2 That clearly identifies the 945GME (where the X server is located in this case) as where OpenGL rendering will be done, and indeed with LIBGL_ALWAYS_INDIRECT=1, foobillard is playable via my X-terminal! So thanks again for directing me to this solution. I don't think I had to set this environment variable for my corresponding tests several years ago, but I may just not be remembering properly. However, clearly it is necessary now, and I wish that environment variable was better documented. I have asked this question a number of places (including lxer.com and Dave Richards's blog where he is the guy who is managing ~500 thin Linux clients for the City of Largo, Florida) where I expected someone would have the answer. But nobody did (the general ignorance of X networking transparency by veteran Linux users is frightening) until you came through. You have made my day.
[...]And just for clarity, I'm neither an Intel employee or an X dev - just
another user :) That's allowed and even encouraged. :-) This list was started as a list for the Intel X community of users and developers which is why I joined it at its inception as a user. It is great to get fundamental help here like this from another user. I hate to end on a negative note, but I have also tried etracer (extreme tuxracer) with LIBGL_ALWAYS_INDIRECT=1, and it is not playable (difficulties even using the mouse-driven menus) from my X-terminal even though it can be run directly without issues. So there is clearly still a performance regression of 3D display over the network (assuming etracer is not that different from tuxracer) compared to the classic X intel stack that I used for my tuxracer tests several years ago, but it is not as extreme (since at least foobillard works smoothly with LIBGL_ALWAYS_INDIRECT=1) as I first reported. Nevertheless, I am still hoping for an answer from the Intel developers on whether improving the efficiency of 3D display over the network is at least on their agenda. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
