There is some information in bug 32752.

Is it an FBC issue (going via compiz might triggering a blit?)? Does i915.powersave=0 make any difference?

On the other hand it might be a pageflipping problem...

Or something entirely different.

Add "i915.powersave=0" into grub.conf, screen still stutter in (drm-intel-next)5d6135012e9a7aa8a9128145ed9315eb916feea2.

I've definitely seen this on my desktop, but it doesn't seem to be 100% reproducible yet...

And I've now spent a few hours trying to reproduce that earlier failure.

*sigh* False alarm. I had a kernel without "reverse-engineer safe snb wm0 values" without which I get random hangs on that machine.

Has anybody followed any additional info on the value that needs to be programmed into wm0?

When it stutters and you have some i915_hangcheck_elapsed errors:

$ echo 1 | sudo tee /sys/kernel/debug/dri/0/i915_wedged

and attach the resulting /sys/kernel/debug/dri/0/i915_error_state.

Created attachment 43150 [details]
The resulting  of i915_error_state

Chris, any idea? We could try bisect if no better method.

I've had a chance now to try and reproduce this on a HuronRiver rev09 to no avail. Is this still reproducible on your test machines?

(In reply to comment #10)
> I've had a chance now to try and reproduce this on a HuronRiver rev09 to no
> avail. Is this still reproducible on your test machines?

Yes. It still exists on our Huronriver rev09 only with compiz enabled. If not enable compiz, there is no such problem.

Ok, a couple of approaches: bisection and tracing.

Grab trace-cmd from git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git and see if you can capture the stutter whilst running trace-cmd record -e i915 (you will need to have enabled tracers/ftrace under kernel debugging) and upload the trace.dat. (It will be too big for bugzilla so just place it on the ftp and give me a link.)

1.Test in commit e8b2c3c47a53348aebbbeb5322e32937df958793 when enable compiz,the bug 'stutter' does not exist on Huronriver(0216 rev08,0116 rev09).
And the performance is improved.Compare commit 6927faf30920b with commit e8b2c3,rgb10text 923k to 1270k;demo of openarane 41.8 to 89.9 fps.
2.In commit e8b2c3c,system hangs on Huronriver(0216 rev08) when running demo of urbanterror only xinit& by 3-5 times(bug 32752).But it works fine on Huronriver(0116 rev09) with commit e8b2c3c(running the demo 15 times).

So this original bug is caused by disable semaphore on SNB mobile (workaround bug#32572). And with that extends to desktop (a1656b9090f7008d2941c314f5a64724bea2ae37), this also impacts SNB desktop now.

.38 behaviour should in theory be the same as .37, so no regression there. .38 includes the i915.semaphores=1 workaround, and drm-intel-next turns them on by default. I think we fully understand the issue and there is no near-term fix better than what we already have in place.

I have a patch "drm/i915: Enable use of GPU semaphores to sync page-flips on SNB" which improves matters further and plans to improve the DDX.

Downgrading priority, as I think all that really remains is thorough testing on .38 with i915.semaphores=1 to see if the root cause preventing enabling by default has been fixed (the FIFO overflow is my guess).

I see semaphore has been enabled in -backport, so shall we close this one?

Yes, I've come to the same conclusion that it is time to close this bug.

Verified with the commit c94249d2a6911daf74f329e05c42e076af2cd024,it works fine.

Reopening. GPU semaphores were turned to disabled in 2.6.39.

*** Bug 37090 has been marked as a duplicate of this bug. ***

So one of the reasons for SNA is to avoid the need for semaphores for SwapBuffers...

Another one for http://lists.freedesktop.org/archives/intel-gfx/2011-June/010979.html

Nah, we never mentioned the BLT hang-check issue on this one ;-)

If enabling semaphores fixes this issue then the real blocker is getting Andrew's machine fixed with semaphores enabled.  And Daniel's patch may do that; we need him to test.  Also missing blit ring interrupts will probably cause stutter even if it doesn't trigger the hangcheck timer?

One can envision where there is a train of BLT interrupts and we happen to be waiting on the early one whose write goes astray. Not sure that matches the usage here though.

We need semaphores for performance as mesa also uses intelClearWithBlit on SNB...

And Andrew's system hang is more than likely one of the Gnome gpu hangs where the gpu reset killed the box. (That has happened often enough that it turns out I've i915.reset=0 on both my snb boxes.)

Test the commit 6a574b5b with above patch, the problems("hang check" and
"stuttered") have been fixed(disable semaphores). 
The 3D performance improved much except 2D.
        6a574b5b(enable semaphores)    6a574b5b(disable semaphores +above patch)
rgb10text(2D)       2380k                                   1100k
aa10text (2D)       2667k                                   1640k
openarena           86.2fps                                 98.8fps
urbanterrror        71.4fps                                 68.5fps
padman              100.7fps                                92fps
nexuiz              20fps                                   19.5fps

(In reply to comment #26)
>         6a574b5b(enable semaphores)    6a574b5b(disable semaphores +above
> openarena           86.2fps                                 98.8fps

I didn't notice this before. Can we follow this up in a new bug, please?

(In reply to comment #27)
> (In reply to comment #26)
> >         6a574b5b(enable semaphores)    6a574b5b(disable semaphores +above
> > openarena           86.2fps                                 98.8fps
> 
> I didn't notice this before. Can we follow this up in a new bug, please?

Unless of course, this is the case where openarena+enable_semaphores+patch is >= 98.8fps.

Performances on Sugarbay with commit 6a574b5b9.
There are 4 columns(enable/disable semaphores and +/- patch).
2D/3D	        disable	 enable	   disable+patch	 enable+patch
2D-aa10text	1790k	 2650k	      1640k	   2550k
2D-rgb10text	1380k	 2380k        1100k	   2320k
openarena	11	 86.2	      98.8	   103.9 fps
urbanterror	10.5	 71.4	      68.5	   70.9  fps
padman	        12.1	 100.7	      92	           100.3 fps

A patch referencing this bug report has been merged in Linux v3.0-rc4:

commit 498e720b96379d8ee9c294950a01534a73defcf3
Author: Daniel J Blueman <daniel.blueman@gmail.com>
Date:   Fri Jun 17 11:32:19 2011 -0700

    drm/i915: Fix gen6 (SNB) missed BLT ring interrupts.

A patch referencing a commit referencing this bug report has been merged in Linux v3.0-rc5:

commit ec6a890dfed7dd245beba5e5bcdfcffbd934c284
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jun 21 18:37:59 2011 +0100

    drm/i915: Apply HWSTAM workaround for BSD ring on SandyBridge

Test on(drm-intel-fixes)f01c22fd59aa10a3738ede20fd4b9b6fd1e2eac3,fixed the SNB
problem :"hang check", "screen stuttered" and performance regression when running the demo of 3D games on SNB.So, I close this bug.
But without semaphores,2D performance regression on SNB,pls see bug 38861.

Test (drm-intel-fixes)f01c22fd59aa10a3738ede20fd4b9b6fd1e2eac3 on IVB, the problem "hang check", "screen stuttered" still exist. Pls see the bug 38862.

Closing old verified+fixed.