Bug 90513

In the trace in the OP, as an example of an "offending call":
on frame 1950, on call #2160519 the ground gets painted red.

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.

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.

(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[1], 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[2] 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.

[1] While the game was still in closed beta
[2] Not sure if a change to the game, to Mesa or both. As far as I can recall, probably both.

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 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.

(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

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.

yeah I can confirm this.

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.

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.

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.

The shadow/brightness flicker should be helped by

https://cgit.freedesktop.org/mesa/mesa/commit/?id=154c0a42a23187c61ea0a1307198fae667398eba

Moving on to the red/green flickering...

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

And here are the diffs. src = gk208, ref = gt215.

https://people.freedesktop.org/~imirkin/traces/talos-diffs.tar

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.

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?

-- 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.