Scott McMillan wrote:
>
> > BTW, the texture modes you're using put you on a very slow path
> > through Mesa. There are quite a few functions calls per pixel.
>
> Texturing (the underlying algorithms) is definitely not my strong
> suit. If you (or anyone) could enlighten me as to why this is a
> slow path, I would appreciate the info (even if only pointers to
> references).
First, when the texture min filter != mag filter Mesa must compute
a level-of-detail parameter per pixel to determine if minification
or magnification is needed. This is also needed for mipmapping.
It's not a cheap computation.
Second, linear sampling and application usually falls onto a slow path.
The problem is there's so many texture sampling options that it's a
mess to optimize them all.
For example, there's GL_REPEAT, GL_CLAMP, and GL_CLAMP_TO_EDGE
parameters which can be different for each texture axis. Then,
different things have to be done depending on whether a texture
border is present. Then the texels have to be pulled out of
the texture image, which can be in several formats. Then, the
texture environment has to be applied to determine the final
fragment color. There's 4 texture env modes and 6 image formats
resulting in 24 (give or take) different paths. All this adds
up to lots of possibilities.
Someday the texture code could be optimized with some pointer
tables into macro-generated, optimized functions. I probably
won't do that for a while.
The fast path is GL_NEAREST sampling, GL_REPEAT wrapping, RGB or
RGBA textures, GL_REPLACE texture env and GL_FASTEST perspective
correction hint. I think the demos/texobj.c program points this
out.
-Brian
----------------------------------------------------------------------
Brian Paul Avid Technology / Softimage [EMAIL PROTECTED]
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
