On 5 June 2012 14:42, Ian Romanick <[email protected]> wrote: > 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:ian.d.romanick@intel.**com <[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.
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. >
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
