Comment # 7
on bug 103544
from Roland Scheidegger
(In reply to Ilia Mirkin from comment #6) > The main difference between IEEE and non-IEEE is whether 0 * infinity = 0 or > NaN. IEEE makes it mean NaN. DX9 behavior is 0. I added a flag to be used by > st/nine to enable the DX9 behavior optionally, but leave the IEEE behavior > 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.) > > Perhaps there are other changes from using the IEEE instruction variants, > e.g. denorms, which would be undesirable. I was never too familiar with 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 and how they avoid the NaNs if they also use ieee conformant behavior (if they actually render it correctly...).
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
