[Mesa-dev] [PATCH] glsl: Make blend_colordodge compare against 1.0 - FLT_EPSILON.
Kenneth Graunke
kenneth at whitecape.org
Mon Oct 3 05:17:46 UTC 2016
On Thursday, September 8, 2016 10:33:06 PM PDT Francisco Jerez wrote:
[snip]
> Heh, right, my concern was that this smells strongly like a test relying
> on not terribly well-defined behavior... AFAICT the problem addressed
> here is ultimately caused by the discontinuity that the COLORBURN
> blending equation has at the point Cd = 1, Cs = 0, and the test authors
> had the awesome idea [not necessarily being sarcastic here ;)] of
> testing the blending function at precisely that point, even though the
> function is guaranteed to be numerically unstable and vary wildly given
> the slightest rounding error.
>
> Does the extension impose any requirements on the precision of the
> division by alpha operation done on pre-multiplied color components?
> The test case may be valid assuming that IEEE precision rules apply, but
> AFAIK GLSL has considerably looser requirements on the division
> operation, and the KHR_blend_equation_advanced lowering code is
> implemented in terms of GLSL division so the result could potentially be
> farther off than 1 - epsilon (though AFAICT this change would be correct
> assuming the result of GLSL division is guaranteed to be within ~1.5 ULP
> of the exact value, which I don't think is the case).
FWIW, I finally filed a spec bug about this:
https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16042
We'll see what people think.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161002/22709e62/attachment.sig>
More information about the mesa-dev
mailing list