[Piglit] [PATCH] CL: Fix check of ULP when probing float/double results

[Ilia Mirkin]

On Tue, Dec 29, 2015 at 1:01 PM, Aaron Watry <awatry at gmail.com> wrote:
> Hi Jan/Tom,
>
> Sorry to resurrect an ancient thread, but I was poking at the piglit CL ULP
> issue last night, and thought I'd try to get us closer to a solution after
> dropping the matter for too long.
>
> I've modified your test program with what I was thinking of trying, and I
> wouldn't mind your feedback.
>
> I realize that we still have issues with discrepancies between
> python-generated expected results based on cpu/rounding mode and the , but
> I'd at least like for us to be able to nail down the C portion before we
> start redefining all of our expected test results.  In the long term, we
> probably want to hand-select our inputs/outputs instead of trusting python,
> but I don't necessarily think that we should block fixing our ULP
> calculations on getting that done.
>
> For now, I'm still ignoring the half-ULP possibility, and just generating a
> minimum/maximum allowed value based on running nextafterf(expected, POS/NEG
> INFINITY) in a loop for ULP iterations. Does that sound like a tenable
> solution?

I'm not 100% sure what you're trying to do, but Micah Fedke (and to a
lesser extent I) spent a ton of time trying to make
GL_ARB_shader_precision piglits in an automated manner (the ext
specifies allowable error for a bunch of functions). We ended up with
a solution which can test some very basic things on its own (single
operations), but any complex function basically can only be tested
with manually-selected values.

Take a look at generated_tests/gen_shader_precision_tests.py .

The basic issue that you have to contend with is that if you ever end
up with a mul + add anywhere in the intermediate calculation of
anything (e.g. dot product), it might get collapsed into a fma(),
which will mess things up greatly. For example imagine you have the
following code:

x = uniform value which == a * b;
y = a * b - x

One way y == 0, another way y == some small but not insignificant
number due to the added precision in the a*b calculation. No amount of
ULP cleverness will save you here.

If this has nothing to do with what you're trying to achieve, feel
free to ignore :)

  -ilia