[Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
Ian Romanick
idr at freedesktop.org
Tue Jun 5 23:42:56 CEST 2012
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.
More information about the mesa-dev
mailing list