[5970] in Release_7.7_team
Re: libGL.so graphics problem on Dell 745s
daemon@ATHENA.MIT.EDU (Alex T Prengel)
Tue Apr 22 15:44:56 2008
Message-Id: <200804221944.m3MJiC3e006503@dit.mit.edu>
To: "andrew m. boardman" <amb@MIT.EDU>
cc: alexp@MIT.EDU, wdc@MIT.EDU, release-team@MIT.EDU
In-Reply-To: Your message of "Tue, 22 Apr 2008 14:30:07 EDT."
<200804221830.m3MIU7WD004309@pothole.mit.edu>
Date: Tue, 22 Apr 2008 15:44:11 -0400
From: Alex T Prengel <alexp@MIT.EDU>
X-Spam-Flag: NO
X-Spam-Score: 0.00
>> 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?
Well, if there's no other way to make things work I suppose I'll have to,
though I wish I didn't need to. There's about a dozen or so lockers I'll
need to kludge, test and remember to do this to every time there's a software
update. This gets really nasty when some versions work for some applications
but not others. I'll most likely stick with the lowest (and slowest)
common denominator (my old Mesa lib or an updated version of that).
A.
