Bug 48077 - [SNB IVB]Piglit general/read-front randomly fails under compositor
Summary: [SNB IVB]Piglit general/read-front randomly fails under compositor
Status: VERIFIED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: All Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-30 00:34 UTC by lu hua
Modified: 2015-03-11 06:12 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch (658 bytes, patch)
2014-03-18 16:57 UTC, Iago Toral
Details | Splinter Review

Description lu hua 2012-03-30 00:34:58 UTC
System Environment:
--------------------------
Arch:             i386
Platform:         Sandybridge
Libdrm:		(master)2.4.33
Mesa:		(master)a7b8e16dc6fb3e076f0bce9b8c68fdce31837848
Xserver:		(master)xorg-server-1.12.0-50-g641a1b9363d59808d2586f9e84847ccc69701482
Xf86_video_intel:	(master)2.18.0-153-g6142232fa0feeb39412cda85ca727cc770eaa042
Libva:		(vaapi-ext)f12f80371fb534e6bbf248586b3c17c298a31f4e
Libva_intel_driver:(vaapi-ext)82fa52510a37ab645daaa3bb7091ff5096a20d0b
Kernel:	(drm-intel-next-queued) 23f54beafee1c31c7f0127650ec2903d80b3dfeb

Bug detailed description:
-----------------------------
The result of general_read-front is unstable under gnome mode. It happens on sugarbay and ivybridge with mesa master and 8.0 branch. 
It fails 2 in 5 runs.
It passes under X mode.
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' }

Reproduce steps:
----------------------------
1.    Start  X
2.    Start  gnome-session
3.    ./bin/read-front -auto
Comment 1 Eric Anholt 2012-07-27 00:11:11 UTC
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>
Comment 2 Kenneth Graunke 2012-08-05 09:51:30 UTC
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?
Comment 3 Eric Anholt 2012-08-06 15:46:40 UTC
Ken: read-front *should* fail if the window is obscured uncomposited.  It should never fail when composited.
Comment 4 Chad Versace 2012-08-06 19:39:52 UTC
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.
Comment 5 lu hua 2012-08-08 02:37:08 UTC
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' }
Comment 6 Iago Toral 2014-03-14 12:54:55 UTC
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.
Comment 7 Iago Toral 2014-03-18 16:57:05 UTC
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.
Comment 8 Iago Toral 2015-03-10 08:12:54 UTC
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>
Comment 9 Matt Turner 2015-03-10 17:05:54 UTC
Feel free to mark as RESOLVED in that case. :)
Comment 10 lu hua 2015-03-11 06:12:53 UTC
Verified.Fixed.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.