Nouveau - May 2015 - [Bug 90513] New: Odd gray and red flicker in The Talos Principle on GK104

https://bugs.freedesktop.org/show_bug.cgi?id=90513

            Bug ID: 90513
           Summary: Odd gray and red flicker in The Talos Principle on
                    GK104
           Product: Mesa
           Version: git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: gediminas at varciai.lt
        QA Contact: nouveau at lists.freedesktop.org

When running The Talos Principle[1] 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[2] in case anyone agrees that one look is better than
a thousand words and wants to see it in action.


I recorded an apitrace[3] 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.

[1] http://store.steampowered.com/app/257510/ [a free demo version which can be
used to reproduce is also available]
[2] https://seriouss.am/video/talos-redflicker.mp4 length: 20 seconds;
filesize: 24.6 MiB
[3] https://seriouss.am/talos-nouveau-2015-05-11T1231.trace.xz filesize: 361.9
MiB

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150518/29139360/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #1 from Gediminas Jakutis <gediminas at varciai.lt> ---
In the trace in the OP, as an example of an "offending call":
on frame 1950, on call #2160519 the ground gets painted red.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150519/c0afcec0/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #2 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150519/04a9b4a8/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #3 from Karol Herbst <freedesktop at karolherbst.de> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150708/fe28ed84/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #4 from Gediminas Jakutis <gediminas at varciai.lt> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150708/2867eb83/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #5 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150708/c7322baa/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #6 from Gediminas Jakutis <gediminas at varciai.lt> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150708/96d7bccd/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #7 from Karol Herbst <freedesktop at karolherbst.de> ---
(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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150709/0b606fe8/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #8 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150712/8b0c2dc3/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #9 from Karol Herbst <freedesktop at karolherbst.de> ---
yeah I can confirm this.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150713/23c19ee4/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #10 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150716/60abb318/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #11 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20160106/6888c98f/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #12 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20160106/fd218225/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #13 from Ilia Mirkin <imirkin at alum.mit.edu> ---
The shadow/brightness flicker should be helped by

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

Moving on to the red/green flickering...

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20160619/1ea3a8e3/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #14 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Created attachment 124613
  --> https://bugs.freedesktop.org/attachment.cgi?id=124613&action=edit
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20160620/0e86f187/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #15 from Ilia Mirkin <imirkin at alum.mit.edu> ---
And here are the diffs. src = gk208, ref = gt215.

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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20160620/7b2caae8/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #16 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20160620/fc4f71ef/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

--- Comment #17 from Gediminas Jakutis <gediminas at varciai.lt> ---
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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20161130/6d2ca9a7/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=90513

GitLab Migration User <gitlab-migration at fdo.invalid> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|NEW                         |RESOLVED

--- Comment #18 from GitLab Migration User <gitlab-migration at
fdo.invalid> ---
-- 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20190918/b5502bde/attachment.html>