Bug 83510 - Graphical glitches in Unreal Engine 4
Summary: Graphical glitches in Unreal Engine 4
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: Other Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-04 19:47 UTC by Clément Guérin
Modified: 2015-01-16 14:01 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Motion blur glitch in Shooter Game (1.08 MB, image/png)
2014-09-04 19:48 UTC, Clément Guérin
Details
Black pixel glitch in Stylized demo (1.31 MB, image/png)
2014-09-04 19:52 UTC, Clément Guérin
Details
Black pixel glitch in Mobile Game demo (1.07 MB, image/png)
2014-09-04 19:56 UTC, Clément Guérin
Details
Black pixel + low light glitch in Realistic Rendering demo (821.82 KB, image/png)
2014-09-04 20:00 UTC, Clément Guérin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Clément Guérin 2014-09-04 19:47:08 UTC
While all the Linux demos are now running fine, there is some rendering errors left.

- Some objects are blurred. It looks like motion blur on objects that don't need it, like cameras, characters or weapons. You can see it in the Elemental Demo or Shooter Game demo.
- Some pixels turn black when the camera is static, very noticeable on the sky box in the Mobile Game demo.
- It seems that the lighting is too dark in some scenes, can be seen in the Realistic Rendering demo or the Shooter Game demo with the Sanctuary map.

HD 7950, mesa-git and llvm-svn on latest Arch Linux.
Comment 1 Clément Guérin 2014-09-04 19:48:01 UTC
Created attachment 105764 [details]
Motion blur glitch in Shooter Game
Comment 2 Clément Guérin 2014-09-04 19:52:30 UTC
Created attachment 105765 [details]
Black pixel glitch in Stylized demo
Comment 3 Clément Guérin 2014-09-04 19:56:15 UTC
Created attachment 105766 [details]
Black pixel glitch in Mobile Game demo
Comment 4 Clément Guérin 2014-09-04 20:00:00 UTC
Created attachment 105767 [details]
Black pixel + low light glitch in Realistic Rendering demo

Should look like this: https://www.youtube.com/watch?v=3AAf_2vry8A
Comment 5 Maciej 2014-09-05 19:25:53 UTC
Can confirm, same thing on Cape Verde (7770) with 3.16.1 and latest mesa on Ubuntu 14.10.
Comment 6 Christoph Haag 2014-10-02 17:02:00 UTC
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.
Comment 7 Christoph Haag 2014-11-25 09:43:09 UTC
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
Comment 8 Marek Olšák 2014-12-04 12:32:44 UTC
(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.
Comment 9 Henri Verbeet 2014-12-04 13:38:16 UTC
(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?
Comment 10 Marek Olšák 2014-12-04 14:01:56 UTC
(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.
Comment 11 Henri Verbeet 2014-12-04 14:13:31 UTC
(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?
Comment 12 Clément Guérin 2014-12-29 20:49:24 UTC
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"
Comment 13 Michel Dänzer 2015-01-06 08:30:44 UTC
(In reply to Clément Guérin from comment #12)
> Low lighting glitch is still here. "can be seen in the Realistic Rendering
> demo or the Shooter Game demo with the Sanctuary map"

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.
Comment 14 Clément Guérin 2015-01-07 01:10:41 UTC
(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.
Comment 15 Daniel Scharrer 2015-01-15 15:19:45 UTC
FWIW, Shooter Game, Realistic Rendering Demo and Light Room Interior Day Demo all look fine to me now with a Radeon HD 7950 and recent Mesa and LLVM snapshots.
Comment 16 Marek Olšák 2015-01-16 14:01:13 UTC
(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.


bug/show.html.tmpl processed on Feb 21, 2017 at 19:04:58.
(provided by the Example extension).