[Bug 99511] Compute Shader can't deal with Depth Buffers correctly

[bugzilla-daemon at freedesktop.org]

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

            Bug ID: 99511
           Summary: Compute Shader can't deal with Depth Buffers correctly
           Product: Mesa
           Version: git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel at lists.freedesktop.org
          Reporter: dark_sylinc at yahoo.com.ar
        QA Contact: dri-devel at lists.freedesktop.org

Created attachment 129119
  --> https://bugs.freedesktop.org/attachment.cgi?id=129119&action=edit
Sample repro. Also contains GCN generated ISA for the Compute Shader

OS: Linux Ubuntu 16.04
Kernel 4.7.3
AMD Radeon HD 7770 1GB
Mesa from git 0f8afde7baf2b4764c3832387607021f2d318f6e

After discovering a Mesa bug in my own app; I've managed to isolate it in a
repro.

The demo does the following:
1. Render a triangle with a specific depth pattern to an 8x8 FBO depth texture
(also outputs colour but this will be ignored). We use gl_FragDepth to achieve
this.
2. Use a compute shader to copy the 8x8 depth texture to a GL_R32F. The CS
copies 4 pixels (2x2 blocks) per thread (there will a few out of bound read and
writes that per spec should be handled correctly by GLSL). It basically acts
like a memcpy.
3. Render a triangle to the RenderWindow sampling from that GL_R32F we just
wrote to.

On Windows, it works as expected and produces the following output:
http://imgur.com/MLWzweG
You can see the 8x8 grid pattern, (the sampling causes the tiling).

However on Mesa, I only get a black triangle.

The sample works as intended if we try to copy colour. I did not research
whether the problem is the GL_R32F destination, or that the source is a depth
texture rather than a colour texture.

The sample should be easy to build and run.

A few tips:
1. There is a "#if 1" in main.cpp. Flip it to 0 so that that step 3 will sample
directly from the depth buffer instead of using the compute shader. It will
produce the desired output (just for reference), though it's grey instead of
red (because of GL specs).

2. Inside the "#if 1", changing instances of texName[1] & dstTexName[1] for
texName[0] & dstTexName[0] will cause the demo to use the colour texture
instead of the depth; which does work as expected.

Oddities:
Comparing Mesa's generated ISA vs CodeXL makes no sense.

CodeXL generates something like this:
image_load v[X:X], v[0:3], s[X:X] dmask:0xf
image_load v[X:X], v[4:7], s[X:X] dmask:0xf
image_load v[X:X], v[8:11], s[X:X] dmask:0xf
image_load v[X:X], v[12:15], s[X:X] dmask:0xf

image_store v[X:X], v[0:3], s[X:X] dmask:0xf unorm glc
image_store v[X:X], v[4:7], s[X:X] dmask:0xf unorm glc
image_store v[X:X], v[8:11], s[X:X] dmask:0xf unorm glc
image_store v[X:X], v[12:15], s[X:X] dmask:0xf unorm glc

That is, both loads and stores reuse the second arguments and they match.

However Mesa generates:
image_load_mip v[X:X], v[0:3], s[X:X] dmask:0xf
image_load_mip v[X:X], v[4:7], s[X:X] dmask:0xf
image_load_mip v[X:X], v[8:11], s[X:X] dmask:0xf
image_load_mip v[X:X], v[12:15], s[X:X] dmask:0xf

image_store v[X:X], v[0:1], s[X:X] dmask:0xf unorm glc
image_store v[X:X], v[34:35], s[X:X] dmask:0xf unorm glc
image_store v[X:X], v[11:12], s[X:X] dmask:0xf unorm glc
image_store v[X:X], v[21:22], s[X:X] dmask:0xf unorm glc

That is, the vectors used for the image_store look totally random; and it
stands out that subtracting these ranges is 1 (i.e. Mesa's 35-34 = 1) when
CodeXL's is always 3. Either the dump is decoding the instructions incorrectly,
the ISA is wrong, or this is a different but wasteful way to do it correctly
(???).
Also Mesa uses image_load_mip whereas CodeXL prefers image_store.

Happy bug hunting

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170124/d8aea093/attachment.html>