Kendall Bennett wrote:
>
> Well we just benchmarked this stuff last week using the absolute
> latest CVS sources and this is not what we found. Here's the timedemo
> results from Quake2 (timedemo 1, demomap demo1.dm2) at 640x480 (3Dfx
> Mesa would not go above this resolution - the Banchee ICD and
> MSWrapper go to 1280x1024):
>
> [Test machine: AMD K6 3DNow! 366Mhz, 98MB RAM, Quake2 v3.20 (supports
> vertex arrays & compiled vertex arrays).]
> 3Dfx Banshee ICD (Q3 compatible driver): 32.8fps
> Microsoft QuakeGL wrapper: 27.8fps
> 3Dfx Mesa (latest CVS source): 18.9fps
>
OK. So I was sitting there wondering just how devilishly clever those
3dfx driver writers are, when it occured to me that I was actually
seeing a pretty good frame rate, even with debugging and profiling
turned on.
And then a little penny dropped: you are the victim of software
fallbacks, most likely due to the GL_EXT_point_parameters extension.
I have it turned off in my quake2 setup, and also in my /etc/mesa.conf
file. My hardware is K6-2/350, with a voodoo-2. I set my mesa.conf
file to turn off multitexturing (the banshee has only a single tmu), and
repeated your benchmark. I assume the demo1.dm2 you use is the same one
that ships with the shareware quake2. With this configuration, no
ext_point_param, no cva, no multitex, I get a consistent 31fps with the
current stable CVS Mesa - the same one you would have tested with.
Assuming the banshee is faster at single-texture than a voodoo-2, it
really begins to beg the question - what can 3dfx do to catch up with
Mesa?
Also - did you compile in the 3dnow assembly? I don't know how easy
this is to miss as I use my own munged makefiles.
Keith
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
