| Summary: | [945 lvds downclock] Very slow redraw performance | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Alexander Lam <lambchop468> |
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | florian |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
|
Description
Alexander Lam
2012-12-28 21:52:18 UTC
Created attachment 72231 [details]
xorg.log
(In reply to comment #0) > Symptoms: > urxvt: very slow - I can see each character being drawn onto the screen > > glxgears: running with vblank_mode=0, glxgears runs at about 22.5 FPS. > > youtube: In Firefox, playing a video with Adobe Flash, and drm.debug=0x2, I > can see that lvds upclock does not happen for frame updates of the video - > lvds is downclocked for continuous periods of time on the order of seconds > (expected behavior?) This can be expected as we have never marked the fb as busy if the scanout is accessed via the GTT mapping (which is how the swrast in flash will eventually be updated). The only thing that can be attributed to lvds downclocking here is the vblank limited glxgears. The 2D engine should not be rate limited by the vrefresh frequency - something else is broken. Your dmesg and a full-debug Xorg log would be useful. Created attachment 72232 [details]
logverbose=7 xorg log
(In reply to comment #3) > Created attachment 72232 [details] > logverbose=7 xorg log Sorry, what I meant was compile the ddx with --enable-debug=full and use sna, and capture a log of using urxvt. Also see if anything shows up on top and perf top when urxvt is being very slow. And dmesg :) I think another useful piece of evidence with be intel-gpu-tools/tests/gem_gtt_speed. Yeah, I'm going to have to hold off - I am currently updating my system from software versions from August 2012 to now (archlinux rolling release - it's sometimes a pain). Until then I can't install new packages because of dependency issues. I'll be back soon. In the meantime, can you please grab intel-gpu-tools (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools) and paste the output of i-g-t/tests/gem_gtt_speed? Created attachment 72312 [details]
gem_gtt_speed results, latest rc kernel & latest stable ddx
the rest of the stuff you requested will be up within the hour
Created attachment 72313 [details]
gem_gtt_speed results, latest rc kernel & latest stable ddx (typo fixed)
Oops, I labeled both sets of results as LVDS downclocking enabled.
Short answer don't do that, you're hurting your hardware. How about a drm.debug=6 dmesg to verify that you are selecting sane values? Created attachment 72314 [details]
dmesg with lvds downclock dotclock=25500 kHz
Created attachment 72315 [details] [review] Only signal CRTC idle from the device idle Created attachment 72316 [details] [review] patch for kernel 3.8rc1 Yes, that fixes it. I've attached the patch I used on 3.8rc1. There was one rename and one removal of a line that wasn't needed. Thanks! Created attachment 72317 [details]
Results of gem_gtt_speed with patch
Daniel please take a look at the attached patch, good enough? commit cf5199e4092500056bcfac7eae76a17433a6c22f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jan 8 11:02:57 2013 +0000 drm/i915: Only run idle processing from i915_gem_retire_requests_worker Flagged for stable, but will only be backported from 3.9... A patch referencing this bug report has been merged in Linux v3.9-rc1: commit 725a5b54028916cd2511a251c5b5b13d1715addc Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jan 8 11:02:57 2013 +0000 drm/i915: Only run idle processing from i915_gem_retire_requests_worker |
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.