Pedro Rosa <[EMAIL PROTECTED]> writes:
> Hi!
>
> There are several problems on using applications based on GL engines and
> latest Cooker builds. First let me note that these problems are
> experienced with a wide array of applications and two types of 3Dfx
> boards: Voodoo Graphics & Voodoo 3 3000.
>
> First problem Voodoo Graphics. The Glide sources for this card do
> present some problems, specially on some asm directives. However
> personally I managed to "give food" to my old Voodoo card until 7.1. On
> the recent Cooker builds and sources, Glide 2.46 can't find the card in
> any way. I tried everything I could but no success (used old 2.2, used
> 2.4 with & without devfs). Until now it is darkness on the forest.
> 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.
> Second problem Mesa, GLX & Voodoo3. This card has given some serious
> troubles in performance. However it worked acceptably until one of the
> latest builds of XFree 4.0.1. Since the moment when Mesa package was set
> as an X "outsider" (Mesa installation declares conflicts with X build)
> everything went into Tortuga Island. GLX works without DRI. Besides GLX
> lives the same life with or without DRI on the kernel. X docs specify
> the existence of a tdfx_dri but I couldn't find anywhere in the source
> how to build it. Only a reference to dri.sourceforge.net and their DRI
> 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).
[...]
> 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.
> In the meantime I would like to note the weird confusion of links &
> library locations I have noted in latest cooker packages. libGlwrapper
> seems to compile as libGLW on original Mesa sources. Mesa and Mesa-devel
> have several "dead links" and a confusion between "who's first who's
> last". Most package show links of the kind lib.so->lib.so.1->lib.so.1.1.
> But here we have a link on Mesa as libMesaGl.so.1.0->libGL.so.1.0 then
> we have a libMesaGL.so.1->libGL.so.1 (dead!). And in Mesa-devel we get a
> libMesaGL.so->libGL.so that is located in this same pack. But
> 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.
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).
> Some similar things happen with Glide packages. They are not so critical
> as there are not dead links. However if ones commits the "stupidity" of
> installing Voodoo Graphics and Voodoo3 DRI drivers then he gets some
> unpleasant surprises. Links get divided between the "traditional" Glide
> 2.6/3.1 drivers and the new ones, in a way that links with the same main
> 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 :-)).
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.
> (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.
--
Guillaume Cottenceau -- Distribution Developer for MandrakeSoft
http://www.mandrakesoft.com/~gc/
