Bug 28293

The problem is using a shader to do the depth drawpixels.  The test considers the tolerable error to be (1 / (1 << depthbits) + 1 / (1 << formatbits)).  But when we sample the texture, the value is stored in a shader floating point reg, which only has about 12 bits of precision.

The GL 3.2 compat spec (also 2.1 spec) is saying that we need to have precision to about 1/10^5 unless otherwise specified for an operation (2.1.1 Floating-Point Computation).  I don't see other specification for precision on pixel transfer ops.  Guidance in the ARB_fragment_program spec seems to reinforce the "if it looks good, it is good" rule, though, and deemphasize 1/10^5 specifically.  If we tweak the test's tolerance to also include the 1/10^5 it still fails, but if the tolerance is bumped to include 1/10^3 for our GPU's fragment reg precision, it passes.

My conclusion is that the GL implementation is doing fine, until someone shows real-world rendering where this DrawPixels precision fudging is bad (and given that we have the same precision fudging *everywhere* in our fragment pipeline, this doesn't seem likely).  These two tests should add 1/1000.0 to test->tolerance[0] (and pxstore-depth.c, though it's not a complete solution to that one).

So, do you suggest us to give these two test case bigger tollerance to let them pass? by doing this we could track if they're getting worse intead of always showing a failure