Bug 48077

I've just pushed piglit changes that catch gnome-shell bugs that cause spurious failures on some of our tests.  Please re-test with that.  If you get the "spurious resize" warning, then the test needs to be re-run to get a valid result.

commit dcb1d026f3769c1dda85198bd554954877b7e233
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Jul 18 16:26:43 2012 -0700

    util: Warn when we get a window resize during an auto run.
    
    We've got a bunch of instances of this happening intermittently during
    runs with gnome-shell.  Because our tests are not generally able to
    handle resizes, they would show up as spurious failures that are hard
    to reproduce.  Instead, provide a diagnostic message and report WARN.
    
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

I can make this fail without a compositor.  Under Openbox, I ran:

$ while true; do ./bin/read-front -auto | grep -v pass; done

and then clicked the maximize/unmaximize button on my terminal window a few times (which, given the right timing, probably obscures the test's window).  The test occasionally fails.

Maybe it's just something about flushing the front buffer and compositors just happen to poke the bear more than usual?

Ken: read-front *should* fail if the window is obscured uncomposited.  It should never fail when composited.

I am unable to confirm this bug on Ivybridge with Mesa master(caa4ae5) 64-bit. I ran read-front 1024 times under two different compositing managers, xcompmgr and gnome-shell, without failure.

System Environment:
Platform:ivybridge
Mesa:	(master)7d65356d8a4d268dce4c933d7704d709e1cdacfa
Kernel:	(drm-intel-next-queued) ab3951eb74e7c33a2f5b7b64d72e82f1eea61571
Start  gnome-session, run: ./bin/read-front -auto

output:
Probe at (0,0)
  Expected: 0.000000 0.000000 1.000000
  Observed: 0.000000 0.000000 0.000000
Probe at (0,50)
  Expected: 0.000000 1.000000 0.000000
  Observed: 0.000000 0.000000 0.000000
PIGLIT: {'result': 'fail' }

I can reproduce this consistenly under a gnome-session with IVB.

After some debugging it looks like we are losing the DRI2_InvalidateBuffers event from the X server when we create the window and call glXMakeCurrent() during the test startup. As a consequence, when we then execute glClearColor(), we will not update our buffers since intel_update_renderbuffers() won't be called because we don't have a new stamp.

I found that simply including a usleep(100000L) anytime between  the moment we send the X_DRI2GetBuffersWithFormat request and the mapping of the window fixes the problem (that is, we get the invalidate event), so it looks like something is happening in that time frame that prevents the event from ever being sent.

Then I traced the problem down to the mapping of the window itself. Waffle maps the window with xcb_map_window_checked. Replacing this with xcb_map_window fixes the problem.

I am not familiar enough with the X server implementation, but it looks as if the checked mapping is preventing the X server from sending the initial invalidate event for the window buffers, which I guess is not the expected behavior.

Created attachment 96012 [details] [review]
Patch

This is a patch to work around the X server issue I commented above in Waffle. Applies on top of release tarball 1.3.0 replacing xcb_map_window_checked by xcb_map_window.

Someone running into this bug may find it useful to avoid false positives. The problem may be affecting others tests too.

Looks like this has been fixed for a while, it always passes for me with master on IvyBridge. I tracked the commit that fixed it to:

commit cde8bad1c9363ee293ae7844bcecb6179426ea65
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Mon May 5 11:02:18 2014 -0700

    i965: Always intel_prepare_render() after invalidating front buffers.
    
    Fixes glean/texture_srgb, which hit recursive-flush prevention
    assertions in vbo_exec_FlushVertices.
    
    This probably hurts the performance of front buffer rendering, but
    very few people in their right mind do front buffer rendering.
    
    Fixes Glean's texture_srgb test.
    
    Cc: "10.2" <mesa-stable@lists.freedesktop.org>
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
    Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
    Reviewed-by: Eric Anholt <eric@anholt.net>

Feel free to mark as RESOLVED in that case. :)

Verified.Fixed.