Bug 33487 - SandyBridge: Frame buffer compression doesn't always repaint
SandyBridge: Frame buffer compression doesn't always repaint
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Intel
unspecified
x86 (IA32) Linux (All)
: medium critical
Assigned To: Jesse Barnes
:
: 34433 38964 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-25 10:04 UTC by Matthias Hopf
Modified: 2011-08-08 01:52 UTC (History)
8 users (show)

See Also:


Attachments
magic wm0 values (1.50 KB, patch)
2011-01-26 09:50 UTC, Chris Wilson
no flags Details | Splinter Review
wait for vblank before enabling fbc (625 bytes, patch)
2011-03-15 14:00 UTC, Jesse Barnes
no flags Details | Splinter Review
Set persistent mode on FBC (2.53 KB, patch)
2011-07-04 05:34 UTC, Chris Wilson
no flags Details | Splinter Review
Disable FBC upon page-flip (1.88 KB, patch)
2011-07-06 23:58 UTC, Chris Wilson
no flags Details | Splinter Review
Perform FBC re-enable from a delayed task (9.18 KB, patch)
2011-07-07 02:28 UTC, Chris Wilson
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Hopf 2011-01-25 10:04:44 UTC
kernel: 2.6.38-rc2
xf86-video-intel 2.14.0


On SandyBridge mobile platform (internal reference: NUE874):

If booted with framebuffer compression active, xterm doesn't paint new characters during typing. Moving the window or deleting characters makes the already typed characters appear.

Booting with i915.powersave=0 doesn't show this behavior, so it's framebuffer compression that's biting us here. Presumably some render path doesn't update the compressed FB.
Comment 1 Matthias Hopf 2011-01-25 10:08:10 UTC
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.
Comment 2 Chris Wilson 2011-01-25 10:15:00 UTC
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>
Comment 3 Matthias Hopf 2011-01-25 10:34:48 UTC
This also happens with e53160b, which contains 4efe070.
Comment 4 Chris Wilson 2011-01-25 10:37:49 UTC
I don't have an e53160b.
Comment 5 Matthias Hopf 2011-01-25 11:04:21 UTC
Sorry, was a local uncorrelated commit. I meant latest Linus' master, c723fda.
Comment 6 Chris Wilson 2011-01-25 11:09:30 UTC
Jesse, you have a laptop, can you reproduce?
Comment 7 Chris Wilson 2011-01-26 09:50:26 UTC
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...
Comment 8 Chris Wilson 2011-02-24 09:35:16 UTC
*** Bug 34433 has been marked as a duplicate of this bug. ***
Comment 9 Jesse Barnes 2011-02-25 09:32:05 UTC
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?
Comment 10 meng 2011-02-27 00:42:11 UTC
(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
Comment 11 meng 2011-02-27 01:42:45 UTC
After change any mode(e.g. xrandr --output LVDS1 --mode 1366x768),it works fine.
Comment 12 Chris Wilson 2011-02-27 03:13:13 UTC
(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?
Comment 13 meng 2011-02-27 23:16:24 UTC
(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.
Comment 14 Jesse Barnes 2011-02-28 10:13:41 UTC
> > 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.
Comment 15 Jesse Barnes 2011-03-15 14:00:50 UTC
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...
Comment 16 meng 2011-03-15 20:06:40 UTC
(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
Comment 17 Gordon Jin 2011-03-23 18:50:33 UTC
Jesse, do you need any help from Shanghai?
Comment 18 Jesse Barnes 2011-03-24 09:27:35 UTC
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?
Comment 19 Shuang He 2011-03-27 19:16:22 UTC
meng, could you help check the commit mentioned by Jesse in comment #18 (which is I think is the one fixed bug #34601)
Comment 20 meng 2011-03-27 21:50:18 UTC
(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.
Comment 21 Chris Wilson 2011-03-27 23:31:37 UTC
It would also be useful if you could confirm if fbc behaves correctly after a modeswitch.
Comment 22 meng 2011-03-31 23:42:49 UTC
(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?
Comment 23 Jesse Barnes 2011-04-01 08:58:40 UTC
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.
Comment 24 meng 2011-04-01 18:46:29 UTC
(In reply to comment #23)

It's still enabled after the mode switch when testing in commit f0c860246.
Comment 25 Sage Weil 2011-06-01 20:46:45 UTC
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?
Comment 26 Jesse Barnes 2011-06-16 10:23:13 UTC
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).
Comment 27 Ben Widawsky 2011-07-01 12:50:39 UTC
Please try this patch:

https://patchwork.kernel.org/patch/937372/
Comment 28 meng 2011-07-03 20:13:02 UTC
Without patch, the problem has been fixed on upstream.

System Environment:
--------------------------
Platform: HuronRiver
Kernel: (drm-intel-next)a7f08958d7ca69e26ec85fe49c0be3568a565493
Comment 29 Chris Wilson 2011-07-04 05:25:44 UTC
(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...
Comment 30 Chris Wilson 2011-07-04 05:34:24 UTC
Created attachment 48741 [details] [review]
Set persistent mode on FBC
Comment 31 Keith Packard 2011-07-04 11:22:57 UTC
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.
Comment 32 meng 2011-07-04 21:33:24 UTC
(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)
Comment 33 Chris Wilson 2011-07-05 11:56:40 UTC
*** Bug 38964 has been marked as a duplicate of this bug. ***
Comment 34 Chris Wilson 2011-07-06 23:58:39 UTC
Created attachment 48840 [details] [review]
Disable FBC upon page-flip

Hopefully this is the elephant-in-the-room...
Comment 35 Chris Wilson 2011-07-07 02:28:40 UTC
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.
Comment 36 Chris Wilson 2011-07-08 03:02:32 UTC
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...
Comment 37 Andre Costa 2011-07-21 07:39:51 UTC
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.
Comment 38 Sage Weil 2011-07-24 20:50:56 UTC
(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!
Comment 39 Jesse Barnes 2011-07-28 17:40:10 UTC
yay for Chris!
Comment 40 Gordon Jin 2011-07-28 17:44:06 UTC
Jesse says the patch has been committed. Can anyone verify with upstream kernel
(to be 3.1)?
Comment 41 Yi Sun 2011-07-28 20:45:06 UTC
(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.
Comment 42 Florian Mickler 2011-08-08 01:50:58 UTC
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
Comment 43 Florian Mickler 2011-08-08 01:52:09 UTC
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