[Mesa-dev] [PATCH 1/4] Use INV_SQRT instead of 1/SQRTF

[Matt Turner]

On Fri, Jul 20, 2012 at 3:29 PM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On 07/20/2012 11:24 AM, Matt Turner wrote:
>> ---
>>  src/mesa/math/m_debug_norm.c |    4 ++--
>>  src/mesa/tnl/t_vb_points.c   |    2 +-
>>  2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/math/m_debug_norm.c b/src/mesa/math/m_debug_norm.c
>> index 02eb1f9..dc768f3 100644
>> --- a/src/mesa/math/m_debug_norm.c
>> +++ b/src/mesa/math/m_debug_norm.c
>> @@ -165,7 +165,7 @@ static void ref_norm_transform_normalize( const GLmatrix *mat,
>>           /* Hmmm, don't know how we could test the precalculated
>>            * length case...
>>            */
>> -            scale = 1.0 / SQRTF( len );
>> +            scale = INV_SQRTF( len );
>>           SCALE_SCALAR_3V( out[i], scale, t );
>>           } else {
>>              out[i][0] = out[i][1] = out[i][2] = 0;
>> @@ -241,7 +241,7 @@ static int test_norm_function( normal_func func, int mtype, long *cycles )
>>        ASSIGN_3V( d2[i], 0.0, 0.0, 0.0 );
>>        for ( j = 0 ; j < 3 ; j++ )
>>           s[i][j] = rnd();
>> -      length[i] = 1 / SQRTF( LEN_SQUARED_3FV( s[i] ) );
>> +      length[i] = INV_SQRTF( LEN_SQUARED_3FV( s[i] ) );
>>     }
>>
>>     source->data = (GLfloat(*)[4]) s;
>> diff --git a/src/mesa/tnl/t_vb_points.c b/src/mesa/tnl/t_vb_points.c
>> index 9edbbc7..0e33b69 100644
>> --- a/src/mesa/tnl/t_vb_points.c
>> +++ b/src/mesa/tnl/t_vb_points.c
>> @@ -64,7 +64,7 @@ run_point_stage(struct gl_context *ctx, struct tnl_pipeline_stage *stage)
>>        for (i = 0; i < VB->Count; i++) {
>>           const GLfloat dist = FABSF(*eyeCoord);
>>           const GLfloat q = p0 + dist * (p1 + dist * p2);
>> -         const GLfloat atten = (q != 0.0F) ? SQRTF(1.0F / q) : 1.0F;
>> +         const GLfloat atten = (q != 0.0F) ? INV_SQRTF(q) : 1.0F;
>>           size[i][0] = pointSize * atten; /* clamping done in rasterization */
>>           eyeCoord += eyeCoordStride;
>>        }
>
> Why change this?  I don't see why the new version is any better.  More
> precise, maybe?
>
> Also, why use INV_SQRT rather than just leaving all of these as 1.0 / SQRTF?

Really just because of the annoyance of having an INV_SQRTF macro and
then seeing 1.0 / SQRTF in the code. There's no functional change.

I thought about getting rid of SQRTF/INV_SQRTF but that was sort of a
hassle, and there is some possibility that they could be useful in the
future if we had some optimized routines.

> Patches 2-4 are:
> Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>

Thanks,
Matt