Eero Pajarre wrote:
>
> When Vtuning my app I noticed a spike in CPU time in the
> routine responsible for calculating the color values for
> clipped triangles. This was caused by the float to int
> conversions.
>
> I did the following change (output from WinCVS diff) to
> clip.c
>
> 39a40
> > #include "mmath.h"
> 64a66,73
> >
> > #define INTERP_SZ_4I( t, vec, to, a, b) \
> > do { \
> > vec[to][3] = FloatToInt(LINTERP( t, vec[a][3], vec[b][3] )); \
> > vec[to][2] = FloatToInt(LINTERP( t, vec[a][2], vec[b][2] )); \
> > vec[to][1] = FloatToInt(LINTERP( t, vec[a][1], vec[b][1] )); \
> > vec[to][0] = FloatToInt(LINTERP( t, vec[a][0], vec[b][0] )); \
> > } while(0)
> 128c137
> < INTERP_SZ( t, VB->ColorPtr->data, dst, in, out, 4 );
> ---
> > INTERP_SZ_4I( t, VB->ColorPtr->data, dst, in, out);
> 158c167
> < INTERP_SZ( t, VB->ColorPtr->data, dst, in, out, 4 );
> ---
> > INTERP_SZ_4I( t, VB->ColorPtr->data, dst, in, out);
>
> This has worked for me (on Win95, VC++ 5.0), but I am not
> certain about the FAST_MATH etc issues on other compiles.
> My own reasoning is that changing the conversion from
> truncation to rounding might actually produce "better"
> results.
Seems like a reasonable general purpose improvement.
This is something I've addressed in two places in the experimental branch - first
in fxclip.c & fxclipttmp.h, which works backwards from device space to build
float-only clip-space vertices & clips them using only floating point ops.
The second improvment is on the fast path code which always builds floating-point
clip-space vertices as an interim step, performs clipping here and then projects
to device space. This is a very intuitive arrangement, but probably isn't what
we want to do for all cases.
With the current divergence of pipelines, it seems that all three techniques will
continue to be useful.
Keith
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
