| Summary: | Intel GM965 compiz works only partially after ring buffer flushed | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Dark Shadow <dark.shadow> | ||||||
| Component: | DRM/Intel | Assignee: | Jesse Barnes <jbarnes> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | medium | Keywords: | NEEDINFO | ||||||
| Version: | XOrg git | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
Dark Shadow
2009-06-23 02:11:52 UTC
Created attachment 27035 [details]
intel_gpu_dump output when compiz works only partially.
GPU dump output as announced in initial post. Too big to submit without compressing, sorry for that.
Created attachment 27323 [details] [review] restore the modeset for every activated crtc Will you please try the attached patch on the latest linus git tree and see whether the issue still exists after hibernation? Thanks. Thanks for the patch, I applied it on my current kernel. Unfortunately, this did not change anything. Currently, I don't have time to test it on the latest linus git tree, maybe I'll try later. Thanks for the test. Please try to test it on the latest linus git tree and I am looking forward to the test result. Thanks. I've cloned tuxonice-head (tracking linus' head), applied your patch, (tested hibernate/resume again,) pulled Eric Anholt's drm-intel-next repository. It does not make a difference, still the same issues. Sorry, your patch does not help. Additionally (in all kernel versions tested so far), the backlight is turned off at atomic copy, but not restored at resume. This is a bit annoying too. Versions: http://git.kernel.org/?p=linux/kernel/git/nigelc/tuxonice-head.git;a=commit;h=4e3adc7dc5d6da2b15b25d86debd2a611b9db09d http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=1ae8c0a56eeb3ed358b78ccadd024d6b721f26bc http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=74227141923a2f5049592219ab80e8733062a5d9 http://cgit.freedesktop.org/mesa/mesa/commit/?id=8ae02a3919bf31bd33f86208472e100eedb58497 http://cgit.freedesktop.org/mesa/drm/commit/?id=fbac5891b91c795de61f4d7cbc1a6799474364ad Thanks for the test. Maybe the compiz issue is not related with the suspend/resume. Will you please do the following test and see whether the compiz still can work well ?(This had better be done on the latest linus git tree. Of course the 2.6.31-rc2 is also ok). a. boot the system with KMS disabled and enter the X-environment b. start compiz and then switch to the console mode by using the command of "chvt 2" c. use the tool of intel_gpu_dump to get the gpu dump d. switch to the X again by using "chvt 7" and see whether the compiz still can work well? Thanks. Hi, All
This issue can be reproduced on another laptop. After doing suspend/resume, the compiz can't work well.
Then I do the following test on the box
1. boot the system with KMS disabled
2. Start x and start compiz window
3. switch to the console mode by using chvt.
4. switch to the X again by using chvt and find that compiz can't work well.
When it switches to console mode by using chvt, the ring buffer will be flushed. And after it switches to X mode again, the compiz can't work well.
But if mode switch is tested in KMS mode, the compiz can work well. And the ring buffer won't be flushed in KMS mode when we switch the mode between console and X.
In fact when we do the suspend/resume, we will have to flush the ring buffer. In such case it brings that the compiz can't work well.
So IMO this issue is not related with suspend/resume. Maybe it is related with how the ring buffer is handled.
thanks.
assign this non-suspend/resume bug away from ykzhao. Jesse, could you take a look? Could be ring flushing... but it could also be the way we handle GTT bind/unbind across VT switch (in UMS mode) and hibernation. In both of those cases we'll be rebuilding the GTT from scratch, whereas KMS VT switch is much lighter weight; it'll just change modes and switch buffers. I think we're probably missing some restore code in both cases. OpenGL clients like compiz expect their textures to be available whenever they access them... Is it possible for you to try using a KMS configuration? We're trying to deprecate the UMS code for various reasons (suspend/resume fragility among them). I've used KMS before. Whatever, after upgrading to kernel-2.6.31 and with latest versions of mesa, drm and intel drivers, everything is fine now. Thanks for your help. |
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.