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

--- Comment #2 from Clément Guérin geecko.dev@free.fr --- Created attachment 105765 --> https://bugs.freedesktop.org/attachment.cgi?id=105765&action=edit Black pixel glitch in Stylized demo

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

--- Comment #4 from Clément Guérin geecko.dev@free.fr --- Created attachment 105767 --> https://bugs.freedesktop.org/attachment.cgi?id=105767&action=edit Black pixel + low light glitch in Realistic Rendering demo

Should look like this: https://www.youtube.com/watch?v=3AAf_2vry8A

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

Christoph Haag haagch@frickel.club changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |haagch@frickel.club

--- Comment #6 from Christoph Haag haagch@frickel.club --- HD 7970M pitcairn here.

On an early unreal tournament pre-alpha build I had these artifacts very extremely: https://www.youtube.com/watch?v=mjbANgbIR6o

In a new build they are reduced, but it still happens: https://www.youtube.com/watch?v=J4yT2cUXMcw

Here is another Video from another user with a HD 7790M: https://www.youtube.com/watch?v=0-zlT93DdyU

When you are talking about motion blur on cameras, are you talking about the glitch you can see in this video? https://www.youtube.com/watch?v=lkDLlCEBKPA This happened a while ago and it does not happen anymore. I think at least for me this is fixed.

But I think my Realistic Rendering demo is still too dark too.

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

--- Comment #8 from Marek Olšák maraeo@gmail.com --- (In reply to Christoph Haag from comment #7)

I think in the new "Lightroom Interior" the blackness glitch is visible in a more interesting way: https://www.youtube.com/watch?v=R9N-srsF_Fg

I think I've tracked down what's causing the blackness in all Unreal Engine demos: Division by zero.

There are several options to fix this:

1) Use V_RCP_LEGACY_F32 instead of V_RCP_F32 (not available on Tonga and later chips).

2) Emulate V_RCP_LEGACY_F32(x) using (x != 0 ? 1/x : 0). This can be done in Mesa or LLVM. For LLVM, a new intrinsic rcp.legacy needs to be added.

3) Disable lowering DIV_TO_MUL_RCP in glsl-to-tgsi and see what happens. Not sure if this will change anything, but at least LLVM doesn't need the lowering and we might need to do the same workaround for TGSI_OPCODE_DIV.

I've implemented (2) in Mesa and it fixes the Lightroom Interior demo. I'm not sure if that's the best solution.

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

--- Comment #10 from Marek Olšák maraeo@gmail.com --- (In reply to Henri Verbeet from comment #9)

(In reply to Marek Olšák from comment #8)

...

(In reply to Christoph Haag from comment #7)

...

I think in the new "Lightroom Interior" the blackness glitch is visible in a more interesting way: https://www.youtube.com/watch?v=R9N-srsF_Fg

I think I've tracked down what's causing the blackness in all Unreal Engine demos: Division by zero.

I didn't debug this of course, but it seems suspicious that this would depend on division be zero returning zero instead of infinity. I don't think any other driver for current hardware does that with GLSL. Are you sure there's not a subsequent multiplication by zero that depends on INF * 0 returning 0 instead of NAN?

Yes, that's possible. However, some internal documents suggest that Catalyst always uses the standard IEEE version of MUL. There are also alternative opcodes for RSQ, RCP and LOG that don't generate NaNs and Infs, which can be used instead. You can certainly choose which behavior you want on a case-by-case basis. Sometimes you want 0 instead of NaN, other times you want 0 or FLT_MAX instead of Inf. The hardware has RSQ and RCP opcodes that do that.

However, Tonga and later hardware doesn't have the legacy dx9 opcodes for MUL, MAD, RCP, RSQ, and LOG and they must be emulated with a comparison (or V_CLASS_F32 that returns whether it's NaN/+-Inf/Denorm/+-0/etc) + conditional assignment. It's better to do the conditional assignment after every RCP than after every MUL.

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

--- Comment #12 from Clément Guérin geecko.dev@free.fr --- I just upgraded mesa-git with the NaN fix.

Black pixel and motion blur glitches are gone. Nice work!

Low lighting glitch is still here. "can be seen in the Realistic Rendering demo or the Shooter Game demo with the Sanctuary map"

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

--- Comment #14 from Clément Guérin geecko.dev@free.fr --- (In reply to Michel Dänzer from comment #13)

Make sure you use the current versions of the demos. I was seeing the darkness in the first version of the Realistic Rendering demo, but it's fixed with the current version, and Shooter Game looks fine as well.

It's great if latest versions of Unreal Engine don't have this issue, but it also means it's not exposing a potential driver bug anymore. This could show up later :(

If anyone else can confirm it's fixed, I think we can close this bug report.

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

Marek Olšák maraeo@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED

--- Comment #16 from Marek Olšák maraeo@gmail.com --- (In reply to Henri Verbeet from comment #11)

(In reply to Marek Olšák from comment #10)

...

However, Tonga and later hardware doesn't have the legacy dx9 opcodes for MUL, MAD, RCP, RSQ, and LOG and they must be emulated with a comparison (or V_CLASS_F32 that returns whether it's NaN/+-Inf/Denorm/+-0/etc) + conditional assignment. It's better to do the conditional assignment after every RCP than after every MUL.

Interesting, I wonder how that works out for Direct3D 9 applications. I don't suppose there's a global switch instead like (at least some) Intel and NVIDIA hardware has?

Yes, there is. See the commit.

Fixed by Mesa commit 2150db4d5daad3781876254d2b440367afd756cd. Closing.