|Summary:||Render error in Wasteland 2|
|Component:||Drivers/DRI/i965||Assignee:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|Status:||RESOLVED MOVED||QA Contact:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|i915 platform:||i915 features:|
black rectagle around bodies on the ground.
apitrace replay log
Description dvlohp 2016-08-22 20:02:43 UTC
Created attachment 125959 [details] black rectagle around bodies on the ground. Wasteland 2 show rendering errors where there are black rectangles visible around objects on the ground and also (partially) hiding the objects. I attached a screen shot showing what I mean. I'm running linux kernel 4.7.2 on an i5-6500 processor. I tried a quite recent mesa version from git ( 18. Aug 2016, at commit d61d25951887a08fd6ea2a9d0db82d52813ce532), but I also saw the problem with older mesa versions. There's nothing suspicious in dmesg, on the console or in my Xorg log. Please tell me if there's more info I can/should provide.
Comment 1 Ilia Mirkin 2016-08-22 20:58:54 UTC
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
Comment 2 Tapani Pälli 2016-08-23 05:58:56 UTC
just to rule out bug with possible workaround, please try also running with following environment variable: UNITY_DISABLE_GRAPHICS_DRIVER_WORKAROUNDS=yes
Comment 3 Tapani Pälli 2016-08-23 11:41:22 UTC
Also one question, is this the 'directors cut' or regular/original version? (so that testing happens with same one)
Comment 4 dvlohp 2016-08-23 21:05:29 UTC
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.
Comment 5 Tapani Pälli 2016-08-26 05:13:22 UTC
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.
Comment 6 Tapani Pälli 2016-08-26 05:33:39 UTC
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
Comment 7 Tapani Pälli 2016-08-26 05:34:09 UTC
Created attachment 126044 [details] apitrace replay log
Comment 8 Tapani Pälli 2016-08-26 09:04:23 UTC
(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) ) ) )) )
Comment 9 Kenneth Graunke 2016-08-26 09:35:24 UTC
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".
Comment 10 dvlohp 2016-08-27 12:21:53 UTC
"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.
Comment 11 Tapani Pälli 2016-08-29 07:54:14 UTC
(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 :/)
Comment 12 dvlohp 2016-08-29 22:18:19 UTC
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?
Comment 13 Tapani Pälli 2016-08-30 05:57:42 UTC
(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.
Comment 14 dvlohp 2016-08-30 16:00:33 UTC
(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.
Comment 15 dvlohp 2016-08-30 16:23:43 UTC
I uploaded the trace (.xz-compressed) to google drive. https://drive.google.com/file/d/0B95lzHm7TExiTnV5bTlyUzZCX2c/view
Comment 16 dvlohp 2016-09-14 20:55:12 UTC
Just updated mesa to recent git (commit bff90aedf1d06c7e746b2d56319b19a624594feb), and the error is still there.
Comment 17 Matt Turner 2017-03-23 18:49:49 UTC
I can reproduce on SKL, and Ilia reports that he can also reproduce on llvmpipe.
Comment 18 Jakub Szuppe 2017-04-10 12:16:44 UTC
We are working on this issue at StreamComputing. The issue still occurs on Skylake and on Ivybridge (using the recent Mesa version from git).
Comment 19 Jakub Szuppe 2017-06-08 09:37:36 UTC
Created attachment 131795 [details] [review] normalize_patch
Comment 20 Jakub Szuppe 2017-06-08 09:40:08 UTC
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/
Comment 21 GitLab Migration User 2019-09-25 18:57:51 UTC
-- 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.