[Intel-gfx] An apparent large performance regression of 3D display over the network

Alan W. Irwin irwin at beluga.phys.uvic.ca
Fri Jan 28 01:15:01 CET 2011


> 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 at 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 at raven> export LIBGL_ALWAYS_INDIRECT=1
irwin at 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
__________________________



More information about the Intel-gfx mailing list