On 5 June 2012 14:42, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 06/04/2012 03:23 PM, Paul Berry wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 4 June 2012 14:50, Ian Romanick <<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a><br></div><div class="im">
<mailto:<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>>> wrote:<br>
<br>
On 06/04/2012 01:31 PM, Olivier Galibert wrote:<br>
<br>
On Mon, Jun 04, 2012 at 01:11:13PM -0700, Ian Romanick wrote:<br>
<br></div>
From: Ian Romanick<ian.d.romanick@intel.<u></u>__com<br>
<mailto:<a href="mailto:ian.d.romanick@intel.com" target="_blank">ian.d.romanick@intel.<u></u>com</a>>><div class="im"><br>
<br>
In single precision, 1.5707963 becomes <a href="tel:1.5707962513" value="+15707962513" target="_blank">1.5707962513</a><br></div>
<tel:<a href="tel:1.5707962513" value="+15707962513" target="_blank">1.5707962513</a>> which is too<div class="im"><br>
small. However, 1.5707964 becomes <a href="tel:1.5707963705" value="+15707963705" target="_blank">1.5707963705</a><br></div>
<tel:<a href="tel:1.5707963705" value="+15707963705" target="_blank">1.5707963705</a>> which is just right.<br>
The value 1.5707964 is already used in <a href="http://asin.ir" target="_blank">asin.ir</a> <<a href="http://asin.ir" target="_blank">http://asin.ir</a>>.<div class="im"><br>
<br>
NOTE: This is a candidate for stable release branches.<br>
<br>
<br>
If piglit stops bitching on that partical problem thanks to such a<br>
small change, it's just beautiful.<br>
<br>
<br>
It does fix the acos issue in piglit. The closed-source test suite<br>
that we use still isn't happy, but I think that just means we need<br>
better approximations for acos and asin.<br>
<br>
asin(vec4(.2, .6, .8, 1.)) has an absolute error of (0.0000105351<br>
0.0001987219 0.0001262426 0.0000003576). The results for .6 and .8<br>
are especially bad, but even the .2 result should be better. The<br>
closed-source test suite wants an absolute error of 1e-5 for asin<br>
and acos.<br>
<br>
<br>
Do we have any quantitative information about how much accuracy is<br>
really needed for asin? Of course, an error of 1.9e-4 would be<br>
embarrassingly bad for scientific use, but are you sure that it isn't<br>
adequate for graphics purposes? I'd hate to spend a lot of effort<br>
</div></blockquote>
<br>
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.</blockquote><div><br>Ok, the fact that other desktop implementations achieve 1e-5 is enough to convince me.<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
implementing a more accurate asin, only to find that the only<br>
user-visible effect is for shaders to run slower because we're doing<br>
more accurate math. As fun as it is to numerically approximate trig<br>
functions (I'm not even kidding--I love this stuff and I'm jealous that<br>
</blockquote>
<br></div>
I didn't think for even a fraction of a second that you were kidding. :)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't have time to work on it right now) I'm not convinced it's worth<br>
it yet.<br>
<br>
Having said that, I *do* think it's worth making sure the asin function<br>
is well-behaved enough near zero that derivatives won't do unexpected<br>
things. If you do wind up working on this, I hope you'll keep the<br>
improvements I made last july (<u></u>d4c80f5f85c749df3fc091ff07b60e<u></u>f4989fa6d9)<br>
where I made the first two terms of the approximation pi/2 and pi/4-1.<br>
If these terms aren't exact, then asin behaves poorly near zero.<br>
</blockquote>
<br></div>
Right. I've been trying to think of a good way to test this, but I keep coming up empty handed.</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do we need a better precision atan, or should piglit just be told to<br>
shutup? The shutup patch has been sent it ages ago, but I can't do<br>
the "more precision" one if that's what's wanted.<br>
<br>
<br>
I think we need a better atan. The result that it produces is not<br>
very good. I plan to look into that more tonight.<br>
<br>
<br>
FYI, our formulas for atan and acos are exact trig identities in terms<br>
of asin, so probably any improvement made to asin will carry over to the<br>
others, at least until you reach the realm of rounding errors (which I'm<br>
guessing you won't reach if your target is 1e-5).<br>
</blockquote>
<br></div>
That's a good point. Starting with asin may bear fruit more quickly than starting with atan.<br>
</blockquote></div><br>