| Summary: | [SNB] performance regression: screen stuttered when running the demo of 3D games with compiz enabled without GPU semaphores | ||||||
|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | meng <mengmeng.meng> | ||||
| Component: | DRM/Intel | Assignee: | Chris Wilson <chris> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | high | CC: | jbarnes, xunx.fang | ||||
| Version: | unspecified | ||||||
| Hardware: | All | ||||||
| OS: | Linux (All) | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
meng
2011-01-23 22:43:59 UTC
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... 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. |
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.