Re: [Quesa-develop] Re: Quesa - Optimization ideas.

[Edward K. C. <ek...@lg...>]

On Feb 12, 2004, at 11:06, Dair Grant wrote:

> Edward K. Chew wrote:
>
>>> What about __fsqrt? Brian used it in all of his code. I'm assuming it
>>> was because it was/is faster than sqrt.
>>
>> I think __fsqrt is only implemented on the G5 (PPC970), am I right?
>
> That's correct, I think Seth is referring to __frsqrte.
>
>
>> It would be great to use __fsqrt, but presumably you would then need
>> two version of the Quesa library: one for the G5 and one for pre-G5s.
>
> The optimisations would be done through some kind of function pointer
> which Q3Math_SquareRoot and Q3Math_InvSquareRoot could invoke.

Sounds good, though __fsqrt, being the single instruction in assembly 
that it is, is just itching to be inlined, isn't it?  ;-)  But you're 
right: even in a function which does nothing else, you should see a 
significant benefit.

> I.e., if you knew you could be happy with lower precision results you
> can use one of those routines rather than sqrt or 1/sqrt.
>
> Today they just call through to sqrt and 1/sqrt, but if this was done
> through a function pointer you could have a sqrt-based approach for
> non-PowerPCs and __frsqrte for PowerPCs (and __fsqrt for G5s).

I had one case recently in which a unit normal vector somehow wound up 
with a length of 1.00001, presumably thanks to my version of sqrt.  
Then I think I did an asin on it and it was, of course, NaN City after 
that.  Generally, I doubt that for 3D graphics, a slight loss of 
precision would cause any harm, but there may be a few special cases to 
watch out for.

I guess if you are using one level of indirection through a function 
pointer, you could add an API to let one choose between the fast 
transcendental functions and safer ones?

>> If you need a whole batch of single-precision square roots, I would
>> recommend vec_rsqrte as an alternative to __frsqrte.
>
> Yes, Q3Vector3D_DotArray and Q3Triangle_CrossProductArray could also 
> use
> a similar scheme - calling a scalar implementation for the general 
> case,
> and AltiVec/SSE when available.

You know, if you added a fourth redundant dimension to the Cartesian 
coordinate system, you could load points, vectors, etc. as true altivec 
vectors and perform a number of operations VERY quickly, albeit at the 
cost of some unused memory.  Hmm...

-Ted