Kendall Bennett wrote:
>
> Keith Whitwell <[EMAIL PROTECTED]> wrote:
>
> > The percentage improvement you quote is largely due to the
> > introduction of the CVA extension, and its use in quake3. I am
> > told that Mesa's performance with Q3 on 3dfx hardware is comparable
> > to what you can expect from 3dfx's drivers on windows. That aside,
> > there is certainly still room for improvment on our code.
>
> 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
>
> As you can see, the Mesa 3dfx driver is running at nearly half the
> speed of the Banshee ICD, and this pretty much comparable to the same
> results that we get via GLDirect on the same hardware.
Quake2, even with CVA, uses a very different rendering path to Quake3.
We are comparing apples and oranges.
> > But, regarding your comments on the pipeline, if you look at the
> > newest CVS code, you'll notice the pipeline is now a data
> > structure, and is built and modified at runtime.
>
> Great! So you are saying that in the newest CVS code it will be
> possible to re-structure the output of the Mesa geometry pipeline to
> exactly match the hardware vertex formats? If so, that is exactly the
> type of thing we need (so now we need to re-code the 3dfx driver to
> utilise this; or has this already been done?).
The vector routines do not take an output stride, so my changes won't
fully satisfy this itch you got. But on the other hand, the profiling
results do not support the notion that 50% of our time is spent simply
coping data from arrays of one stride to another. If you are looking to
catch up with the other drivers, you will need to do a lot more
scratching.
Of course, you may find applications which manage to trigger a lot more
copying and transformation than the one which I have profiled. Why
don't you do some profiling of your own, and come back with concrete
figures, or better still concrete suggestions, or best of all, patches.
You'll probably find it easiest to do it in a special case stage which
performs all the operations of some simple pipeline. This way you don't
have to worry about who else might need the data, and what formats they
expect it in. Restrict yourself to the precalc pipeline, because
vertex-copy in gl_reset_vb() is one of the worst offenders. So in that
limited context, your goal is within grasp.
> Great. So it would appear then that some time is being spent copying
> and re-formatting the data structures internally in the 3dfx driver
> currently. If the 3dfx driver was updated to use the new vertex re-
> formatting stuff you mentioned in the geometry pipeline, this should
> speed that stage up by 30% right?
My real point was that most of the time that we lose is lost to other
things than just adjusting the stride of arrays. In particular, there
is a kink in the pipeline where we project to device space, and then
perform clipping in clip space, to produce more window- and device-space
vertices.
In the q3 pipeline, which is all I have profiling data for right now,
there is only one redundant copy outside of the clipping calculations.
This would appear to take about 3-5% of the time spent inside Mesa. As
a percentage of the total time (quake3 + mesa), be generous and call it
3%. So, for quake 3, fixing that one copy without doing anything else
will buy you maybe 1 frame per second at 30fps...
Anyway, I think you should dive in and read some code, think about how
you would implement what you are talking about, and make some concrete
suggestions. I don't doubt there are gains to be made, and I look
forward to discussing them with you.
Keith
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
