Am 20.12.2014 um 03:02 schrieb Matt Turner:
> On Fri, Dec 19, 2014 at 5:04 PM, Jason Ekstrand wrote:
>> v3: fmin and fmax technically aren't commutative or associative. Things
>> get funny when one of the arguments is a NaN.
>
> I have a difficult time believing that the GLSL definitions of
Hi Jason,
The DX10 version of min/max is indeed commutative. However, GLSL specs
define min/max using a conditional assignment:
mix(x) = y < x ? y : x;
max(x) = x < y ? y : x;
which means that if either argument is NaN, x is returned., which
means that you can combine open-coded min/max function
On Fri, Dec 19, 2014 at 6:02 PM, Matt Turner wrote:
>
> On Fri, Dec 19, 2014 at 5:04 PM, Jason Ekstrand
> wrote:
> > v3: fmin and fmax technically aren't commutative or associative. Things
> > get funny when one of the arguments is a NaN.
>
> I have a difficult time believing that the GLSL d
On Fri, Dec 19, 2014 at 5:04 PM, Jason Ekstrand wrote:
> v3: fmin and fmax technically aren't commutative or associative. Things
> get funny when one of the arguments is a NaN.
I have a difficult time believing that the GLSL definitions of min()
and max() intentionally have that effect.
To
This commit adds some algebraic properties to the metadata of each opcode
in NIR. In particular, you now know, just from the metadata, if a given
opcode is commutative or associative. This will be useful for algebraic
transformation passes that want to be able to match a + b as well as b + a
in o
