Welcome to the forums.
The packages used were the latest for Edgy Eft.
I'll compile the drivers with the argument you mentioned when time permits and see how things change.
I doubt you'd see much of a difference, I've tried playing around with compile options and it's almost unnoticable. Not that I used any scientific benchmarks or anything.
Check out http://dri.freedesktop.org/wiki/Building
It'll tell you how to compile sources from CVS. In my experiance the cvs drivers offer better performance then standard stuff. Although that may just be because I am using a x800 card and the default distro drivers that I had installed at the time failed to accurately identify it and treated it as a generic r300 card rather then use any device-specific optimizations or features.
Also for best stability it may be wise to compile the kernel drm .ko modules for the kernel.
For the packaged software for the librm I did:
configure --prefix=/usr --exec-prefix=/usr
And for the Mesa stuff I copied the libGL stuff over the existing Debian package supplied software in /usr/lib
That way I didn't have to mess around with any Debian packaging stuff or ldconfig tricks and everythign works fine. The only snafu is that applications look for the *_dri.so files in the old monolythic X.org spot, so I setup a symbolic link to those from were the *_dri.so drivers are installed by default and that works fine.
Also it's nice to keep the source code tree relatively prestine so you don't have to worry about any compile stuff getting mixed up with the cvs tree which you may want to update time to time when you feel like compiling new drivers.
To do that you can use lndir.. You go like this..
Say you have ~/sources/Mesa
so you can go:
mkdir -p build/Mesa
and it should make a duplicate directory structure for you.
Last edited by drag; 10-09-2006 at 09:42 PM.
I've been thinking about this a bit. I suspect that the biggest performance difference on ET is r300's lack of acceleration for compiled vertex arrays. All Quake 3 based games make heavy use of this extension to reduce the geometry transfer load. It's only my todo list to add a generic acceleration path in Mesa for compiled vertex arrays for drivers that support buffer objects.
Originally Posted by marcheu
Of course, none of that will help the UT performance, and we really get spanked there...