Bug 98761

Created attachment 128045 [details]
ground looks good

The patch at https://patchwork.freedesktop.org/patch/122101/ fixes a known regression from that commit -- does it help here?

Created attachment 128053 [details]
problem in motion

unfortunately, doesn't help here. (mesa git-da2a511 + your patch/llvm 287325)
this is how looks like in game before and after.

I can reproduce it, but I don't yet know how to find the bad shader.

apitrace doesn't work with this game and shaders aren't always loaded in the same order.

This is only reproducible on LLVM 4.0 trunk.

LLVM 3.9 renders doesn't have this issue.

If Witcher 2 has scalar spills, I'd suggest trying LLVM trunk from before r286766 (or perhaps with that commit reverted), as there's another known bug: SGPR spills conflict with fragment shader input interpolation (because both use M0), and it's possible that the Mesa commit simply exposed the issue.

Found the bad shader.

The good one has before v_interp:
s_mov_b32 m0, s11

The bad one has before v_interp:
s_mov_b32 m0, s19

I don't see any store instructions though.

Scratch that. The bad one has this:

s_mov_b32 s19, s11
s_mov_b32 m0, s19

It looks like it's not an m0 issue.

Found a possibly related bug in another game: #98776.

Nicolai, I don't want to bisect llvm I really hate it but i've tried r286757 & r286827 and problem is somewhere between. So you have right i believe. 

And still can't reproduce this on hd7770 (verde).

First bad commit:

commit 4404d0d6e354e80dd7f8f0a0e12d8ad809cf007e
Author: Matt Arsenault <Matthew.Arsenault@amd.com>
Date:   Sun Nov 13 18:20:54 2016 +0000

    AMDGPU: Implement SGPR spilling with scalar stores
    
    nThis avoids the nasty problems caused by using
    memory instructions that read the exec mask while
    spilling / restoring registers used for control flow
    masking, but only for VI when these were added.
    
    This always uses the scalar stores when enabled currently,
    but it may be better to still try to spill to a VGPR
    and use this on the fallback memory path.
    
    The cache also needs to be flushed before wave termination
    if a scalar store is used.
    
    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286766 91177308-0d34-0410-b5e6-96231b3b80d8

Created attachment 128128 [details]
affected shader (good asm)

Created attachment 128129 [details]
affected shader (good->bad diff)

Created attachment 128130 [details]
affected shader (bad asm)

It looks like m0 isn't restored for v_interp instructions.

Possible duplicates: bug 98776 bug 98783 bug 98785
llvm bug: https://llvm.org/bugs/show_bug.cgi?id=31019

Marek, thanks for help with llvm. 
Grazvydas, with Talos I agree, even opengl is garbage now. Unigine-heaven has similar problem since r286766 
Probably guilty is "AMDGPU: Implement SGPR spilling with scalar stores" for all scenario but i never ever had any problem with Life is Strange (I've just finished E01)

Try after llvm r287844

Created attachment 128178 [details]
still bad

(In reply to Matt Arsenault from comment #18)
> Try after llvm r287844

It's still pretty broken. See the attached asm. "s_mov vcc_hi, m0" looks suspicious.

(In reply to Marek Olšák from comment #19)
> Created attachment 128178 [details]
> still bad
> 
> (In reply to Matt Arsenault from comment #18)
> > Try after llvm r287844
> 
> It's still pretty broken. See the attached asm. "s_mov vcc_hi, m0" looks
> suspicious.

s_mov vcc_hi, m0 is fine and expected. TableGen happens to sort VCC to the beginning of the SReg_64 register class list, so the scavenger tends to find VCC first if its available

This is more concerning: s_buffer_store_dword exec_lo, s[84:87], m0

exec should never be spilled

Created attachment 128180 [details]
witcher2_r287854

so, it's resolved ground's problem for me, the movie is not looking perfect but this is not problem of this bug report i think. 

Marek, Matt I don't know what do you talking about but maybe you are looking for:
https://bugs.freedesktop.org/show_bug.cgi?id=98238 
there is big visual differences between mesa 12.0.4 vs 13.0 ...work in progress:)

Oops.. when Marek reverted "SGPR spilling..."-stuff, this one should be closed aswell.