José Fonseca wrote:
> While I was debugging a new vertex buffer template for Mach64 I've
> discovered that this piece of code doesn't work:
>
> INTERP_F( t, (*dst++).f, (*out++).f * qout, (*in++).f * qin );
> INTERP_F( t, (*dst++).f, (*out++).f * qout, (*in++).f * qin );
>
> The problem is that INTERP_F is defined in src/mmath.h as:
>
> #define INTERP_F( t, dstf, outf, inf ) \
> dstf = LINTERP( t, outf, inf )
>
> while in turn LINTERP is defined as
> #define LINTERP(T, OUT, IN) \
> ((OUT) + (T) * ((IN) - (OUT)))
>
> so the OUT argument is being used twice and the pointer incremented
> twice as well.
>
> I think this is a bug in Mesa. First because a macro should generally
> behave as an
> ordinary function, unless there is a very special reason not to do so.
Hmm, not really, this is something people are supposed to understand about
macros generally - it's one of the classic C programming mistakes to assume
that macros evaluate their arguments exactly once.
> Second because this relies on compiler optimization to remove the
> redundancy of calculating OUT twice. Although I haven't check what is
> the exact assembler output of gcc, the call of INTERP_F with
> calculations in
> its arguments is used on the default vertex template, hence used across
> all drivers. See src/tnl_dd/t_dd_vbtmp.h:669:
You should check the output. Gcc does lots of
common-subexpression-elimination (cse). I'd be suprised if it didn't find
this one.
> INTERP_F( t, dst->v.u0, out->v.u0 * qout, in->v.u0 * qin );
> INTERP_F( t, dst->v.v0, out->v.v0 * qout, in->v.v0 * qin );
>
>
> Since it isn't pratical to change LINTERP, INTERP_F should be
> redefined to
>
> #define INTERP_F( t, dstf, outf, inf ) \
> do { \
> GLfloat temp = outf; \
> dstf = LINTERP( t, temp, inf ); \
> } while (0)
>
> and LINTERP shouldn't be used outside mmath.h. Other macros which call
> LINTERP should be checked too.
Maybe, but in general I'd be suprised if this produced better code than the
existing macro. On the other hand, it won't be any worse, either, so I don't
have any objection to doing this...
Keith
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
