On 06/04/2012 03:23 PM, Paul Berry wrote:
On 4 June 2012 14:50, Ian Romanick <[email protected]
<mailto:[email protected]>> 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@intel.__com
<mailto:[email protected]>>
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.
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
