ATI R300: Open v. Closed Drivers

[Michael]

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.

[drag]

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.


edit:

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:
cd ~/sources
mkdir -p build/Mesa
cd build/Mesa
lndir ../../Mesa

and it should make a duplicate directory structure for you.

[idr1]

However, I have one question : you seem to have used the default r300 ubuntu packages. These packages are compiled using the default Mesa optimizations options, which use -O. Would you mind testing again with a home-compiled version of r300 using, say, -O2 ? You have to get the Mesa tree for that, and touch the config/linux-dri target. I would expect that to make a difference.

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.

Of course, none of that will help the UT performance, and we really get spanked there...