[2978] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: Accelerated 3D driver for Dell Linux NVIDIA?

daemon@ATHENA.MIT.EDU (Alex T Prengel)
Thu Sep 27 18:26:10 2001

Message-Id: <200109272226.SAA00985@dit.mit.edu>
To: wdc@MIT.EDU, ghudson@MIT.EDU
cc: alexp@MIT.EDU, release-team@MIT.EDU
Date: Thu, 27 Sep 2001 18:26:06 -0400
From: Alex T Prengel <alexp@MIT.EDU>


>Inasmuch as we run in patches for Sun OpenGL, I wanted to raise the
>question:  Do we want to consider running in an RPM with an enhanced
>driver for 3d and OpenGL on the Dell/Linux box?

To jump into this conversation- this potentially affects a lot of Third Party
software. I created a mesa locker a while back, built binaries from source
and am using it to run almost all of the important Third Party OpenGL apps
I have installed. The reason I did this was that at the time (somewhere
around last May) almost all OpenGL apps I tried to run were segfaulting
when I tried to run them with the default /usr/lib/libGL.so.1.
(/afs/athena/software/mesa is actually an AFS symlink to allow me to
transparently switch the locker contents to new releases).

I also noted when I did that that Mesa development is pretty rapid and the
libraries change frequently (which was a significant argument for putting
them in a locker).

I'm also concerned that if we go to hardware accelerated LibGL.so (and related
libs), we might have a whole bunch of different libraries for different
graphics cards ("a maze of twisty little passages, all different").

What I'd like is either one single set of libGL* libraries that I can
put in the Mesa locker that will work on all machines/graphics cards
we have, or assurance that local /usr/lib/libGL* libraries will work
properly without segfaulting (there also things like libGL.la that come
with Mesa but I'm not sure if they're necessary or not).

In the former case I'm not sure we can do it without giving up
hardware acceleration. In the latter, I would probably switch things
like /afs/athena/software/mesa/lib/libGL.so to being symlinks to things
like /usr/lib/libGL.so since I've standardized quite a few lockers to
look in /afs/athena/software/mesa/lib; however I'd also lose the ability
to update the libraries outside of the release cycle.

I'm open to whatever people feel is most reasonable but the libraries can't
be broken (like they were last spring).

                                              Alex



home help back first fref pref prev next nref lref last post