Kendall Bennett wrote:
>
> Keith Whitwell <[EMAIL PROTECTED]> wrote:
>
> > My real point was that most of the time that we lose is lost to other
> > things than just adjusting the stride of arrays.
>
> It is not the adjusting of the stride for the arrays that is the
> problem, but the geometry engine does not output a vertex that is
> already in the correct format for the 3dfx driver.
In the q3 (and q2 for that matter) pipelines, the only redundant step is
a single copy operation. Everything else in the fx setup code
represents real work, which must be done in either one place or the
other. Like the cookie monster, rearranging the cookies on the plate
doesn't alter their number.
Here is a sketch of the pipeline:
transform: obj->clip
cliptest: clip->(clipmask, 1/w, win)
setup: (win, tc0, tc1, rgba)->fx vertex
clip-and-render: (you-dont-wanna-know)
The setup stage:
- Copies the win values.
- Translates the rgba from ubyte to float. We get the rgba in ubyte,
so this is the first time we touch them - no possible improvement here.
- Project the texcoords - similarly this is the first time we see them
- so no real room for improvement.
All you can do to improve this picture is:
1) Have cliptest output win and 1/w directly into the fx vertices.
This should be just a stride operation, but the grVertex struct is a
mess so it's slightly worse than that. For the D3D vertices
2) Improve what goes on inside clip-and-render.
If you consider pipelines with texgen and lighting operations, the
amount of redundant work increases, but those stages have plenty of
other scope for improvement.
If you consider the immediate pipeline (ie the one you get if you use
glVertex, etc) you have again a lot of room for improvement.
Keith
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
