Summary: | [SNB sna] delayed/missing rendering, fixed with 3.0 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | clem <luca.clem> | ||||||
Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
Severity: | major | ||||||||
Priority: | medium | ||||||||
Version: | 7.6 (2010.12) | ||||||||
Hardware: | x86-64 (AMD64) | ||||||||
OS: | Linux (All) | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Attachments: |
|
Description
clem
2011-06-27 13:10:53 UTC
The important bit of information that you need to tell me that Bryce hinted at, was what exactly slowed down? What desktop environment and applications are you running? Do you have a precise benchmark that hints as to the nature of the slowdown? Can you please attach both Xorg.log and dmesg? Created attachment 48484 [details]
Xorg.0.log with new driver git20110627.44cd6ebf
Created attachment 48485 [details]
dmesg with new driver git20110627.44cd6ebf
(In reply to comment #1) > The important bit of information that you need to tell me that Bryce hinted at, > was what exactly slowed down? What desktop environment and applications are you > running? Do you have a precise benchmark that hints as to the nature of the > slowdown? > > Can you please attach both Xorg.log and dmesg? Files attached. I'm using ubuntu unity, and the whole desktop is quite unusable with new driver. everything is slowed down. if i open a terminal and i type something, the character I've typed are displayed with a delay of several seconds. The same happens if I open a browser and I type a address. If a move a window with the mouse, the windows stays in the original position. only after several seconds it is suddenly redrawn in the new position. if the unity launcher is hidden and i put the mouse on the corner, it takes very long to appear again. after few time, if i have several applications opened, the desktop becomes completely unusable. I have to open a vt by pressing Ctrl+Alt+F1 and reboot. Maybe it's not a bug in the driver, there is only some problems with my installation. I don't know... but every problems disappears if a go back to the previous version of the driver (git20110624.471115a9) and the system is very stable and smooth. (maybe the new driver brings some new feature that is not fully supported by my hardware?) Two more things: can you give me a dmesg after using the system for a while, and can you try a 3.0.0 kernel (probably need a mainline ppa)? (In reply to comment #5) > Two more things: can you give me a dmesg after using the system for a while, > and can you try a 3.0.0 kernel (probably need a mainline ppa)? The files that i attached before are taken after some minutes of usage. Do you want me to get others after some more time? or just after the login? Tomorrow I will give a try to kernel v3.0-rc4 and report back (In reply to comment #6) > The files that i attached before are taken after some minutes of usage. Do you > want me to get others after some more time? or just after the login? No, that's fine. I just wanted to be sure that you had observed the failure before you grabbed the dmesg so I could be certain if one of the expected failure modes was being reported. It wasn't, but I know of many more bugs... > Tomorrow I will give a try to kernel v3.0-rc4 and report back Thanks. I'm using right now the lastest kernel that i found in deb format, it's 3.0rc4 and the problem seems solved. the system is smooth and responsive once again. During normal use i cannot see any difference between the two versions of the intel driver. If it's useful to have a more accurate measurement of the performance of the two drivers, somebody should suggest me a proper benchmark tool because i don't know any. (In reply to comment #8) > I'm using right now the lastest kernel that i found in deb format, it's 3.0rc4 > and the problem seems solved. the system is smooth and responsive once again. > During normal use i cannot see any difference between the two versions of the > intel driver. No, you wont really be able to tell since using a compositing WM drops the performance immensely, and then sna is only about 50% faster -- the difference between fast and very fast, until you hit one of the boundary cases handled by sna but forces a software fallback on uxa. And even if you aren't both uxa and sna on SNB are GPU bound (more or less), just sna uses about 1/5 the CPU to do so. (Conversely if you were just to measure how fast both paths could feed the GPU, i.e. without caring for latency of rendering, sna is 5x faster.) > If it's useful to have a more accurate measurement of the performance of the > two drivers, somebody should suggest me a proper benchmark tool because i don't > know any. That's fine. I just needed to characterise your problem, as it turns out the issue was a rather more severe and fundamental bug than just merely bad performance. Bisection suggests the fix is in this range, all of which are unbootable: commit 9e3c256d7d56a12a3242222945ce8e6347f93fa0 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed May 18 13:51:43 2011 -0700 drm/i915: initialize gen6 rps work queue on Sandy Bridge and Ivy Bridge commit 56184e3da005e0259fc628706351b54fcc4527db Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue May 17 14:03:50 2011 +0100 drm/i915/sdvo: Reorder i2c initialisation before ddc proxy commit 61e499bf05254aca0fab08e2c91643331a15e725 Author: Keith Packard <keithp@keithp.com> Date: Tue May 17 16:13:52 2011 -0700 drm/i915: FDI link training broken on Ironlake by Ivybridge integration commit a51f7a66fb5e4af5ec4286baef940d06594b59d2 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu May 5 14:42:26 2011 -0700 drm/i915: enable rc6 by default commit c1a9f047638b27e481d097910604316b8a0d132b Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu May 5 15:24:21 2011 -0700 drm/i915: add fbc enable flag, but disable by default commit 8547920fc6f0d288fcc57ca705ccb2d00920fc72 Author: Feng, Boqun <boqun.feng@intel.com> Date: Thu Apr 28 17:15:33 2011 +0800 drm/i915: clean up unused ring_get_irq/ring_put_irq functions commit 5bfa1063a775836a84f97e4df863fc36e1f856ad Author: Feng, Boqun <boqun.feng@intel.com> Date: Mon May 16 16:02:39 2011 +0800 drm/i915: fix user irq miss in BSD ring on g4x commit 645c62a5e95a5f9a8e0d0627446bbda4ee042024 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed May 11 09:49:31 2011 -0700 drm/i915: split PCH clock gating init commit 28963a3eb5e2ae861995c2f7c15c7de982b3ce0e Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed May 11 09:42:30 2011 -0700 drm/i915: add Ivybridge clock gating init function commit 4593010b68247e6bed746da4e15f66f06e239e28 Author: Eric Anholt <eric@anholt.net> Date: Fri May 6 17:12:35 2011 -0700 drm/i915: Update the location of the ringbuffers' HWS_PGA registers for IVB The most likely fix is then disabling the FBC, which is consistent with the presentation of the bug. |
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.