Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On Tue, Jun 05, 2012 at 04:51:54PM -0700, Paul Berry wrote: 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. Can't you take the perfectly reasonable hypothesis that the system's asin is precise, and upload something like a 256x256 R32FG32FB32FA32F texture with reference values? 262144 testing points should be good enough :-) And that's something that generalizes easily to all the functions you may want to test on a segment. OG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On 06/06/2012 05:16 AM, Olivier Galibert wrote: On Tue, Jun 05, 2012 at 04:51:54PM -0700, Paul Berry wrote: 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. Can't you take the perfectly reasonable hypothesis that the system's asin is precise, and upload something like a 256x256 R32FG32FB32FA32F texture with reference values? 262144 testing points should be good enough :-) And that's something that generalizes easily to all the functions you may want to test on a segment. OG. There's at least one problem with that: if the hardware only supports N active textures at once, and the application already asked to use all N of those...you don't have a texture available for this. Which is maybe not a big deal if you just need one, say, for asin...but if you want one for asin, one for noise, one for ... I suppose you could combine them into one texture. Still, it's kind of annoying to deal with. Also, arithmetic instructions tend to be vastly cheaper than texture lookups, so you can probably get a fairly nice algebraic approximation in that amount of space. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On 6 June 2012 10:31, Kenneth Graunke kenn...@whitecape.org wrote: On 06/06/2012 05:16 AM, Olivier Galibert wrote: On Tue, Jun 05, 2012 at 04:51:54PM -0700, Paul Berry wrote: 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. Can't you take the perfectly reasonable hypothesis that the system's asin is precise, and upload something like a 256x256 R32FG32FB32FA32F texture with reference values? 262144 testing points should be good enough :-) And that's something that generalizes easily to all the functions you may want to test on a segment. OG. There's at least one problem with that: if the hardware only supports N active textures at once, and the application already asked to use all N of those...you don't have a texture available for this. Which is maybe not a big deal if you just need one, say, for asin...but if you want one for asin, one for noise, one for ... I suppose you could combine them into one texture. Still, it's kind of annoying to deal with. Also, arithmetic instructions tend to be vastly cheaper than texture lookups, so you can probably get a fairly nice algebraic approximation in that amount of space. There's some missing context here. Ian was asking for suggestions on how to *test* asin(), not how to implement it. As a testing technique Olivier's suggestion would be ok, although not ideal because it relies on floating point textures--it would be nice if floating point texture support weren't required to run our piglit tests for asin(). Also, it's not entirely clear to me from the original context, but I thought Ian was looking for suggestions on how to test that dFdx(asin(x)) behaves well near x=0. Testing asin(x) at 262144 points won't necessarily validate that the derivative behaves well, because it's possible that a small discontinuity near x=0 could result in a very badly behaved derivative even if asin(x) is within tolerance for all x. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On 06/04/2012 03:23 PM, Paul Berry wrote: On 4 June 2012 14:50, Ian Romanick i...@freedesktop.org mailto:i...@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 Romanickian.d.romanick@intel.__com mailto:ian.d.roman...@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.105351 0.0001987219 0.0001262426 0.003576). 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 mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On 5 June 2012 14:42, Ian Romanick i...@freedesktop.org wrote: On 06/04/2012 03:23 PM, Paul Berry wrote: On 4 June 2012 14:50, Ian Romanick i...@freedesktop.org mailto:i...@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 Romanickian.d.romanick@intel.**__com mailto:ian.d.romanick@intel.**com ian.d.roman...@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.105351 0.0001987219 0.0001262426 0.003576). 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 mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
From: Ian Romanick ian.d.roman...@intel.com In single precision, 1.5707963 becomes 1.5707962513 which is too small. However, 1.5707964 becomes 1.5707963705 which is just right. The value 1.5707964 is already used in asin.ir. NOTE: This is a candidate for stable release branches. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Cc: Olivier Galibert galib...@pobox.com Cc: Paul Berry stereotype...@gmail.com --- src/glsl/builtins/ir/acos.ir |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/glsl/builtins/ir/acos.ir b/src/glsl/builtins/ir/acos.ir index f0078f8..8c3797e 100644 --- a/src/glsl/builtins/ir/acos.ir +++ b/src/glsl/builtins/ir/acos.ir @@ -4,26 +4,26 @@ (declare (in) float x)) ((declare () float s) (call asin (var_ref s) ((var_ref x))) - (return (expression float - (constant float (1.5707963)) (var_ref s) + (return (expression float - (constant float (1.5707964)) (var_ref s) (signature vec2 (parameters (declare (in) vec2 x)) ((declare () vec2 s) (call asin (var_ref s) ((var_ref x))) - (return (expression vec2 - (constant float (1.5707963)) (var_ref s) + (return (expression vec2 - (constant float (1.5707964)) (var_ref s) (signature vec3 (parameters (declare (in) vec3 x)) ((declare () vec3 s) (call asin (var_ref s) ((var_ref x))) - (return (expression vec3 - (constant float (1.5707963)) (var_ref s) + (return (expression vec3 - (constant float (1.5707964)) (var_ref s) (signature vec4 (parameters (declare (in) vec4 x)) ((declare () vec4 s) (call asin (var_ref s) ((var_ref x))) - (return (expression vec4 - (constant float (1.5707963)) (var_ref s) + (return (expression vec4 - (constant float (1.5707964)) (var_ref s) )) -- 1.7.6.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On 4 June 2012 13:11, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com In single precision, 1.5707963 becomes 1.5707962513 which is too small. However, 1.5707964 becomes 1.5707963705 which is just right. The value 1.5707964 is already used in asin.ir. NOTE: This is a candidate for stable release branches. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Cc: Olivier Galibert galib...@pobox.com Cc: Paul Berry stereotype...@gmail.com Reviewed-by: Paul Berry stereotype...@gmail.com --- src/glsl/builtins/ir/acos.ir |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/glsl/builtins/ir/acos.ir b/src/glsl/builtins/ir/acos.ir index f0078f8..8c3797e 100644 --- a/src/glsl/builtins/ir/acos.ir +++ b/src/glsl/builtins/ir/acos.ir @@ -4,26 +4,26 @@ (declare (in) float x)) ((declare () float s) (call asin (var_ref s) ((var_ref x))) - (return (expression float - (constant float (1.5707963)) (var_ref s) + (return (expression float - (constant float (1.5707964)) (var_ref s) (signature vec2 (parameters (declare (in) vec2 x)) ((declare () vec2 s) (call asin (var_ref s) ((var_ref x))) - (return (expression vec2 - (constant float (1.5707963)) (var_ref s) + (return (expression vec2 - (constant float (1.5707964)) (var_ref s) (signature vec3 (parameters (declare (in) vec3 x)) ((declare () vec3 s) (call asin (var_ref s) ((var_ref x))) - (return (expression vec3 - (constant float (1.5707963)) (var_ref s) + (return (expression vec3 - (constant float (1.5707964)) (var_ref s) (signature vec4 (parameters (declare (in) vec4 x)) ((declare () vec4 s) (call asin (var_ref s) ((var_ref x))) - (return (expression vec4 - (constant float (1.5707963)) (var_ref s) + (return (expression vec4 - (constant float (1.5707964)) (var_ref s) )) -- 1.7.6.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On Mon, Jun 04, 2012 at 01:11:13PM -0700, Ian Romanick wrote: From: Ian Romanick ian.d.roman...@intel.com In single precision, 1.5707963 becomes 1.5707962513 which is too small. However, 1.5707964 becomes 1.5707963705 which is just right. The value 1.5707964 is already used in 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. 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. OG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
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 Romanickian.d.roman...@intel.com In single precision, 1.5707963 becomes 1.5707962513 which is too small. However, 1.5707964 becomes 1.5707963705 which is just right. The value 1.5707964 is already used in 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.105351 0.0001987219 0.0001262426 0.003576). 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 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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On 4 June 2012 14:50, Ian Romanick i...@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 Romanickian.d.romanick@intel.**com ian.d.roman...@intel.com In single precision, 1.5707963 becomes 1.5707962513 which is too small. However, 1.5707964 becomes 1.5707963705 which is just right. The value 1.5707964 is already used in 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.105351 0.0001987219 0.0001262426 0.003576). 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 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 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. 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). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Fix pi/2 constant in acos built-in function
On Mon, Jun 04, 2012 at 03:23:34PM -0700, Paul Berry wrote: I'm not even kidding--I love this stuff and I'm jealous that I don't have time to work on it right now Do you have a favorite method for Vandermonde matrix inversion? OG. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
