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

[Kenneth Graunke]

On 07/20/2012 04:15 PM, Matt Turner wrote:
> 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.

Yeah, okay, that's what I figured.  I don't really care either way, so
feel free to go ahead with this unless somebody else objects. :)

Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>