[Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function

[Kenneth Graunke]

On 06/06/2012 05:16 AM, Olivier Galibert wrote:
> On Tue, Jun 05, 2012 at 04:51:54PM -0700, Paul Berry wrote:
>> The best idea I've got so far would be a shader_runner test with a fragment
>> shader that computes dFdx(asin(x)), compares it to the theoretical closed
>> form derivative of asin(x) (which is 1/sqrt(1-x^2)), and draws red pixels
>> if the result is outside a certain error tolerance.  We'd probably want to
>> use a relative error (since the derivative of asin(x) can get quite large)
>> and stop a bit shy of the endpoints where it goes to infinity.
> 
> Can't you take the perfectly reasonable hypothesis that the system's
> asin is precise, and upload something like a 256x256 R32FG32FB32FA32F
> texture with reference values?  262144 testing points should be good
> enough :-)
> 
> And that's something that generalizes easily to all the functions you
> may want to test on a segment.
> 
>   OG.

There's at least one problem with that: if the hardware only supports N
active textures at once, and the application already asked to use all N
of those...you don't have a texture available for this.  Which is maybe
not a big deal if you just need one, say, for asin...but if you want one
for asin, one for noise, one for ...

I suppose you could combine them into one texture.  Still, it's kind of
annoying to deal with.  Also, arithmetic instructions tend to be vastly
cheaper than texture lookups, so you can probably get a fairly nice
algebraic approximation in that amount of space.