Bug 96565

Summary: Clive Barker's Jericho displays strange,vivid colors when motion blur enabled
Product: Mesa Reporter: Béla Gyebrószki <gyebro69>
Component: Drivers/DRI/nouveauAssignee: Nouveau Project <nouveau>
Status: RESOLVED FIXED QA Contact: Nouveau Project <nouveau>
Severity: normal    
Priority: medium CC: gyebro69, imirkin
Version: 11.2Keywords: bisected, regression
Hardware: Other   
OS: All   
i915 platform: i915 features:
Attachments: screenshot
failing tgsi shader

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

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):

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

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:

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.