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

[Paul Berry]

On 5 June 2012 14:42, Ian Romanick <idr at freedesktop.org> wrote:

> 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 <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.


Ok, the fact that other desktop implementations achieve 1e-5 is enough to
convince me.


>
>
>  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 (**d4c80f5f85c749df3fc091ff07b60e**
>> f4989fa6d9)
>> 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.


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.


>
>
>         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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120605/a354ded0/attachment.htm>