On Tue, Jul 8, 2014 at 5:44 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 08.07.2014 08:22, schrieb Matt Turner: >> On Mon, Jul 7, 2014 at 11:00 PM, Erik Faye-Lund <kusmab...@gmail.com> wrote: >>> On Mon, Jul 7, 2014 at 7:18 PM, Matt Turner <matts...@gmail.com> wrote: >>>> This comment tripped me up for a second. This really means that you've >>>> found either >>>> >>>> - min(max(x, 0.0), 1.0); or >>>> - max(min(x, 1.0), 0.0) >>> >>> Hmm, but are optimizing both of these to saturate OK? Shouldn't >>> min(max(NaN, 0.0), 1.0) give 0.0, whereas max(min(NaN, 1.0), 0.0) give >>> 1.0? >> >> Under standard IEEE rules, wouldn't the NaN propagate through all of >> these expressions? > not under ieee754-2008 rules, no. min/max return the other number if one > of them is a NaN.
I'm not entirely sure what IEEE754-2008 has to say about min/max, as GLSL already defines those operations (and states that IEEE754 compliance isn't required). I was referring to the definition of the less-than comparison-operator, which GLSL seems to lean on. And that seems to always evaluate to 'false'. > This is enforced by d3d10 so at least d3d10 capable > hardware is going to honor that. > http://msdn.microsoft.com/en-us/library/windows/desktop/cc308050%28v=vs.85%29.aspx > The order of min/max though indeed matters. Right, this is very useful information, thanks. This makes me think that the perhaps the dependence on the less-than definition could be considered a spec-bug. A quick test reveals that NVIDIA's Windows driver implement both min(0.5, NaN) and min(NaN, 0.5) as returning 0.5. So I'd say: raise an issue with Khronos, and implement DX10 rules. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
