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

[Ian Romanick]

On 06/04/2012 03:23 PM, Paul Berry wrote:
> On 4 June 2012 14:50, Ian Romanick <idr at freedesktop.org
> <mailto:idr at freedesktop.org>> wrote:
>
>     On 06/04/2012 01:31 PM, Olivier Galibert wrote:
>
>         On Mon, Jun 04, 2012 at 01:11:13PM -0700, Ian Romanick wrote:
>
>             From: Ian Romanick<ian.d.romanick at intel.__com
>             <mailto:ian.d.romanick at intel.com>>
>
>             In single precision, 1.5707963 becomes 1.5707962513
>             <tel:1.5707962513> which is too
>             small.  However, 1.5707964 becomes 1.5707963705
>             <tel:1.5707963705> which is just right.
>             The value 1.5707964 is already used in asin.ir <http://asin.ir>.
>
>             NOTE: This is a candidate for stable release branches.
>
>
>         If piglit stops bitching on that partical problem thanks to such a
>         small change, it's just beautiful.
>
>
>     It does fix the acos issue in piglit.  The closed-source test suite
>     that we use still isn't happy, but I think that just means we need
>     better approximations for acos and asin.
>
>     asin(vec4(.2, .6, .8, 1.)) has an absolute error of (0.0000105351
>     0.0001987219 0.0001262426 0.0000003576).  The results for .6 and .8
>     are especially bad, but even the .2 result should be better.  The
>     closed-source test suite wants an absolute error of 1e-5 for asin
>     and acos.
>
>
> Do we have any quantitative information about how much accuracy is
> really needed for asin?  Of course, an error of 1.9e-4 would be
> embarrassingly bad for scientific use, but are you sure that it isn't
> adequate for graphics purposes?  I'd hate to spend a lot of effort

The test expects an absolute error not more than 1e-5, and other desktop 
implementations achieve that.  I don't think we should be significantly 
less precise than other implementations.

> implementing a more accurate asin, only to find that the only
> user-visible effect is for shaders to run slower because we're doing
> more accurate math.  As fun as it is to numerically approximate trig
> functions (I'm not even kidding--I love this stuff and I'm jealous that

I didn't think for even a fraction of a second that you were kidding. :)

> I don't have time to work on it right now) I'm not convinced it's worth
> it yet.
>
> Having said that, I *do* think it's worth making sure the asin function
> is well-behaved enough near zero that derivatives won't do unexpected
> things.  If you do wind up working on this, I hope you'll keep the
> improvements I made last july (d4c80f5f85c749df3fc091ff07b60ef4989fa6d9)
> where I made the first two terms of the approximation pi/2 and pi/4-1.
> If these terms aren't exact, then asin behaves poorly near zero.

Right.  I've been trying to think of a good way to test this, but I keep 
coming up empty handed.

>         Do we need a better precision atan, or should piglit just be told to
>         shutup?  The shutup patch has been sent it ages ago, but I can't do
>         the "more precision" one if that's what's wanted.
>
>
>     I think we need a better atan.  The result that it produces is not
>     very good.  I plan to look into that more tonight.
>
>
> FYI, our formulas for atan and acos are exact trig identities in terms
> of asin, so probably any improvement made to asin will carry over to the
> others, at least until you reach the realm of rounding errors (which I'm
> guessing you won't reach if your target is 1e-5).

That's a good point.  Starting with asin may bear fruit more quickly 
than starting with atan.