Commen=
t # 7
on bug 10354=
4
from Roland Scheidegger
(In reply to Ilia Mirkin from comment #6)
> The main difference between IEEE and non-IEEE is=
whether 0 * infinity =3D 0 or
> NaN. IEEE makes it mean NaN. DX9 behavior is 0. I added a flag to be u=
sed by
> st/nine to enable the DX9 behavior optionally, but leave the IEEE beha=
vior
> for GLSL. (There was some additional desire to expose that in a GL ext=
for
> WINE to use, but it got shot down pretty quickly.)
>=20
> Perhaps there are other changes from using the IEEE instruction varian=
ts,
> e.g. denorms, which would be undesirable. I was never too familiar wit=
h the
> R600 ISA.
I don't think these chips can do denorms at all.
I quickly looked at some trace, and indeed it looks like NaNs popping up in
some RT (which has a rgba16f format), and in that case it will then show as
black in the final output later.
I could not figure out what fragment shader is responsible for it, the NaNs=
are
always surrounded by pixels which are all black (hence making them
indistinguishable in qapitrace visually), plus that texture which gets the =
NaNs
is also blitted to from other textures via glBlitFramebuffer, which also
already has NaNs and so on, and I didn't invest all that much time...
I guess though the question is why other mesa drivers render it correctly a=
nd
how they avoid the NaNs if they also use ieee conformant behavior (if they
actually render it correctly...).