[Bug 103544] Graphical glitches r600 in game this war of mine linux native

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 1589 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=103544

--- Comment #7 from Roland Scheidegger <sroland@vmware.com> ---
(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.

[-- Attachment #1.2: Type: text/html, Size: 2496 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel