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. 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.
> > The GLSL 4.40 spec says > > "Operations and built-in functions that operate on a NaN are not required to > return a NaN as the result." > > So it seems like we have a lot of flexibility here. Is there some text > I'm missing? _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
