|Summary:||Odd gray and red flicker in The Talos Principle on GK104|
|Product:||Mesa||Reporter:||Gediminas Jakutis <gediminas>|
|Component:||Drivers/DRI/nouveau||Assignee:||Nouveau Project <nouveau>|
|Status:||RESOLVED MOVED||QA Contact:||Nouveau Project <nouveau>|
|i915 platform:||i915 features:|
|Attachments:||list of draws with bad results|
Description Gediminas Jakutis 2015-05-18 22:43:35 UTC
When running The Talos Principle on my GK104 under Nouveau, I get two kinds of odd flickering: · some parts of some objects flicker between being bright and less bright · some objects flicker between being "normal" and full-red Although, the "red" flicker does not appear if the game's graphics settings are set to "minimum" – only the bright / less bright flicker happens. It looks fine on proprietary drivers, which probably rules out hardware defects. It also looks fine on an Intel GPU under Mesa. I recorded a short video in case anyone agrees that one look is better than a thousand words and wants to see it in action. I recorded an apitrace of it. On nouveau this replays the same way it looks "live". On proprietary drivers it replays "correctly" – the flicker is nonexistent. I did not manage to do the reverse – sadly, an apitrace recorded on proprietary drivers fail to replay at all regardless of what driver is used.  http://store.steampowered.com/app/257510/ [a free demo version which can be used to reproduce is also available]  https://seriouss.am/video/talos-redflicker.mp4 length: 20 seconds; filesize: 24.6 MiB  https://seriouss.am/talos-nouveau-2015-05-11T1231.trace.xz filesize: 361.9 MiB
Comment 1 Gediminas Jakutis 2015-05-19 01:45:58 UTC
In the trace in the OP, as an example of an "offending call": on frame 1950, on call #2160519 the ground gets painted red.
Comment 2 Ilia Mirkin 2015-05-19 23:32:30 UTC
Confirmed that I get redness coming in on that draw on my GK208, whereas it's fine on i965. There are a few awkward things, but nothing completely ridiculous: 1. 4096x4096 srgb dxt1/5 textures, specifically GL_TEXTURE4, GL_TEXTURE6. 2. Multiple vertex elements are mapped to the same position in the same buffer (3, 4, and 5). Curiously, no shaders appear to be bound, which is very odd. I'm guessing that's some sort of qapitrace fail. Very weird.
Comment 3 Karol Herbst 2015-07-08 12:05:58 UTC
does enabling "No Dynamic Lightning" helps with the issue even on very high gpu settings Like Ultra? Its a customize options for the gpu speed.
Comment 4 Gediminas Jakutis 2015-07-08 18:40:50 UTC
(In reply to Karol Herbst from comment #3) > does enabling "No Dynamic Lightning" helps with the issue even on very high > gpu settings Like Ultra? Its a customize options for the gpu speed. Oh my, yes it does. I suppose that means the dynamic lighting is responsible for it. Hmmm... previously, dynamic lighting used to crash the game at certain locations, but would not create any visual problems. This particular flickering started appearing after some change that made the game to NOT crash anymore. I'm going to ping the game's developers and ask them to look into this particular report. Maybe by knowing their engine's internals, they can toss some [valuable] insight.  While the game was still in closed beta  Not sure if a change to the game, to Mesa or both. As far as I can recall, probably both.
Comment 5 Ilia Mirkin 2015-07-08 18:50:46 UTC
I've made no progress on this bug BTW; perhaps an avenue would be to generate a super-low-resolution trace (i.e. minimum supported by the game... 320x200 or 640x480 or something) so that it plays back faster, and with the minimum number of "features" enabled to make the problem happen. Basically right now every run through glretrace is a minute or longer, which is too painful to analyze the draws. And I think I gave up waiting for llvmpipe.
Comment 6 Gediminas Jakutis 2015-07-08 20:24:49 UTC
(In reply to Ilia Mirkin from comment #5) > I've made no progress on this bug BTW; perhaps an avenue would be to > generate a super-low-resolution trace (i.e. minimum supported by the game... > 320x200 or 640x480 or something) so that it plays back faster, and with the > minimum number of "features" enabled to make the problem happen. I'll get on it right now.
Comment 7 Karol Herbst 2015-07-09 18:34:41 UTC
(In reply to Ilia Mirkin from comment #5) > I've made no progress on this bug BTW; perhaps an avenue would be to > generate a super-low-resolution trace (i.e. minimum supported by the game... > 320x200 or 640x480 or something) so that it plays back faster, and with the > minimum number of "features" enabled to make the problem happen. > > Basically right now every run through glretrace is a minute or longer, which > is too painful to analyze the draws. And I think I gave up waiting for > llvmpipe. in the trace I gave you (https://www.dropbox.com/s/hiwgrf4i6kw5aue/talos.trace.xz?dl=0) frame 1166 call 1710787 draws the faulty wall into the buffer
Comment 8 Ilia Mirkin 2015-07-12 21:46:25 UTC
I got the demo, and even with GPU set to the "lowest" level, I see lighting/texture mapping/_something_ errors. At the very first level in the demo, if you walk towards the castle, and stand relatively close to it (but not _too_ close), you can see the moss go from being applied to not applied to the wall/stones, along with other lighting changes by just standing still and turning. This was with a GF108. I suspect that everything is a fallout from whatever issue is causing that.
Comment 9 Karol Herbst 2015-07-13 20:27:36 UTC
yeah I can confirm this.
Comment 10 Ilia Mirkin 2015-07-16 00:43:48 UTC
OK, so... it looks like nouveau just fails at rendering this game entirely. The flickering is like the *least* of our problems. Although one of the more annoying. I just ran Karol's trace through apitrace dump-images on i965 and a gk208, and beyond the semi-expected small differences all over, things seem to go extremely wrong in a few distinct places: Draw call at 383068. Nouveau just fails to draw the "top" part of the image. There is supposed to be a "circle" of specs, and nouveau just has a semi-circle. Subsequent draws add more specs and they all appear to be missing on nouveau. This is a mask of some sort, but I can't imagine that it translates into anything good down the line. Then the next big difference comes in at draw 395973. Now, I'm willing to entertain the notion that it's actually fine for that difference to exist due to silly GPU differences. However the next draw after that -- 396054 -- the footpath is supposed to have some texture mapped on top of it, and it's just not there on the gk208 -- the footpath is there, but the dark pattern that's supposed to go over it isn't.
Comment 11 Ilia Mirkin 2016-01-06 19:09:11 UTC
Interesting... same issues don't occur on nv50 (GT215). Need to try to disable features one-by-one until we find which ext is causing some difference to be happening.
Comment 12 Ilia Mirkin 2016-01-06 19:58:18 UTC
Actually talos doesn't use any "new" features. So it must be something that's just plain broken on nvc0... The trace replays fine on nv50.
Comment 13 Ilia Mirkin 2016-06-19 14:19:57 UTC
The shadow/brightness flicker should be helped by https://cgit.freedesktop.org/mesa/mesa/commit/?id=154c0a42a23187c61ea0a1307198fae667398eba Moving on to the red/green flickering...
Comment 14 Ilia Mirkin 2016-06-20 01:10:52 UTC
Created attachment 124613 [details] list of draws with bad results I ran a diff (with retracediff.py) against nv50 (after fixing alpha test on nv50, otherwise it had too many differences). The attached list of draws has diffs when running GK208 vs GT215, most (all?) randomly-green-stuff related. [GT215 renders everything fine.] The trace in question is https://people.freedesktop.org/~imirkin/traces/talos-karolherbst.trace.xz
Comment 15 Ilia Mirkin 2016-06-20 03:03:26 UTC
And here are the diffs. src = gk208, ref = gt215. https://people.freedesktop.org/~imirkin/traces/talos-diffs.tar
Comment 16 Ilia Mirkin 2016-06-20 03:18:15 UTC
Trying to replay this, I see the green splotches in other frames, while the ones that were bad during my retracediff work out just fine. That will make the remaining misrenders much trickier to track down.
Comment 17 Gediminas Jakutis 2016-11-30 17:55:33 UTC
I just ran it on [current HEAD at the time of writing] and I do not notice any of the problems anymore. Was it "accidentally" fixed? Can someone else test, too, and see if it's really fine && can be closed?
Comment 18 GitLab Migration User 2019-09-18 20:40:06 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/1073.