[Mesa-dev] [v2 PATCH 09/16] glsl: Optimize clamp(x, 0, 1) as saturate(x)

[Roland Scheidegger]

Am 08.07.2014 08:22, schrieb Matt Turner:
> On Mon, Jul 7, 2014 at 11:00 PM, Erik Faye-Lund <kusmabite at gmail.com> wrote:
>> On Mon, Jul 7, 2014 at 7:18 PM, Matt Turner <mattst88 at 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?