Keith Whitwell wrote:
>
> Eero Pajarre wrote:
> >
> > > The reason why I suspected the usefulness of the
> > > multitexture emulation is that without multitexture
> > > for example my application minimizes texture swapping,
> > > but the emulation will swap actively between the two
> > > textures. On the other hand the multitexture emulation
> > > will ofcourse decrease the amount of geometry
> > > transformations into half.
> > >
> >
> > On a short test with a Voodoo2
> > using FX_EMULATE_SINGLE_TMU and
> > FX_DONT_FAKE_MULTITEX
> > I got the following results:
> >
> > 1) (best) real multitexture
> > 2) single TMU no faking
> > 3) (worst) single TMU faking multitex
> >
> > The difference between the steps was
> > 5-10 % in framerate.
> >
> > All tests were run with a texture setup
> > which fit into the onboard memory.
> > (obviously it would be easy the get really
> > bad results with a the single TMU configs
> > using a larger texture set)
>
> This is a little suprising; can you give details of the application and/or any
> profiling information you have? It's been a while since I measured this, but it
> was inspired by q3 where there is significant geometry in each glDrawElements
> command - the speedup from skipping the stuff which can't be shared between
> passes (particularly clipping) is quite sigificant.
>
As I mentioned above this was a "short" test. I just let my
application (which is basically a driving simulator) to stay
at a single viewpoint for a while, and I compared the FPS figures
given by the application.
(Typically when I look at which routines consume
most time I analyze the program using Vtune, which
gives a sampling based line by line CPU consumption
estimate)
In any case my results "are just a single data point",
and they don't have any real value even for me, because --
I did the testing because of my Voodoo1 problems.
(And on my voodoo1 using Windows95 my program still
gets stuck somewhere inside Glide, so what ever performance
it would have is really not so important...)
I use multitexture to do textured geometry + shadow textures
on the geometry. The geometry is sorted based on the textures
before rendering. I have optimized my shadow map usage inorder to
minimize texture changes during the rendering, but my shadowmaps
still cause problems to the CVA vertex sharing (I have to duplicate
vertices because of the shadow maps, I have already optimized the
basic texture mapping regarding vertex sharing).
so my guess is that the reason that multitexture faking was
was slower than single texture for me was because of three factors:
1) bad vertex sharing on shadow maps also disturbed
the well behaving vertices in the basic texture+geometry
2) sorting by two textures together causes more state changes
than doing the textures separately
3) The implementation of the fake multitexture has penalties
(because of frequent texture changes)
Effect of this might be increased because I did several
drawelements calls for each texture set.
does the faking switch textures multiple times in this case?
I guess I will have to:
a) optimize my shadow maps for vertex sharing
b) run the tests again with VTune
Eero
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
