| 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@lists.freedesktop.org |
| Reporter | dark_sylinc@yahoo.com.ar |
| QA Contact | dri-devel@lists.freedesktop.org |
Created attachment 129119 [details] 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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
