Guillaume Cottenceau wrote:
>
> Pedro Rosa <[EMAIL PROTECTED]> writes:
>
> > Hi!
> >
> > There are several problems on using applications based on GL engines and
> [...]
> > test3Dfx kills badly the comp.
>
> The support for Voodoo is not here yet in Cooker. That fact is that to
> build the DRI stuff for XFree-4 we need a more recent Glide library then
> the one which is currently in Cooker; Yoann is working to get that, but
> apparently the guys do not release often so he has to extract stuff from
> CVS and it takes time to do this in a somewhat stable fashion.
>
Well I've been trying to wake up this dri stuff on my own hands. It
seems that there is a long cat's tail well behind this.
For years I've used the "hacked" gl stuff from Mesa. This trick, that
allows Mesa to work without X, managed to work until the latest cooker
post-7.1 stuff. Now it says "can't find Voodoo Graphics..." when
launching. No matter what I did (well anyway I have some _years_ playing
with this stuff) I couldn't get a hint. The last time it worked, my
machine had 4.0.1 (from a XFree86-4.0-mdk.src.rpm patched by me),
kernel 2.4.0-test4. Now with the latest sources from cooker, my old
board vanished misteriously. I tested everything and specially the
links, references and calls. It gets to Glide and bang - "can't
find...".
>
> > Second problem Mesa, GLX & Voodoo3. This card has given some serious
> [...]
> > CVS tree.
>
> That's exactly what we need to build when we'll have the latest Glide
> library.
>
> > In the meantime I tried to use Quake2 in gl (do not confuse with glx)
> > mode. libGL.so does not work with it. This didn't happen before.
>
> Francois? (I don't see clearly the "do not confuse with glx"; to me you
> can not anymore get any acceleration without glx/dri).
Tu me demande se je suis de France? Non je suis portugais. Excuse mon
francais mais je n'ai pas lui practiquee pres longtemps.
On what concerns gl & glx. The gl "hack" still exists on Mesa. However
one should go another way to compile it - edit some stuff, "make
linux-glide" or similar, and install the stuff mostly by hand. Libraries
made through "configure" have some oops to use on gl.
>
> [...]
>
> > I checked the Mesa spec and noted that glide has been "killed"
> > (configure --without-glide). Besides glx module is compiled as glx-3.
>
> Yes, because we have to choose glide or utah-glx (this is for xf-3)
> (according to giuseppe ghibo); and glide is supposedly supported through
> the tdfx_dri with xf-4.
>
Yeap. Unfortunately there is something real wrong with this tdfx_dri...
X does not seem to have it. Rebuilding X shows several *_dri.so drivers
but no tdfx. Even DRI from CVS on sourceforge does not seem to compile
it. However DRI docs talk about its existence. And even say to turn off
DRI support on the kernel (why?). Could you give some hints about this?
> > In the meantime I would like to note the weird confusion of links &
> [...]
> > libGL.so->libGl.so.1 and such link is dead under both packages.
>
> Francois's big trick..
>
> His wrapper is supposed to dynamically load the correct stuff; his way of
> doing the things make even Quake3 work, whereas the Redhat wrapper fails
> in that issue.
>
Well the wrapper is cool stuff. But I don't see the point... I made a
more correct linking and left the wrapper on libGL.so.1. It seems to
work as before.
> It has been successfully tested with i810 and ati-mach64, for the moment.
> The acceleration with i810 (with a p3-733, ok) is pretty impressive (q3
> with all things turned to full quality).
i810? How stable?
>
> > Some similar things happen with Glide packages. They are not so critical
> [...]
> > version either point to "traditional" or "non-traditional" libs.
>
> With XFree-4.0 we had a working tdfx_dri stuff. I tested it myself on a
> Voodoo 3 (it needed Glide-V3-DRI) and it was quite nice. (I don't know
> the nominative speed of a voodoo3, and moreover my test machine is based
> on an amd-k6/2-300 so..). It was running q3-demo or FlightGear at good
> framerate.
>
> We can expect a working solution, when we have the tdfx_dri module ready.
>
> > This might look "secondary" for some people here. Unfortunately I don't
>
> Mo :-) we (mostly Francois) are working hard to provide a Real Gamers
> Distribution for the 7.2 :-)).
Any help needed? Really I can kill a few hours because GL is BADLY
NEEDED. In any case I can test it even on non-gamer apps that use GL as
a base. There speed may not be so critical but things are still too
slow. Besides here we have several machines and boards on Linux. Most of
them Celleron & PII. In a month some PIII and Athlon should come in.
Motherboards are mostly IBM, Asus & Abit. We have uni and dual-proc
machinery. Videocards range from a stupid S3Trio to TNT2. Besides I have
access to a GeForce card. And half-staff is Linux fan (the other half
you may guess). If your problem is testing...
>
> More seriously, we want to provide out-of-the-box acceleration for most
> common cards, including i810, voodoo, tnt/geforce. it's possible, and it's
> under its way.
>
> [...]
>
> > Mandrake has always shown some oddities when referring to 3D,
> > visualization and image processing. I don't remember any Mandrake dist
> > that didn't force me to recompile/rebuild several things from scratch.
> > And this does not happen only with Voodoo boards but also with Riva
> > ones. This refers not only to GL & Mesa but also to old good svgalib
>
> Riva has a problem because the drivers are not open-source. We cannot
> provide them, sorry.
Know that. But anyway you can test them right? In fact, what is needed
to do with Riva drivers is to kick up a few things on X.
Anyway I am not the Riva expert here. But on an older "highly patched"
Mandrake 6.1 with 4.0.1, Riva flies. I know that NVIDIA are (*skipped* -
very long comment) on what concerns their drivers. But I think that a
few tests+possible patches may give users an easier life to install
NVIDIA's drivers. They do not install smoothly on some machines. For you
and me, this reflects on some words more in address of NVIDIA. For a
regular user, it can be an headache.
>
> > (this time it works really bad!) and something like gimp (1.0 & 1.1).
>
> What is the problem with svgalib? It works fine here for 7.0 and 7.1.
Right. For 7.0 & 7.1. On cooker post-7.1 (well, people are reading a new
distro right?) things crash badly on VESA option (comp freezes
sometimes) and show some funny effects on BANSHEE option (magenta screen
at start of SVGALIB app, console trashed). Similar things happen with
the lastest tarball of svgalib btw. But this time, the comp doesn't
freeze anymore. For info the comp is a dual Celleron 300a speeded up to
450Mhz on Abit BP6 128M with Voodoo3 3000+Voodoo Graphics board
(hardware never showed any conflicts for half year). I tested this
situation on one latest build of mandrake kernel & 2.4.0-test* kernels.
>
> --
> Guillaume Cottenceau -- Distribution Developer for MandrakeSoft
> http://www.mandrakesoft.com/~gc/
Ektanoor
