OK.
I've recently made some changes that will reduce the footprint of display lists
in mesa 3.1. These are a lot less intrusive than the full solution of a
display-list postprocessor which I'd previously envisaged as necessary to solve
the problem, and contain less possibilities for major instabilities. I've tried
most of the applications I can get my hands on, and the all seem to work, but I'd
be grateful if people made some quick checks of their pet projects against this
change.
I've also been looking at the type of data that xracer is storing in its lists
and basically it can be improved quite easily by sorting the polygons within each
display list according to texture. This is quite easy to achieve - i've attached
a perl script which does the job nicely.
The changes I've made to Mesa are probably sufficient to get xracer running on
most systems, but the script should help performance by minimizing state changes.
You would also find performance would probably improve if the display lists
included a little more geometry in each list. You originally have about 4
vertices per statechange (cough), and after sorting this is about
20/statechange. For reference, q3test is quite well designed and manages up to
1024/statechange...
Keith
PS. Note that the script on its own won't solve the problems running with mesa -
you need to update to the latest CVS no matter what.
PPS. The script is should be applied to demo.trk.gz (after decompressing), and
matches the format used in xracer-0.90
fix_xracer.pl
