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.
Created attachment 105764 [details] Motion blur glitch in Shooter Game
Created attachment 105765 [details] Black pixel glitch in Stylized demo
Created attachment 105766 [details] Black pixel glitch in Mobile Game demo
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
Can confirm, same thing on Cape Verde (7770) with 3.16.1 and latest mesa on Ubuntu 14.10.
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.
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
(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.
(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?
(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.
(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?
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"
(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.
(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.
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.
(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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.