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

[Erik Faye-Lund]

On Tue, Jul 8, 2014 at 5:44 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> 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.

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.