Bug 33487

xterm is not the only way to reproduce, but by far the easiest. Most toolkits don't seem to have this issue, so render is probably working fine.

Matthias, since -rc2 was a whirlwind release we didn't get the FBC blitter fix in. It's upstream now:

commit 4efe070896e1f7373c98a13713e659d1f5dee52a
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Jan 18 11:25:41 2011 -0800

    drm/i915: make the blitter report buffer modifications to the FBC unit
    
    Without this change, blits to the front buffer won't invalidate FBC
    state, causing us to scan out stale data.  Make sure we update these
    bits on every FBC enable, since they may get clobbered if we shut off
    the display.
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=26932
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

This also happens with e53160b, which contains 4efe070.

I don't have an e53160b.

Sorry, was a local uncorrelated commit. I meant latest Linus' master, c723fda.

Jesse, you have a laptop, can you reproduce?

Created attachment 42539 [details] [review]
magic wm0 values

I wonder if it has anything to do with this patch? I have to apply this on my desktop to prevent random hangs despite the specs implying otherwise...

*** Bug 34433 has been marked as a duplicate of this bug. ***

Damn, I'm not seeing this on my SNB laptop.

Mattias, can you try Chris's patch as well as the patch I posted to #34433?

Meng, can you try Chris's patch too?

(In reply to comment #9)
> Meng, can you try Chris's patch too?
Testin commit 710f957 with this patch((id=42539),the problem still exists

After change any mode(e.g. xrandr --output LVDS1 --mode 1366x768),it works fine.

(In reply to comment #11)
> After change any mode(e.g. xrandr --output LVDS1 --mode 1366x768),it works
> fine.

Just to clarify: after a mode change, updates continue to be immediately painted rather than the mode change causing the screen to be repainted?

(In reply to comment #12)
> Just to clarify: after a mode change, updates continue to be immediately
> painted rather than the mode change causing the screen to be repainted?

After a mode change,the bug does not exists.

> > After change any mode(e.g. xrandr --output LVDS1 --mode 1366x768),it works
> > fine.
> 
> Just to clarify: after a mode change, updates continue to be immediately
> painted rather than the mode change causing the screen to be repainted?

Hm, that might point to us not waiting for the requisite number of
vblanks between plane and fbc enable or something along those lines.

Created attachment 44487 [details] [review]
wait for vblank before enabling fbc

Does this patch help?  Before enabling FBC we're supposed to wait for a couple of vblanks for some reason...

(In reply to comment #15)
> Created an attachment (id=44487) [details]
> wait for vblank before enabling fbc
> Does this patch help?  Before enabling FBC we're supposed to wait for a couple
> of vblanks for some reason...

Testing in commit 47ae63e with this patch((id=44487),the problem still exists

Jesse, do you need any help from Shanghai?

I need a new theory about why this isn't working.  Apparently a full mode set (xrandr) will fix things, but simple vblank waits doesn't.

Btw does this bug still exist now that Chris's "redundant operations" patch for not double enabling the planes & pipes is in?

meng, could you help check the commit mentioned by Jesse in comment #18 (which is I think is the one fixed bug #34601)

(In reply to comment #18)
> Btw does this bug still exist now that Chris's "redundant operations" patch for
> not double enabling the planes & pipes is in?

Testing in commit 00d70b151(drm/i915: skip redundant operations whilst enabling pipes and planes),the problem still exists.

It would also be useful if you could confirm if fbc behaves correctly after a modeswitch.

(In reply to comment #21)
> It would also be useful if you could confirm if fbc behaves correctly after a
> modeswitch.

Could you please tell me how to confirm whether fbc behaves is correct afer a modeswitch?

On Thu, 31 Mar 2011 23:42:49 -0700 (PDT)
bugzilla-daemon@freedesktop.org wrote:

> https://bugs.freedesktop.org/show_bug.cgi?id=33487
> 
> --- Comment #22 from meng <mengmeng.meng@intel.com> 2011-03-31 23:42:49 PDT ---
> (In reply to comment #21)
> > It would also be useful if you could confirm if fbc behaves correctly after a
> > modeswitch.
> 
> Could you please tell me how to confirm whether fbc behaves is correct afer a
> modeswitch?

Ideally by measuring power consumption, but you can also check the FBC
enable files in sysfs and see if it's still enabled after the mode
switch.

(In reply to comment #23)

It's still enabled after the mode switch when testing in commit f0c860246.

I'm hitting this bug on a Samsung np900x3a running ubuntu natty, 2.6.38-8-generic #42-ubuntu x86_64.  Has it been fixed upstream?

This may have been fixed upstream with all the force wake changes, can someone with the problem confirm with a 3.0-rc kernel?  You'll have to explicitly enable FBC with a module param (redundantly named i915_enable_fbc, so i915.i915_enable_fbc=1 at the kernel boot line).

Please try this patch:

https://patchwork.kernel.org/patch/937372/

Without patch, the problem has been fixed on upstream.

System Environment:
--------------------------
Platform: HuronRiver
Kernel: (drm-intel-next)a7f08958d7ca69e26ec85fe49c0be3568a565493

(In reply to comment #28)
> Without patch, the problem has been fixed on upstream.
> 
> System Environment:
> --------------------------
> Platform: HuronRiver
> Kernel: (drm-intel-next)a7f08958d7ca69e26ec85fe49c0be3568a565493

Upsteam just disabled fbc...

Created attachment 48741 [details] [review]
Set persistent mode on FBC

Chris's latest patch has been reported to fix this for at least one machine. I'd love to hear from others who have experienced this issue whether this patch works for them as well so that we can close this bug and get the patch merged into the 3.0 kernel release.

(In reply to comment #30)
> Created an attachment (id=48741) [details]

After enable fbc and with above patch, the problem has been fixed.

System Environment:
--------------------------
Platform: HuronRiver
Kernel: (drm-intel-next)a7f08958d7ca69e26ec85fe49c0be3568a565493(enable fbc)

*** Bug 38964 has been marked as a duplicate of this bug. ***

Created attachment 48840 [details] [review]
Disable FBC upon page-flip

Hopefully this is the elephant-in-the-room...

Created attachment 48844 [details] [review]
Perform FBC re-enable from a delayed task

This is the second step. Instead of hitting the wait-for-vblank in the middle of page-flipping and so reducing application performance, we defer the re-enablement till 50ms afterward the last page-flip finishes.

Downgrading priority as FBC has been disabled in upstream kernels until we have a complete solution. Maybe the patches I've posted will be sufficient...

Hi,

I'm having some repaint issues on Ubuntu 11.04 on a Intel DH67BL mobo (i965 graphics chipset? see log snippet below), I thought it could be related to this bug. On my case it's specially noticeable with menus on SWT apps (eg. Eclipse IDE), they are usually (but not always) drawn partially until the mouse hovers over menu items. Other symptoms include "sticky SWT fragments": eg. Eclipse is running on desktop #1, when I switch to desktop #2 some fragments of Eclipse still appear on the screen until I force a repaint.

My environment is: GNOME 2 (I'm not using Unity), no desktop effects (compiz), 4 virtual desktops. AFAICS some of the driver components are outdated:

From Xorg.0.log:
[     8.230] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[     8.230] (II) Module intel: vendor="X.Org Foundation"
[     8.230]    compiled for 1.10.1, module version = 2.14.0
...
[     8.519] (II) intel(0): [DRI2]   DRI driver: i965
...
[     8.583] (II) AIGLX: Trying DRI driver /usr/lib/dri/i965_dri.so
[     8.585] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[     8.585] (II) AIGLX: enabled GLX_INTEL_swap_event
[     8.585] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[     8.585] (II) AIGLX: enabled GLX_SGI_make_current_read
[     8.585] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[     8.585] (II) AIGLX: Loaded and initialized i965
[     8.585] (II) GLX: Initialized DRI2 GL provider for screen 0

3D driver: 7.10.2

libdrm-intel1 2.4.23-1ubuntu6

kernel: 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

libva1 1.0.8-3

My questions are:

1. would i915.powersave=0 boot parameter help me? If not, is there any other configuration I could try to workaround this?
2. how can I try the latest stable driver versions on Ubuntu 11.04? Is there any installation instructions?

Please let me know if there's any additional info I can provide.

(In reply to comment #31)
> Chris's latest patch has been reported to fix this for at least one machine.
> I'd love to hear from others who have experienced this issue whether this patch
> works for them as well so that we can close this bug and get the patch merged
> into the 3.0 kernel release.

3.0 + the above patch has fixed it for me as well, without any special boot arguments.  Thanks!

yay for Chris!

Jesse says the patch has been committed. Can anyone verify with upstream kernel
(to be 3.1)?

(In reply to comment #40)
> Jesse says the patch has been committed. Can anyone verify with upstream kernel
> (to be 3.1)?

Did you mean the patch mentioned by Comment 30?

I didn't find it both on fixes and next branch.

A patch referencing this bug report has been merged in Linux v3.1-rc1:

commit 7782de3bd671657674e7baba854f0fd43e9f86bc
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 8 12:22:41 2011 +0100

    drm/i915: Disable FBC across page-flipping

A patch referencing this bug report has been merged in Linux v3.1-rc1:

commit 9ce9d0695d15da23ffe817516ba5d0b58caf8d05
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 8 12:22:40 2011 +0100

    drm/i915: Set persistent-mode for ILK/SNB framebuffer compression