Bug 93566 - Shadow of Mordor is fading to white with Intel Mesa driver
Summary: Shadow of Mordor is fading to white with Intel Mesa driver
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Kenneth Graunke
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-03 13:51 UTC by Darius Spitznagel
Modified: 2016-06-17 21:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Darius Spitznagel 2016-01-03 13:51:46 UTC
Hello devs,

today I was testing Shadow of Mordor on my Intel Iris pro since tessellation landed for gen7+ some days ago in master git.

Mesa:
glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Desktop 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.0-devel (git-28dea26)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.2.0-devel (git-28dea26)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.2.0-devel (git-28dea26)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Steam start options:
MESA_GL_VERSION_OVERRIDE=4.3 MESA_GLSL_VERSION_OVERRIDE=430 %command%

When the main menu comes up, the complete rendered background (not menu dialogs) is fading slowly to white (also ingame and benchmark).

If i append MESA_EXTENSION_OVERRIDE=-GL_ARB_compute_shader to my steam start option, there is no fading > the menu is rendered as expected.

I have made an apitrace and replayed it...
Without GL_ARB_compute_shader there are errors, because Shadow of Mordor wants to use it, but rendering LOOKS ok.
With GL_ARB_compute_shader the errors are gone, but there is this white fading.

So I guess there is something wrong with GL_ARB_compute_shader!
Could someone look into this?

You can download my apitrace here...
http://www.goodbytez.de/mesa/ShadowOfMordor.trace.tar.bz2

Kind regards
Darius
Comment 1 Darius Spitznagel 2016-01-03 22:25:12 UTC
Uhh, I have to correct myself...

My apitrace doesn't show the white fading!
The white fading is ONLY VISIBLE when I start the game (through steam client)!

This is really strange:(
Comment 2 Darius Spitznagel 2016-01-03 23:25:53 UTC
I made some more investigation...

The problem seems to be partly kernel related (I have 2 kernels installed)!!!

When I replay my apitrace with kernel 4.1.15 i can see the white fading.
When I replay my apitrace with kernel 4.3.3 the white fading isn't there.

But...
playing the game with both kernels shows the white fading.

What the hell is going on?
Is apitrace 7.1 broken or is there a problem with intel drm?

I'm out of clue right now, please help.

My System is Debian 8.2 x64
libdrm 2.4.66 from git master
xserver-xorg-video-intel 2.99.917+git20151217
xserver-xorg-core 1.16.4
Comment 3 Kenneth Graunke 2016-01-05 10:48:59 UTC
It looks like there are a number of bugs being provoked by SoM on Gen7/7.5.

Compute shaders require a functional kernel command validator to work.  IIRC, that was introduced in Kernel 4.2.  Mesa is wrongly enabling the feature without checking the kernel dependency.  I'll follow up on this.

Secondly, there's the shaders failing to compile due to int/uint conversions in bitwise operators.  You need "glsl: Allow implicit int -> uint conversions for bitwise operators (&, ^, |)." from http://cgit.freedesktop.org/~kwg/mesa/log/?h=mordor    (I've been trying to follow up with Khronos about this, but haven't gotten anywhere.  I should prod them again, and perhaps just send the patch regardless...)

Third, it looks like bitfield insert/extract lowering is botching int/uint stuff, too, and making the IR validator trip asserts.  I'm not sure what would happen in release mode.  I'll try and follow up on this too.
Comment 4 Kenneth Graunke 2016-01-05 11:05:44 UTC
I just sent a patch to disable ARB_compute_shader on Kernel < 4.2:
http://lists.freedesktop.org/archives/mesa-dev/2016-January/104221.html
Comment 5 Kenneth Graunke 2016-01-05 12:31:53 UTC
I fixed the third problem - opt_vectorize() is trying to combine multiple scalar bitfieldInsert operations, but our validator wasn't allowing that.  I've written patches to relax that restriction, as it ought to work fine.

Now there's a fourth problem: for some bizarre reason, I'm getting nir_op_fdiv in a compute shader.  We don't actually implement fdiv, as it's supposed to get turned into fmul/frcp...
Comment 6 Kenneth Graunke 2016-01-05 13:21:01 UTC
nir_opt_algebraic was converting log2(a) - log2(b) into log2(a/b).  We were still relying on GLSL IR for fdiv lowering, which happens before NIR, so this fdiv actually made it to the backend.  I've written a patch to do fdiv lowering in NIR.

With all of those fixes, it seems to be running with no fade-to-white.  Feel free to give my 'mordor' branch a try:

http://cgit.freedesktop.org/~kwg/mesa/log/?h=mordor
Comment 7 Darius Spitznagel 2016-01-05 14:16:40 UTC
Impressive Kenneth.
You fixed the problem in less than 3 hours!

As you might know there are some more glitches like missing rain etc., but this is not part of this bug report.

Thank you very much. You made my day.
With your patches landing in master this ticket/report can be closed.

Kind regards
Darius
Comment 8 Kenneth Graunke 2016-01-06 00:04:49 UTC
Great!  Thanks for testing :)

I wasn't aware of missing rain.  I'll have to look into that...
Comment 9 Darius Spitznagel 2016-01-06 01:05:22 UTC
Hello Kenneth,

I have opened a new bugreport for the missing rain, etc.
https://bugs.freedesktop.org/show_bug.cgi?id=93601

Many thanks
Darius


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.