Created attachment 52331 [details]
git softpipe

Apologies, not a 7.11 regression afterall - llvmpipe's broken on 7.11 too.

Lauri,

Could you please try to obtain a trace of this issue with https://github.com/apitrace/apitrace , following the instructions in the INSTALL and README.

Just FYI, I tried some conformance and piglit stencil tests and they all passed with llvmpipe.  If it's a stencil bug, it's probably something slightly obscure.

Attaching the apitrace output. glretrace'd it with both softpipe and llvmpipe, results are the same as with the actual app.

hm, hit the size limit. Link:

http://kiwi6.com/file/g9064pv6ps

It looks like some sort of depth fighting.

It might be related to fbo-depth-sample-compare

I know that at least the llvmpipe should snap interpolated fragment Z to the depth buffer precision (i.e., 24bits), so that the Z values from the interpolator and depth buffer are consistent, and I had a patch that fixed that, but it didn't fully fix the  fbo-depth-sample-compare so I didn't complete it.

I'll try to search my git stash to see if I find it and if it fixes this issue.

I did find my old patch but it fixed nothing.  I'd really like to fix this, but there seems to be something very broken with depth in llvmpipe, that goes beyond the precision lost due to unorm24 <-> float32 conversions.



I've also looked at the trace more closely:

One thing odd about it is that it starts using the stencil buffer without clearing on the first time (it only clears the color and depth buffer). But I'm not sure if that's the problem.

Also the issue can be seen as early as draw call 837.

The first stencil clear is ironically, at call 838.

Oh, and I'm not sure if this is depth fighting, or culling. Because the edges of the shadows are visible and apparently correct.

Created attachment 52451 [details]
glut test program

Jose, I extracted some of the commands from the trace into a glut test harness and I think I've reproduced the bug.

A yellow floor quad is drawn first.  Then a sphere is drawn (as a stand-in for a shadow volume) into the stencil buffer then the shadow itself is drawn by drawing a window-sized quad with blending and stencil test.

If you look carefully, there's stray red pixels just below the round shadow.  If you rotate the scene (cursor keys, z, Z) you'll see the stray pixels randomly move around.

If you decrease the sphere tessellation, the number of artifacts decreases.  In the previously attached trace, the shadow volume appears to be very complicated (23424 vertices).  If you make the window smaller, the number of artifacts is less than if the window is large.

It seems as if we're writing stray pixels in the stencil code when drawing very small triangles.  But only when polygon culling is enabled.

Adding an initial glClear(GL_STENCIL_BUFFER_BIT) doesn't make any difference.

If I have time this week I'll try to debug further.

Created attachment 52585 [details]
0000000837.fglrx.png

Created attachment 52586 [details]
0000000837.llvmpipe.png

Created attachment 52587 [details]
0000000837.diff.png

Brian,

I see the stray pixels with your example here, but I'm not sure if it is the same issue.

See the attached screenshots of the trace at call 837, with llvmpipe and fglrx, and a difference map between them.

It looks like only the edges of the shadows were drawn.

I'm not 100% sure it's the same issue either, actually.  But note that I didn't try to reproduce the trace's projection parameters or object coordinates.  If I duplicated those params/coords used in the trace, perhaps the stray pixels would more distinctly correspond to the triangle edges like in the trace.  That might point toward a z-fighting or z-precision type of issue.

In any case, I think it's worth digging into the smaller test case first and see what's going on there.

I spent sometime today looking at this.

I modified glretrace to dump the stencil buffer instead of color buffer:
$ git diff
diff --git a/retrace/glstate_images.cpp b/retrace/glstate_images.cpp
index e534a65..75664e6 100644
--- a/retrace/glstate_images.cpp
+++ b/retrace/glstate_images.cpp
@@ -739,6 +739,7 @@ getFramebufferAttachmentDesc(Context &context, GLenum target, GLenum attachment,
 image::Image *
 getDrawBufferImage() {
     GLenum format = GL_RGB;
+    format = GL_STENCIL_INDEX;
     GLint channels = _gl_format_channels(format);
     if (channels > 4) {
         return NULL;

And ran retracediff.py script to compare the stencil buffer contents, on every draw call, between llvmpipe and Intel:


$ ./scripts/retracediff.py -r ./glretrace --src-env LD_LIBRARY_PATH=/home/jfonseca/projects/opengl/mesa/build/linux-x86_64-debug/gallium/targets/graw-xlib:/home/jfonseca/projects/opengl/mesa/build/linux-x86_64-debug/gallium/targets/libgl-xlib /home/jfonseca/projects/opengl/traces/stencil.trace
call	precision
387	36.802488
531	36.802488
622	36.802488
708	36.802488
776	36.802488
802	7.947939
{
  GL_ATTRIB_STACK_DEPTH: 0 -> 1,
  GL_COLOR_ARRAY: "GL_TRUE" -> "GL_FALSE",
  GL_COLOR_ARRAY_POINTER: 59042800 -> 62751856,
  GL_COLOR_WRITEMASK: [
    "GL_TRUE" -> "GL_FALSE",
    "GL_TRUE" -> "GL_FALSE",
    "GL_TRUE" -> "GL_FALSE",
    "GL_TRUE" -> "GL_FALSE"
  ],
  GL_CULL_FACE_MODE: "GL_BACK" -> "GL_FRONT",
  GL_CURRENT_MATRIX_ARB: [
    1 -> 1.961161,
    0 -> 0.07548513,
    0 -> 0.3849002,
    0,
    0,
    1 -> 1.962614,
    0 -> -0.3849002,
    0,
    0 -> -0.3922323,
    0 -> 0.3774257,
    1 -> 1.924501,
    0,
    0 -> -17.65045,
    0 -> -12.45505,
    0 -> 92.37605,
    1
  ],
  GL_DEBUG_CALLBACK_USER_PARAM: 36090016 -> 39956640,
  GL_DEPTH_WRITEMASK: "GL_TRUE" -> "GL_FALSE",
  GL_LIGHTING: "GL_TRUE" -> "GL_FALSE",
  GL_MATRIX_MODE: "GL_TEXTURE" -> "GL_MODELVIEW",
  GL_NORMAL_ARRAY: "GL_TRUE" -> "GL_FALSE",
  GL_NORMAL_ARRAY_POINTER: 61292368 -> 65157424,
  GL_POLYGON_OFFSET_BIAS_EXT: 0 -> 1,
  GL_POLYGON_OFFSET_FILL: "GL_FALSE" -> "GL_TRUE",
  GL_POLYGON_OFFSET_UNITS: 0 -> 1,
  GL_STENCIL_BACK_PASS_DEPTH_FAIL: "GL_KEEP" -> "GL_INCR_WRAP",
  GL_STENCIL_PASS_DEPTH_FAIL: "GL_KEEP" -> "GL_INCR_WRAP",
  GL_STENCIL_TEST: "GL_FALSE" -> "GL_TRUE",
  GL_TEXTURE_COORD_ARRAY: "GL_TRUE" -> "GL_FALSE",
  GL_TEXTURE_COORD_ARRAY_POINTER: 61081232 -> 64931200,
  GL_TRANSPOSE_CURRENT_MATRIX_ARB: [
    1 -> 1.961161,
    0 -> 0.07548513,
    0 -> 0.3849002,
    0,
    0,
    1 -> 1.962614,
    0 -> -0.3849002,
    0,
    0 -> -0.3922323,
    0 -> 0.3774257,
    1 -> 1.924501,
    0,
    0 -> -17.65045,
    0 -> -12.45505,
    0 -> 92.37605,
    1
  ],
  GL_VERTEX_ARRAY_POINTER: 61337392 -> 65378608,
  GL_VERTEX_ARRAY_STRIDE: 36 -> 12,
}

806	5.831233
837	5.831233

So the differences start on call 802. 

The attached stencil-802-intel.png stencil-802-llvmpipe.png show the stencil contents on that call.

It's still not clear whether this is a truly a depth stencil issue, or simply a depth test (polygon offset) problem.

Created attachment 69327 [details]
stencil-802-llvmpipe

Created attachment 69328 [details]
stencil-802-intel

Fixed by 82d7733b52e7c124a268c68395de140641b50c05. Replay still looks a bit odd to me but seems to be the same as with softpipe now, so if it's still wrong it must be another bug.