Nouveau - Jan 2017 - [Bug 99532] New: Compute shader doesn't give right result under some circumstances

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

            Bug ID: 99532
           Summary: Compute shader doesn't give right result under some
                    circumstances
           Product: Mesa
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: stu_dby at 126.com
        QA Contact: nouveau at lists.freedesktop.org

Created attachment 129135
  --> https://bugs.freedesktop.org/attachment.cgi?id=129135&action=edit
apitrace of my program

When I'm doing a course project in my compute graphics class, I found my
program didn't fully work on nouveau while it was working fine on intel and
nvidia proprietary drivers. It is a program using deferred shading with some
shadow map techniques, and it has an option to draw a "histogram" of
depth
distribution sampled by a compute shader. I found histogram was showing wrong
results (totally blank) on nouveau.

After looking into the problem for a while, I happened to find that if I
didn't
render the histogram (i.e. didn't use compute shader to sample) on the first
frame, the histogram would go wrong, otherwise, it would be okay.

This problem can be reproduced with the attached apitrace file, recorded with
simplified program and trimmed to contain only 4 frames. The first 2 frames are
mainly initialization and the third frame renders the scene from one angle
without generating histogram. The last frame renders the scene from another
angle and generates a histogram at bottom-right edge, which is completely blank
on nouveau. However, if the trace is further trimmed to contain frame 0,1,3,
the histogram will render correctly. (Results of the two will be attached
below)

I'm willing provide assistance if needed.

-- 
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/20170125/5aa824b8/attachment.html>

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

--- Comment #1 from Boyan Ding <stu_dby at 126.com> ---
Created attachment 129136
  --> https://bugs.freedesktop.org/attachment.cgi?id=129136&action=edit
Wrong rendering (histogram blank)

-- 
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/20170125/adc417c0/attachment.html>

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

--- Comment #2 from Boyan Ding <stu_dby at 126.com> ---
Created attachment 129137
  --> https://bugs.freedesktop.org/attachment.cgi?id=129137&action=edit
Correct rendering of the last frame

-- 
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/20170125/509606b8/attachment.html>

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

--- Comment #3 from Ilia Mirkin <imirkin at alum.mit.edu> ---
On GM107 it actually appears to work correctly. However on GK208 I got a blank
histogram on the first run, and then a semi-random one on subsequent runs. (And
now it's blank again.)

What GPU are you using?

-- 
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/20170125/f742bf68/attachment.html>

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

--- Comment #4 from Boyan Ding <stu_dby at 126.com> ---
(In reply to Ilia Mirkin from comment #3)
> On GM107 it actually appears to work correctly. However on GK208 I got a
> blank histogram on the first run, and then a semi-random one on subsequent
> runs. (And now it's blank again.)
> 
> What GPU are you using?
Mine is a GT740M (GK208).

-- 
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/20170125/bda0e0af/attachment.html>

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

--- Comment #5 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Can you figure out which compute invocation messes up? Looks like you have 2
compute shaders in there, although my bet is on the one that does all the
atomic ops on shared memory - that stuff changed between Kepler and Maxwell,
which could explain why it works on GM107.

-- 
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/20170125/6cbb9a5d/attachment.html>

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

--- Comment #6 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Oh wait - while there are 2 compute shaders, you only use one of them (the one
with all the shared atomics). Also need to double-check that it's not an
earlier draw messing things up (e.g. that the compute shader is getting the
proper inputs). But my bet is on an issue in the compute shader.

-- 
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/20170125/df6300ae/attachment.html>

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

--- Comment #7 from Boyan Ding <stu_dby at 126.com> ---
(In reply to Ilia Mirkin from comment #6)
> Oh wait - while there are 2 compute shaders, you only use one of them (the
> one with all the shared atomics). Also need to double-check that it's
not an
> earlier draw messing things up (e.g. that the compute shader is getting the
> proper inputs). But my bet is on an issue in the compute shader.
I agree with you, since the same compute shader input was also used in
subsequent rendering. If that were wrong, the following render would also be
incorrect.

-- 
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/20170125/17e1c633/attachment.html>

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

--- Comment #8 from Samuel Pitoiset <samuel.pitoiset at gmail.com> ---
A missing OP_CCTL maybe? I have something which could help (but it's
definitely
not the right thing to do).

The possible fix is here:
https://cgit.freedesktop.org/~hakzsam/mesa/commit/?h=atomic_fixes&id=d3a1158acde83d9d7a2a58e431623dd89e59ca65

-- 
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/20170125/98971253/attachment.html>

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

--- Comment #9 from Samuel Pitoiset <samuel.pitoiset at gmail.com> ---
That might explain the failure on kepler (and presumably fermi) because maxwell
doesn't need that.

-- 
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/20170125/f57cd958/attachment-0001.html>

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

--- Comment #10 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to Samuel Pitoiset from comment #8)
> A missing OP_CCTL maybe? I have something which could help (but it's
> definitely not the right thing to do).
> 
> The possible fix is here:
> https://cgit.freedesktop.org/~hakzsam/mesa/commit/
> ?h=atomic_fixes&id=d3a1158acde83d9d7a2a58e431623dd89e59ca65
Nope. It does change the rendering very slightly - there's now one bar
consistently in the histogram - still incorrect.

-- 
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/20170125/b2f21957/attachment.html>

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

--- Comment #11 from Boyan Ding <stu_dby at 126.com> ---
Created attachment 129157
  --> https://bugs.freedesktop.org/attachment.cgi?id=129157&action=edit
The compute shader binary and assembly compiled with nouveau

I took some time today to capture the compiled shader binaries under nouveau
and proprietary driver. It seems there are differences when handling atomic
operations. The code generated by nvidia driver (will be attached below) is
rather huge, but seems mostly repetitions of several small sections of code.

I don't know about nvidia isa, but hope it helps.

-- 
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/20170126/d2ce8118/attachment-0001.html>

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

--- Comment #12 from Boyan Ding <stu_dby at 126.com> ---
Created attachment 129158
  --> https://bugs.freedesktop.org/attachment.cgi?id=129158&action=edit
The compute shader binary and assembly compiled with proprietary driver

-- 
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/20170126/3d99f037/attachment.html>

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

--- Comment #13 from Boyan Ding <stu_dby at 126.com> ---
Now I doubt if the problem really lies in the atomic operations, even in
compiler at all. I changed the compute shader a little bit, only letting thread
(0, 0) to accumulate its result to the ssbo (the dividing factor in histogram
fragment shader changed from 20000 to 20). This bypasses atomic operation and
shared memory, but the same problem persists.

I suspect that the input state of compute shader is somehow invalid, and that
explains why removing one frame of the trace will magically eliminate the
problem.

-- 
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/20170206/530d7eb4/attachment.html>

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

--- Comment #14 from Boyan Ding <stu_dby at 126.com> ---
Created attachment 129380
  --> https://bugs.freedesktop.org/attachment.cgi?id=129380&action=edit
A minimal reproducer

I wrote another much simpler program today to find the real cause of this bug.
Turns out that compute shader is unable to sample from depth texture.

The attached program first renders a shape to a FBO. Then a compute shader is
used to copy the color and depth textures attached to the former FBO to a
shader image, which is drawn to the screen. The depth part is different between
nouveau and other drivers.

Compile the program with gcc test.c -lglfw -lGLEW -lGL

-- 
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/20170207/425f1d9a/attachment.html>

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

--- Comment #15 from Boyan Ding <stu_dby at 126.com> ---
Created attachment 129381
  --> https://bugs.freedesktop.org/attachment.cgi?id=129381&action=edit
Correct shader image (i965)

-- 
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/20170207/94c614c9/attachment.html>

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

--- Comment #16 from Boyan Ding <stu_dby at 126.com> ---
Created attachment 129382
  --> https://bugs.freedesktop.org/attachment.cgi?id=129382&action=edit
Incorrect shader image (nouveau)

-- 
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/20170207/d3268f48/attachment.html>

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

--- Comment #17 from Ilia Mirkin <imirkin at alum.mit.edu> ---
A few observations:

- Pretty sure you want GL_TEXTURE_FETCH_BARRIER_BIT. Not that this matters for
nvc0.
- In addition to this always working on GM107, it *sometimes* works on my
GK208. Something about card state? Or something in compute insufficiently
initialized?
- I tried setting the DEPTH_TEXTURE bit in the TIC with no effect.
- The GM107 works just as effectively with both old- and new-style TIC formats.
- Throwing glFlush or glTextureBarrier into the mix made no difference, so
it's
not a cache issue.
- Switching to DEPTH24 and DEPTH32F made no difference.

-- 
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/20170212/6e139984/attachment.html>

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

--- Comment #18 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Also likely relevant is the fact that all these fail, even on GM107. But the
ones for other shader stages do pass. We're clearly missing some setting of
some kind.

dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.const_literal.compute.sampler2dshadow,Fail
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.const_literal.compute.samplercubeshadow,Fail
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.const_literal.compute.sampler2darrayshadow,Fail
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.const_literal.compute.isampler2d,Fail
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.const_expression.compute.sampler2dshadow,Fail
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.const_expression.compute.samplercubeshadow,Fail
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.const_expression.compute.sampler2darrayshadow,Fail
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.uniform.compute.sampler2dshadow,Fail
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.uniform.compute.samplercubeshadow,Fail
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.uniform.compute.sampler2darrayshadow,Fail
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.dynamically_uniform.compute.sampler2dshadow,Fail
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.dynamically_uniform.compute.samplercubeshadow,Fail
dEQP-GLES31.functional.shaders.opaque_type_indexing.sampler.dynamically_uniform.compute.sampler2darrayshadow,Fail

-- 
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/20170213/ce33c540/attachment.html>

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

Boyan Ding <stu_dby at 126.com> changed:

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

--- Comment #19 from Boyan Ding <stu_dby at 126.com> ---
commit 956556b3c30ce3d38d0af795f9383df3bc2cf8a2
Author: Ilia Mirkin <imirkin at alum.mit.edu>
Date:   Mon Feb 13 11:14:51 2017 -0500

    nvc0: disable linked tsc mode in compute launch descriptor

    Empirically, this makes things work. Presumably this was originally
    copied from the blob, which does make use of linked tsc mode.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99532
    Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
    Reviewed-by: Samuel Pitoiset <samuel.pitoiset at gmail.com>
    Cc: mesa-stable at lists.freedesktop.org

-- 
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/20170214/7aa15b29/attachment.html>