Bug 96565 - Clive Barker's Jericho displays strange,vivid colors when motion blur enabled
Summary: Clive Barker's Jericho displays strange,vivid colors when motion blur enabled
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/nouveau (show other bugs)
Version: 11.2
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Nouveau Project
URL:
Whiteboard:
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2016-06-17 17:53 UTC by Béla Gyebrószki
Modified: 2016-06-19 14:18 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
screenshot (740.60 KB, image/png)
2016-06-17 17:53 UTC, Béla Gyebrószki
Details
failing tgsi shader (4.12 KB, text/plain)
2016-06-18 18:35 UTC, Ilia Mirkin
Details

Description Béla Gyebrószki 2016-06-17 17:53:45 UTC
Created attachment 124580 [details]
screenshot

When motion blur effect is enabled in the game, the screen is filled with red, yellow and green colors (both the menus and midgame).
The problem doesn't exist with the software renderer.

Bisecting revealed that the problem is present since

commit 7752bbc44e78e982de3cd4c34862adc38a338234
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Thu Dec 10 18:19:44 2015 -0500

    gk104/ir: simplify and fool-proof texbar algorithm
    
    With the current algorithm, we only look at tex uses. However there's a
    write-after-write hazard where we might decide to, on some path, not use
    a texture's output at all, but instead to write a different value to
    that register. However without the barrier, the texture might complete
    later and overwrite that value.
    
    This fixes Unreal Elemental demo on GK110/GK208, flightgear on GK10x,
    and likely other random-looking failures.

The game renders properly with the previous commit.

Trace (uncompressed 138M):
https://drive.google.com/open?id=0B-tTbLKBl-tOaVRvNmMwQW8zYlk

OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV106
OpenGL core profile version string: 4.3 (Core Profile) Mesa 12.1.0-devel (git-5a64549)
OpenGL core profile shading language version string: 4.30

Fedora 23
Libdrm 2.4.68+git
Linux kernel 4.7.0-rc3
Comment 1 Samuel Pitoiset 2016-06-18 16:31:16 UTC
The trace replays fine on my GF119. I guess it's a Kepler issue.
Comment 2 Ilia Mirkin 2016-06-18 18:35:05 UTC
Created attachment 124590 [details]
failing tgsi shader

Somehow the attached shader manages to generate

BB:11 (4 instructions) - idom = BB:8, df = { BB:5 }
 -> BB:26 (tree)
 -> BB:12 (tree)
 45: mov u32 $r4 $r14 (8)
 46: mov u32 $r5 $r15 (8)
 47: tex 2D $r1 $s0 f32 $r4t $r4d (8)
 48: set ftz u8 $p0 neu f32 $r7 neg $r7 (8)
BB:12 (4 instructions) - idom = BB:11, df = { BB:13 }
 -> BB:13 (forward)
 49: $p0 add ftz f32 $r17 $r17 $r4 (8)
 50: $p0 add ftz f32 $r18 $r18 $r5 (8)
 51: $p0 add ftz f32 $r19 $r19 $r6 (8)
 52: $p0 add ftz f32 $r16 $r16 1.000000 (8)

Which is obviously missing a texbar. Investigating.
Comment 3 Ilia Mirkin 2016-06-18 19:27:53 UTC
https://patchwork.freedesktop.org/patch/94103/

That fixes the trace for me. Technically the issue wasn't *caused* by that commit... the bad logic existed already. But the old logic didn't pick up the "uses" at the top of the loop, which in turn meant that it kept the uses after the tex. Oh well.
Comment 4 Ilia Mirkin 2016-06-18 20:18:15 UTC
v2 here:

https://patchwork.freedesktop.org/patch/94106/
Comment 5 Béla Gyebrószki 2016-06-18 20:52:18 UTC
(In reply to Ilia Mirkin from comment #4)
> v2 here:
> 
> https://patchwork.freedesktop.org/patch/94106/

The patch fixes the problem in the game, thank you.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.