An apitrace (https://github.com/apitrace/apitrace) demonstrating the issue would likely help debugging. I assume this is with steam, so you probably want to have a look at https://github.com/apitrace/apitrace/wiki/Steam

just to rule out bug with possible workaround, please try also running with following environment variable:

UNITY_DISABLE_GRAPHICS_DRIVER_WORKAROUNDS=yes

Also one question, is this the 'directors cut' or regular/original version? (so that testing happens with same one)

It's the directors cur version of the game, via Steam.
Just gave it a quick try, using UNITY_DISABLE_GRAPHICS_DRIVER_WORKAROUNDS=yes doesn't help.

I haven't had the time to create an apitrace yet, will try to do this tomorrow.

I've reproduced this, some creatures (at least Megamaggot) seem to leave a 'trail of black' when moving, trail has some 'noise' in it just like the rectangles in the screenshot. Playing around with options (such as AA or shadows and overall quality) did not change this, this is happening even with lowest possible settings.

I've created apitrace but it is *huge*, will try to trim it smaller.

I noticed when playing back trace that there's *lots* of warnings like this:

4524: message: major shader compiler issue 114: 0:14(18): warning: `tmpvar_1' used uninitialized
681109: message: major shader compiler issue 149: 0:93(18): warning: `tmpvar_2' used uninitialized
687330: message: major shader compiler issue 269: 0:113(35): warning: `tmpvar_5' used uninitialized
687531: message: major shader compiler issue 279: 0:95(34): warning: `tmpvar_3' used uninitialized

then also spotted one weird one:
4787: message: api performance issue 132: Recompiling fragment shader for program -1

Created attachment 126044 [details]
apitrace replay log

(In reply to Tapani Pälli from comment #6)
> I noticed when playing back trace that there's *lots* of warnings like this:
> 
> 4524: message: major shader compiler issue 114: 0:14(18): warning:
> `tmpvar_1' used uninitialized
> 681109: message: major shader compiler issue 149: 0:93(18): warning:
> `tmpvar_2' used uninitialized
> 687330: message: major shader compiler issue 269: 0:113(35): warning:
> `tmpvar_5' used uninitialized
> 687531: message: major shader compiler issue 279: 0:95(34): warning:
> `tmpvar_3' used uninitialized

These seem like bogus warnings though, such warning gets printed for example for this shader:

( function main
  (signature void
    (parameters
    )
    (
      (declare () vec2 tmpvar_1)
      (assign  (xyzw) (var_ref gl_Position)  (expression vec4 * (var_ref gl_ModelViewProjectionMatrix) (var_ref gl_Vertex) ) ) 
    ))

)

The uninitialized variable warning does have false positives.  If you want to zero initialize unusued variables and see if that helps, you can run with "glsl_zero_init=true".

"glsl_zero_init=true" doesn't help.

I finally got around creating a apitrace. However, it's 1.5G (720M compressed) in size. Should I really attach it as is or is there any way to preprocess it into something smaller?

Most of the replay just is the loading screen/menu, only the last few seconds contain the scene with the black rectangles.

Btw.: I also noticed the strange artefacts left by the megamaggots.

(In reply to dvlohp from comment #10)
> "glsl_zero_init=true" doesn't help.
> 
> I finally got around creating a apitrace. However, it's 1.5G (720M
> compressed) in size. Should I really attach it as is or is there any way to
> preprocess it into something smaller?

you could try trimming feature which works like this:

apitrace trim --frames=2180-2366 WL2.trace

(for me resulting trace did not work though :/)

Stripping doesn't work for me either.

Unfortunately, I can't upload the full trace, as no attachments >73MB are allowed.

Even the stripped version would be too big...

Is there anything else I could do?

(In reply to dvlohp from comment #10)
> "glsl_zero_init=true" doesn't help.
> 

Rendering errors with megamaggots disappear for me when using "glsl_zero_init=true" and playing back the trace I have.

(In reply to Tapani Pälli from comment #13)
> (In reply to dvlohp from comment #10)
> > "glsl_zero_init=true" doesn't help.
> > 
> 
> Rendering errors with megamaggots disappear for me when using
> "glsl_zero_init=true" and playing back the trace I have.

Then it's definitely a different error. I just tried again playing back my trace with glsl_zero_init=true, but no luck. Also, as far as I remember, the maggot tails are really full of static, while the black rectangles I get are just black.

I uploaded the trace (.xz-compressed) to google drive.

https://drive.google.com/file/d/0B95lzHm7TExiTnV5bTlyUzZCX2c/view

Just updated mesa to recent git (commit bff90aedf1d06c7e746b2d56319b19a624594feb), and the error is still there.

I can reproduce on SKL, and Ilia reports that he can also reproduce on llvmpipe.

We are working on this issue at StreamComputing. The issue still occurs on Skylake and on Ivybridge (using the recent Mesa version from git).

Created attachment 131795 [details] [review]
normalize_patch

There are black rectangles instead of blood splashes. They are rendered in call 1570549, for example:
https://drive.google.com/open?id=0B1fY17pW39ZebG9Dd05QNnFMM0E

Fragments' color values are NaNs. The fragment shader (1337, call 1080782) receives NaN values for two inputs: xlv_TEXCOORD2 and xlv_TEXCOORD2_1.

The vertex shader  (1336, call 1080779) produces these values by calling normalize on TANGENT attribute.

TANGENT is mapped to 1 generic vertex attribute. There is 1570545 @1 glDisableVertexAttribArrayARB(index = 1) before 1570549 @1 glDrawElements. I.e. the attribute uses the current value, but this value is never set directly (using glVertexAttrib4f, for example), so its value is (0, 0, 0, 1) according to the OpenGL specification.

[!] normalize(x) is not defined for zero vectors. The spec only says that it
"returns a vector in the same direction as x but with a length of 1."

Any behavior is correct:

* Mesa (not only i965) returns NaNs
* NVIDIA proprietary driver returns NaNs
* AMD proprietary driver returns zeros

Why it works on NVIDIA: although normalize returns NaNs for zero vectors, for some reason GL_CURRENT_VERTEX_ATTRIB is (1, 0, 0, 1), this behavior violates the specification: https://drive.google.com/open?id=0B1fY17pW39ZeMFhrWEM4Q2lCUkU

Why it works on AMD:  normalize returns zeros for zero vectors, so other values are not "damaged". Catalyst uses v_mul_legacy here which treats NaNs as zeros (Mesa uses v_mul).

Here is a workaround that makes Mesa return zeros for zeros vectors (as AMD on Catalyst does):
https://bugs.freedesktop.org/attachment.cgi?id=131795

How the screen looks like with this workaround:
https://drive.google.com/open?id=0B1fY17pW39ZeTlAyam0wVzhzclk

This workaround also fixes megamaggots' trails.

Anyway, in our opinion the bug is in the game engine, not in Mesa. glVertexAttrib4(1, ...) should be added after glDisableVertexAttribArray(1) to set correct values for TANGENT attribute. That's a coincidence that it works well on proprietary NVIDIA (because of its weird behavior) and AMD (because of its normalize implementation).

Kind regards,
Stream HPC Team
https://streamhpc.com/

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1535.