<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 29, 2015 at 12:16 PM, Ilia Mirkin <span dir="ltr"><<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Tue, Dec 29, 2015 at 1:01 PM, Aaron Watry <<a href="mailto:awatry@gmail.com">awatry@gmail.com</a>> wrote:<br>
> Hi Jan/Tom,<br>
><br>
> Sorry to resurrect an ancient thread, but I was poking at the piglit CL ULP<br>
> issue last night, and thought I'd try to get us closer to a solution after<br>
> dropping the matter for too long.<br>
><br>
> I've modified your test program with what I was thinking of trying, and I<br>
> wouldn't mind your feedback.<br>
><br>
> I realize that we still have issues with discrepancies between<br>
> python-generated expected results based on cpu/rounding mode and the , but<br>
> I'd at least like for us to be able to nail down the C portion before we<br>
> start redefining all of our expected test results.  In the long term, we<br>
> probably want to hand-select our inputs/outputs instead of trusting python,<br>
> but I don't necessarily think that we should block fixing our ULP<br>
> calculations on getting that done.<br>
><br>
> For now, I'm still ignoring the half-ULP possibility, and just generating a<br>
> minimum/maximum allowed value based on running nextafterf(expected, POS/NEG<br>
> INFINITY) in a loop for ULP iterations. Does that sound like a tenable<br>
> solution?<br>
<br>
</span>I'm not 100% sure what you're trying to do, but Micah Fedke (and to a<br>
lesser extent I) spent a ton of time trying to make<br>
GL_ARB_shader_precision piglits in an automated manner (the ext<br>
specifies allowable error for a bunch of functions). We ended up with<br>
a solution which can test some very basic things on its own (single<br>
operations), but any complex function basically can only be tested<br>
with manually-selected values.<br>
<br>
Take a look at generated_tests/gen_shader_precision_tests.py .<br>
<br>
The basic issue that you have to contend with is that if you ever end<br>
up with a mul + add anywhere in the intermediate calculation of<br>
anything (e.g. dot product), it might get collapsed into a fma(),<br>
which will mess things up greatly. For example imagine you have the<br>
following code:<br>
<br>
x = uniform value which == a * b;<br>
y = a * b - x<br>
<br>
One way y == 0, another way y == some small but not insignificant<br>
number due to the added precision in the a*b calculation. No amount of<br>
ULP cleverness will save you here.<br>
<br>
If this has nothing to do with what you're trying to achieve, feel<br>
free to ignore :)<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>The issue that we have in CL piglits right now is that the program-tester is treating the ULP value for a given test as an absolute tolerance, not as floating units of least precision.<br><br></div><div>Example (generated_tests/cl/builtin/math/<a href="http://builtin-float-cos-1.0.generated.cl">builtin-float-cos-1.0.generated.cl</a>):<br>[test]<br>name: cos float1<br>kernel_name: test_1_cos_float<br>global_size: 12 0 0<br><br>arg_out: 0 buffer float[12] 1.0 0.0 -1.0 0.0 1.0 0.432574513059 0.753902254343 -0.145500033809 0.943808393901 0.626322983292 -0.925879022855 nan  tolerance 4 ulp<br>arg_in: 1 buffer float[12] 0.0 1.57079632679 3.14159265359 4.71238898038 6.28318530718 1.12345 7 8 1048576.0 16777216.0 1.32922799578e+36 nan <br><br></div><div>Let's take the second test:<br></div><div>cos(1.57079632679) [essentially cos(pi/2)] should be roughly 0.0. The test is specified with a tolerance of 4 ULP. The current piglit CL code is accepting any value in the range [-4.0, ..., 4.0], because it is treating the ULP as an absolute tolerance, not units of least precision.<br><br></div><div>Regardless of whether 0.0 is the absolutely correct answer for cos(1.57079632679), we can hopefully all agree that -4.0 is NOT a valid answer for cosine of anything<br><br></div><div>The functions that I'm trying to fix here (piglit-util-cl.c: piglit_cl_probe_[floating|double]), take:<br></div><div>1) The actual result from the kernel/shader.<br>2) The expected result defined in the test.<br></div><div>3) A ULP value to use to calculate the acceptable tolerances.<br><br></div><div>But it does it wrong. It was copy/pasted from the integer checking code which takes a tolerance...<br><br></div><div>--Aaron<br></div><div><br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><font color="#888888">
  -ilia<br>
</font></span></blockquote></div><br></div></div>