Bug 22433 - Intel GM965 compiz works only partially after ring buffer flushed
Summary: Intel GM965 compiz works only partially after ring buffer flushed
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Jesse Barnes
QA Contact:
Keywords: NEEDINFO
Depends on:
Reported: 2009-06-23 02:11 UTC by Dark Shadow
Modified: 2017-07-24 23:09 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

intel_gpu_dump output when compiz works only partially. (77.87 KB, application/octet-stream)
2009-06-23 02:16 UTC, Dark Shadow
no flags Details
restore the modeset for every activated crtc (1.11 KB, patch)
2009-07-02 01:30 UTC, ykzhao
no flags Details | Splinter Review

Description Dark Shadow 2009-06-23 02:11:52 UTC
xf86-video-intel: bfeeac6de096256fca82244338bb45d53ee53cbc
mesa: 70e72070fce6aa1e0918dcc62c1949465cee69f7
libdrm: 790097c51330090b2b7b90429b9ab8ddf259fd8e
xorg-server: X.Org X Server (1.6.2 RC 1), Release Date: 2009-5-8
kernel: 2.6.30 gentoo-sources-2.6.30-r1, tuxonice patch applied

After resume from hibernation, decorations are missing (using emerald) and cannot be restored with `emerald --replace' but only by restarting compiz. Other effects are not working, too, like zoom when opening windows.
This can be easily solved by running compiz-manager to kill and restart emerald and compiz.

Steps to reproduce:
1. Start compiz.
2. Hibernate.
3. Resume.

Actual Results:
. Compiz works partially (some effects don't work anymore, decoration is missing even when restarting emerald), everything else works fine.

Expected Results:
. Everything's working fine.

glxgears runs fine with hibernate and resume.

I'll attach intel_gpu_dump output after resume, with compiz misbehaving.

Other patches applied:
compiz glxDestroyPixmap changed like suggested in bug #20704, comment #48.
Nothing else (not using Eric Anholt's intel-drm anymore since I was not able to merge it into my git repo without issues).
Comment 1 Dark Shadow 2009-06-23 02:16:00 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.
Comment 2 ykzhao 2009-07-02 01:30:47 UTC
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?

Comment 3 Dark Shadow 2009-07-02 03:27:49 UTC
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.
Comment 4 ykzhao 2009-07-02 19:18:51 UTC
Thanks for the test.
Please try to test it on the latest linus git tree and I am looking forward to the test result.


Comment 5 Dark Shadow 2009-07-03 02:48:04 UTC
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.


Comment 6 ykzhao 2009-07-06 19:47:36 UTC
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?

Comment 7 ykzhao 2009-07-16 02:18:44 UTC
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.

Comment 8 Gordon Jin 2009-07-16 18:45:27 UTC
assign this non-suspend/resume bug away from ykzhao.

Jesse, could you take a look?
Comment 9 Jesse Barnes 2009-08-31 11:12:39 UTC
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...
Comment 10 Jesse Barnes 2009-10-05 10:42:03 UTC
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).
Comment 11 Dark Shadow 2009-10-05 13:03:25 UTC
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.