[Piglit] [PATCH v3 2/3] arb_shader_precision: add framework for calculating tolerances for complex functions

[Ilia Mirkin]

On Mon, Mar 2, 2015 at 5:14 PM, Micah Fedke <micah.fedke at collabora.co.uk> wrote:
> In my approach, the error discovered by comparing the ~infinite precision
> result to the finite precision result *is* the allowable error range.  It's
> like saying "This function diverged from the true result by amount x when
> simulated at finite precision on the CPU, so we need to give it x amount of
> leeway when it is run on the GPU."  The finite precision result should be a
> complete representation of how error truly propagated through the
> intermediate stages of the equation, for the given inputs.

As seen by the CPU. TBH, I have no clue what the precision guarantees
are for the various functions are on CPUs, but it seems unlikely to be
identical to the ones in ARB_shader_precision. I sort of assume that
all the simpler ops are supposed to be within 1 ULP on the CPU, but...
who knows. (x87 had a few colorful opcodes which I'm sure introduce
tons of error... some taking over 1K cycles on the original 8087,
which wasn't exactly a speed demon to begin with.) It seems like
you're computing error due to fp32 representation limitations rather
than due to calculation imprecision.

I understand that it's annoying to have spent a bunch of time on
something that seems so trivial, but having failing tests due to the
test being wrong is _quite_ annoying (and I say this having debugged a
few such tests). I may give the approach I suggested a shot shortly,
at least for a few ops, to see what the code looks like. Note that I
have about 30 side-projects, and this would join that list... so...
don't want to set the wrong expectations :)

FWIW I never actually ran the results of your tests on my nvc0,
perhaps I should do that. If it passes, then maybe what you have in
practice is good enough, despite not being what the spec wants. Would
love to hear opinions from others as well.

  -ilia