[5969] in Release_7.7_team
Re: libGL.so graphics problem on Dell 745s
daemon@ATHENA.MIT.EDU (andrew m. boardman)
Tue Apr 22 14:30:14 2008
Message-Id: <200804221830.m3MIU7WD004309@pothole.mit.edu>
To: Alex T Prengel <alexp@MIT.EDU>
cc: release-team@MIT.EDU, wdc@MIT.EDU
In-Reply-To: Your message of "Wed, 16 Apr 2008 15:37:28 EDT."
<200804161937.m3GJbSEo030376@prevert.mit.edu>
Date: Tue, 22 Apr 2008 14:30:07 -0400
From: "andrew m. boardman" <amb@MIT.EDU>
X-Spam-Flag: NO
X-Spam-Score: 0.00
[dropped bugs from CC for the time being]
> I've tested a couple of additional libGL.fgl.so.1.2 libraries that are
> newer than the one in the current release (thanks to Andrew who
> pointed me to the rpms). The bad news is that none of them make
> Mathematica 3d graphics, my "Cone" code example and glxgears work at
> the same time. The only thing I've found that does is the old
> libGL.so.1.4.501 library I built years ago:
Thanks for the research. The frame rate on libGL.so.1.4.501 suggests
that it's not taking advantage of any of the hardware acceleration hooks
at all, which is probably why it actually works.
Barring a generally functional solution, any chance you could bundle the
various functional accelerated versions of libGL into the various
relevant lockers? I'm assuming that they'll also work fine on non-fglrx
machines, but given how flaky the rest of this looks, that could be an
unwarranted assumption. Alternately, you could include the vanilla
versions of libGL, and people could have something that would be at least
functional, if potentially slower.
