Bug 13418 - Image on VGA screen stutters with framebuffer compression
Summary: Image on VGA screen stutters with framebuffer compression
Status: RESOLVED DUPLICATE of bug 13326
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: 7.3 (2007.09)
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Jesse Barnes
QA Contact: Xorg Project Team
Depends on:
Blocks: 15000
  Show dependency treegraph
Reported: 2007-11-28 03:08 UTC by Guillaume Melquiond
Modified: 2008-04-08 17:51 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Log with mode debug and framebuffer compression enabled (72.45 KB, text/x-log)
2007-11-28 05:34 UTC, Guillaume Melquiond
no flags Details
Program y offset of framebuffer for FBC (1.59 KB, text/x-diff)
2007-12-11 14:30 UTC, Jesse Barnes
no flags Details
Log for 2.2.90+ with fb compression enabled (64.29 KB, text/x-log)
2008-02-08 15:20 UTC, Guillaume Melquiond
no flags Details
Adjust FBC memory interface behavior (574 bytes, patch)
2008-02-19 17:47 UTC, Jesse Barnes
no flags Details | Splinter Review
Don't touch 965 FBC regs on !965 (1.46 KB, patch)
2008-02-21 09:57 UTC, Jesse Barnes
no flags Details | Splinter Review
LVDS is on pipe B which is connected to plane B (64.92 KB, text/plain)
2008-03-19 00:24 UTC, Guillaume Melquiond
no flags Details
LVDS is on pipe B, which is connected to plane B, when frmabuffer compression is enabled (64.68 KB, text/x-log)
2008-03-20 00:58 UTC, Guillaume Melquiond
no flags Details

Description Guillaume Melquiond 2007-11-28 03:08:06 UTC
The laptop is a Dell D620, the screen is a Dell 2007 FP, and they are linked by a VGA cable. The chipset is a 945GM. Video mode is:

  1600x1200 (0x5f)  162.0MHz +HSync +VSync
        h: width  1600 start 1664 end 1856 total 2160 skew    0 clock   75.0KHz
        v: height 1200 start 1201 end 1204 total 1250           clock   60.0Hz

Every few seconds, the synchronization is lost (?) and the frame seems to be displayed at a different position horizontally.

As suggested by Julien Cristau, disabling the framebuffer compression stabilizes the image and fixes this issue. The driver version is the one in the Debian package 2.2.0-1.
Comment 1 Guillaume Melquiond 2007-11-28 05:34:54 UTC
Created attachment 12775 [details]
Log with mode debug and framebuffer compression enabled

In case it helps, here is the diff between the logs of an enabled compression and a disabled one:

@@ -976,7 +977,7 @@
 (II) intel(0): X context handle = 0x1
 (II) intel(0): [drm] installed DRM signal handler
 (==) intel(0): VideoRam: 262144 KB
-(**) intel(0): Framebuffer compression enabled
+(**) intel(0): Framebuffer compression disabled
 (**) intel(0): Tiling enabled
 (II) intel(0): Attempting memory allocation with tiled buffers.
 (II) intel(0): Success.
@@ -1026,14 +1027,10 @@
 (II) intel(0): xf86BindGARTMemory: bind key 4 at 0x07000000 (pgoffset 28672)
 (II) intel(0): Fixed memory allocation layout:
 (II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
-(II) intel(0): 0x00020000-0x0061ffff: compressed frame buffer (6144 kB, 0x000000007f820000 physical
+(II) intel(0): 0x00020000-0x00029fff: HW cursors (40 kB, 0x000000007f820000 physical
-(II) intel(0): 0x00620000-0x00620fff: compressed ll buffer (4 kB, 0x000000007fe20000 physical
-(II) intel(0): 0x00621000-0x0062afff: HW cursors (40 kB, 0x000000007fe21000 physical
-(II) intel(0): 0x0062b000-0x00632fff: logical 3D context (32 kB)
-(II) intel(0): 0x00633000-0x00633fff: overlay registers (4 kB, 0x000000007fe33000 physical
+(II) intel(0): 0x0002a000-0x00031fff: logical 3D context (32 kB)
+(II) intel(0): 0x00032000-0x00032fff: overlay registers (4 kB, 0x000000007f832000 physical
 (II) intel(0): 0x007bf000:            end of stolen memory
 (II) intel(0): 0x01000000-0x01ffffff: front buffer (16384 kB) X tiled
@@ -1049,14 +1046,9 @@
 (II) intel(0): SDVO: R:                         (Success)
 (II) intel(0): SDVO: W: 05 00 00                   (SDVO_CMD_SET_ACTIVE_OUTPUTS)
 (II) intel(0): SDVO: R:                         (Success)
-(II) intel(0): fbc disabled on plane a
-(II) intel(0): fbc disabled on plane a
-(II) intel(0): fbc disabled on plane a
 (II) intel(0): Mode for pipe A:
 (II) intel(0): Modeline "1600x1200"x60.0  162.00  1600 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
 chosen: dotclock 161828 vco 1618285 ((m 118, m1 20, m2 6), n 5, (p 10, p1 1, p2 10))
-(II) intel(0): fbc enabled on plane a
-(WW) intel(0): fbc already enabled on plane a, not enabling on plane a
 (II) intel(0): Mode for pipe B:
 (II) intel(0): Modeline "1440x900"x60.0   95.44  1440 1504 1536 1744  900 903 906 912 -hsync -vsync (54.7 kHz)
 chosen: dotclock 95142 vco 2664000 ((m 111, m1 18, m2 9), n 2, (p 28, p1 4, p2 7))
@@ -1102,9 +1094,9 @@
 (II) intel(0):          DSPATILEOFF: 0x00000000
 (II) intel(0):            PIPEACONF: 0x80000000 (enabled, single-wide)
 (II) intel(0):             PIPEASRC: 0x063f04af (1600, 1200)
-(II) intel(0):         FBC_CFB_BASE: 0x7f820000
-(II) intel(0):          FBC_LL_BASE: 0x7fe20006
-(II) intel(0):          FBC_CONTROL: 0xc3e847e0
+(II) intel(0):         FBC_CFB_BASE: 0x00000000
+(II) intel(0):          FBC_LL_BASE: 0x00000000
+(II) intel(0):          FBC_CONTROL: 0x00000000
 (II) intel(0):          FBC_COMMAND: 0x00000000
 (II) intel(0):           FBC_STATUS: 0x20000000
 (II) intel(0):         FBC_CONTROL2: 0x00000000
@@ -1353,4 +1345,3 @@
 (II) Configured Mouse: ps2EnableDataReporting: succeeded
 Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
 Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list!
-(WW) intel(0): fbc already enabled on plane a, not enabling on plane a
Comment 2 Jesse Barnes 2007-12-11 14:30:32 UTC
Created attachment 13041 [details]
Program y offset of framebuffer for FBC

Hm, I wonder if in your configuration we need to program the Y offset of the framebuffer.  Not doing this is a bug regardless, but maybe this'll help your situation.
Comment 3 Guillaume Melquiond 2007-12-13 03:08:22 UTC
It seems like this patch did the trick. The image on external VGA is now stable when compression is enabled.
Comment 4 Guillaume Melquiond 2007-12-13 06:14:30 UTC
Sorry for the earlier message, I had only tested with a VGA display (and I usually turn off the LVDS when I do), so all seemed fine. But now I also tested with the LVDS (and no VGA) and the situation is in fact no better. With the patch, it is the LVDS display that stutters when compression is enabled. Please do not apply.
Comment 5 Jesse Barnes 2007-12-13 10:55:59 UTC
Just to confirm, you're seeing flickering on both the VGA and LVDS outputs, even when only one of them is enabled?

Also, can you time the flickering?  I wonder if it occurs every ~15s... if so that would almost surely be the FBC re-compress event.

Does the flickering stop after a short time and the display return to normal?  Or once corrupt does it stay corrupt?
Comment 6 Guillaume Melquiond 2007-12-13 12:58:43 UTC
Let me summarize what I experience when compression is enabled:

- without the patch, no VGA display: the LVDS output is fine

- without the patch, LVDS is off and a VGA display is connected: the VGA output flickers several times per minute, but only for a split second; the display is fine otherwise; my initial thought was that there was a glitch in the hardware that occurred while the framebuffer is being compressed, so this behavior is compatible with your "FBC re-compress event" hypothesis

- with the patch, LVDS is off and a VGA display is connected: the VGA output is fine (but perhaps I did not experiment for long enough, see below)

- with the patch, no VGA display: the LVDS flickers similarly to the VGA way above, but it happens rarely: only three times while using the computer for one hour

So there is a noticeable improvement with the patch for the VGA output, since there is no longer a flicker every few seconds. But it broke something with respect to the LVDS.
Comment 7 Guillaume Melquiond 2007-12-14 00:25:42 UTC
Here is another event that just occurred with the LVDS and framebuffer compression. Since it never occurred before, it may be related to the patch too. The display suddenly got blank. Switching VT worked fine and I could read and use the text consoles (pure text consoles, no fb, if that matters). Restarting the X server did not help, the display was blank again once in graphical mode. I had to reboot the laptop in order to get back a visible X.
Comment 8 Guillaume Melquiond 2007-12-24 00:16:54 UTC
Since then, I have been working with and without framebuffer compression. So I can now confirm that the display going blank is caused by patch+fbc. I can also confirm that VGA display does not suffer from the issues the patch introduced for LVDS display. As a consequence, while it fixed VGA display, the patch severely broke LVDS display. Perhaps some other graphic register should have been written along the one in the patch?
Comment 9 Benjamin Close 2008-01-11 02:38:47 UTC
Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler
Comment 10 Jesse Barnes 2008-02-05 14:12:00 UTC
Just pushed some FBC stuff that will hopefully fix this.  Care to retest?
Comment 11 Guillaume Melquiond 2008-02-08 00:32:34 UTC
This is still as bad as before. However, it seemed to work at first: When I installed the new driver, I didn't reboot the computer, I just restarted X, and the LVDS display was fine. Or at least I think it was.

So I have made a log diff between the possibly-stable display (-) and the certainly-unstable display (+), both with the new driver and the framebuffer compression. It may give you a clue with what goes wrong with the hardware, in case all these ARxx values are relevant.

@@ -20,7 +20,7 @@
 Markers: (--) probed, (**) from config file, (==) default setting,
 	(++) from command line, (!!) notice, (II) informational,
 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Thu Feb  7 20:52:02 2008
+(==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb  8 09:15:24 2008
 (==) Using config file: "/etc/X11/xorg.conf"
 (==) ServerLayout "Default Layout"
 (**) |-->Screen "Default Screen" (0)
@@ -442,7 +442,7 @@
 (II) intel(0):      PFIT_PGM_RATIOS: 0x00000000
 (II) intel(0):      PORT_HOTPLUG_EN: 0x00000020
 (II) intel(0):    PORT_HOTPLUG_STAT: 0x00000400
-(II) intel(0):             DSPACNTR: 0x59000000 (disabled, pipe B)
+(II) intel(0):             DSPACNTR: 0x00000000 (disabled, pipe A)
 (II) intel(0):           DSPASTRIDE: 0x00000000 (0 bytes)
 (II) intel(0):              DSPAPOS: 0x00000000 (0, 0)
 (II) intel(0):             DSPASIZE: 0x00000000 (1, 1)
@@ -539,7 +539,7 @@
 (II) intel(0):                 SR06: 0x00
 (II) intel(0):                 SR07: 0x00
 (II) intel(0):                  MSR: 0x67
-(II) intel(0):                  ARX: 0x30
+(II) intel(0):                  ARX: 0x33
 (II) intel(0):                 AR00: 0x00
 (II) intel(0):                 AR01: 0x01
 (II) intel(0):                 AR02: 0x02
@@ -556,7 +556,7 @@
 (II) intel(0):                 AR0d: 0x0d
 (II) intel(0):                 AR0e: 0x0e
 (II) intel(0):                 AR0f: 0x0f
-(II) intel(0):                 AR10: 0x20
+(II) intel(0):                 AR10: 0x0c
 (II) intel(0):                 AR11: 0x00
 (II) intel(0):                 AR12: 0x0f
 (II) intel(0):                 AR13: 0x08
@@ -807,6 +807,9 @@
 (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd0000009
 (WW) intel(0): PP_STATUS before: on, ready, sequencing idle
 (WW) intel(0): PP_STATUS after: on, ready, sequencing on
+(WW) intel(0): Register 0x70180 (DSPACNTR) changed from 0x00000000 to 0x58000000
+(WW) intel(0): DSPACNTR before: disabled, pipe A
+(WW) intel(0): DSPACNTR after: disabled, pipe A
 (==) Depth 24 pixmap format is 32 bpp
 (II) do I need RAC?  No, I don't.
 (II) resource ranges after preInit:
@@ -847,14 +850,19 @@
 (II) intel(0): Kernel reported 488960 total, 1 used
 (II) intel(0): I830CheckAvailableMemory: 1955836 kB available
 drmOpenDevice: node name is /dev/dri/card0
-drmOpenDevice: open result is 8, (OK)
+drmOpenDevice: open result is -1, (No such device or address)
+drmOpenDevice: open result is -1, (No such device or address)
+drmOpenDevice: Open failed
 drmOpenDevice: node name is /dev/dri/card0
-drmOpenDevice: open result is 8, (OK)
+drmOpenDevice: open result is -1, (No such device or address)
+drmOpenDevice: open result is -1, (No such device or address)
+drmOpenDevice: Open failed
 drmOpenByBusid: Searching for BusID pci:0000:00:02.0
 drmOpenDevice: node name is /dev/dri/card0
 drmOpenDevice: open result is 8, (OK)
 drmOpenByBusid: drmOpenMinor returns 8
 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
+(II) [drm] loaded kernel module for "i915" driver.
 (II) [drm] DRM interface version 1.3
 (II) [drm] DRM open master succeeded.
 (II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
@@ -1092,10 +1100,10 @@
 (II) intel(0):                 AR0d: 0x0d
 (II) intel(0):                 AR0e: 0x0e
 (II) intel(0):                 AR0f: 0x0f
-(II) intel(0):                 AR10: 0x20
+(II) intel(0):                 AR10: 0x00
 (II) intel(0):                 AR11: 0x00
 (II) intel(0):                 AR12: 0x0f
-(II) intel(0):                 AR13: 0x08
+(II) intel(0):                 AR13: 0x00
 (II) intel(0):                 AR14: 0x00
 (II) intel(0):                 CR00: 0x5f
 (II) intel(0):                 CR01: 0x4f
Comment 12 Jesse Barnes 2008-02-08 09:37:22 UTC
Guillaume, can you please attach the full X log (with modedebug enabled) from running with the latest git tip?  It has some register dumps I'd like to look at...
Comment 13 Guillaume Melquiond 2008-02-08 15:20:53 UTC
Created attachment 14225 [details]
Log for 2.2.90+ with fb compression enabled

Here is the log. In case it is the register you are interested in (since it is the only new one, as far as I can tell), the CACHE_MODE_0 value is 0x00006820.
Comment 14 Jesse Barnes 2008-02-19 17:47:22 UTC
Created attachment 14431 [details] [review]
Adjust FBC memory interface behavior

I wonder if this patch makes any difference at all?  It just changes the way FBC blocks memory traffic, hopefully making things a little better.
Comment 15 Guillaume Melquiond 2008-02-21 01:34:52 UTC
I would be happy to post that I didn't experience any stutter with the patch. But I have the feeling that I did not experiment anything actually. In my logs, except for the second dump (the one after the start of X), all the FBC registers are about 0. I would have expected only half of the dumps to be 0 (for VT) and the other ones to be non-zero (for X). Could it be that X fails to restore the framebuffer compression when I switch back from VT to X? How can I be sure that compression is enabled at a given time?
Comment 16 Guillaume Melquiond 2008-02-21 05:29:01 UTC
I don't know yet about LVDS display, since I need more testing. But I can already tell that the bug is back for VGA displays. It seems to occur less quickly than before, since I need to let the computer idle for 30 seconds / 1 minute before it happens.

As a matter of fact, I am no longer sure the bug really disappeared after your first patch, since I have yet to understand when framebuffer compression is enabled. For instance, this time, X started with framebuffer compression disabled (perhaps because I had enabled both LVDS and VGA?), but the screensaver restored it later on when it kicked out.
Comment 17 Jesse Barnes 2008-02-21 08:49:10 UTC
Yeah, it should automatically get disabled if you have more than one pipe running.  If only one pipe is active (like if the VGA has been shut off by DPMS but LVDS is still active) then it should turn back on.

So are you running with both LVDS and VGA enabled?  If you don't see the problem in that configuration, that's good.  If you see it only after one display has been disabled, then we still have a problem...
Comment 18 Guillaume Melquiond 2008-02-21 09:06:57 UTC
I almost never run X with both displays at once, so I cannot tell for sure if it works or not. But I guess it does, especially since you just confirmed that framebuffer compression is disabled when both pipes are active.

Since it does not seem clear, I will try to describe more precisely my setting. I have an external screen connected to my laptop, so at the start of X, both pipes (A is VGA, B is LVDS) are enabled and framebuffer compression is disabled. Then I disable LVDS (with xrandr). As far as I can tell from the logs, both pipes still seem to be enabled (is that a bug or my misunderstanding?). Later on, DPMS kicks in and powers off the VGA display. Then, when the VGA display is brought back, only the VGA pipe is enabled and framebuffer compression starts. And the stutter starts too.
Comment 19 Jesse Barnes 2008-02-21 09:55:22 UTC
Thanks for clearing things up, the scenario you describe makes sensee, though when you use 'xrandr' to turn off a display, the corresponding pipe should also get disabled.
Comment 20 Jesse Barnes 2008-02-21 09:57:26 UTC
Created attachment 14483 [details] [review]
Don't touch 965 FBC regs on !965

I'm running out of possibilities here.  Can you give this patch a try?  It won't touch registers it shouldn't on pre-965 chips.  If those regs exist but have different layouts on previous generations, writing them could be harmful.
Comment 21 Guillaume Melquiond 2008-02-22 02:22:42 UTC
No, it doesn't help, the LVDS display is stable, but the VGA display is not. Since your first patch of touching the FENCE_OFF register seemed to help (as far as I remember), I will later experiment with writing to it, but not writing to CONTROL2 as per your latest patch suggestion.

As a side remark, I have found a way to forcefully enable or disable compression, so testing should now be a lot easier (but I don't have time right now). To disable framebuffer compression, enable the other pipe a few seconds. To enable back compression, switch to VT.
Comment 22 Guillaume Melquiond 2008-02-25 00:36:16 UTC
Once again I thought it was working, but then I noticed that pipe B (LVDS) was connected to plane B, so framebuffer compression was not enabled. (This probably explains comment #15.)

Is there a way to manually connect pipe B to plane A, so that I can actually test the patches?
Comment 23 Jesse Barnes 2008-03-18 18:24:29 UTC
Hm, the pipe/plane swap should occur at startup... can you attach logs from when the swap seems to be failing?
Comment 24 Guillaume Melquiond 2008-03-19 00:24:28 UTC
Created attachment 15290 [details]
LVDS is on pipe B which is connected to plane B

I have attached my current log, which has pipe B connected to plane B. Framebuffer compression is disabled in my configuration, but it should not be relevant to the choice of planes (?).
Comment 25 Jesse Barnes 2008-03-19 09:11:29 UTC
Actually, it is.  Normally pipe a maps to plane a and pipe b to plane b.  However, on pre-965 chips, framebuffer compression only works on plane a and LVDS only works on pipe b, so we have to switch the pipe/plane mappings when framebuffer compression is enabled.  So if you change your config to enable framebuffer compression, you should see a message saying that the mappings were changed to support it.

But I'm starting to think this problem may be only partially related to fbc...
Comment 26 Guillaume Melquiond 2008-03-20 00:58:39 UTC
Created attachment 15328 [details]
LVDS is on pipe B, which is connected to plane B, when frmabuffer compression is enabled
Comment 27 Guillaume Melquiond 2008-03-20 01:01:33 UTC
Just to be sure my memory wasn't playing tricks on me, I enabled back framebuffer compression. So I can now confirm it does not change the mapping: LVDS is still connected to the non-compressed plane.
Comment 28 Jesse Barnes 2008-03-28 13:44:20 UTC
Ok, thanks Guillame, according to your log, fbc isn't getting enabled on plane A after things come up because the pipe/plane mappings weren't actually swapped, maybe due to an old DRM?

In your old logs, we were enabling FBC on the VGA pipe, since it was sitting on plane A, but we were also running pipe B/plane B for the LVDS, which is what I thought was causing the flicker.

So can you try updating your DRM so that the pipes & planes will get swapped (you should see "adjusting pipe->plane mappings" in your log) to see if the problem still occurs?  It may be that the patch to disable FBC if two pipes were active fixed the problem...
Comment 29 Jesse Barnes 2008-03-28 13:45:55 UTC
This might be a DUP of 13326 too
Comment 30 Guillaume Melquiond 2008-03-28 14:31:19 UTC
The version of the linux kernel on the laptop is 2.6.24, so the DRM code should not be that old (?). Anyway, I will try to get and install a newer version.

In the meantime, please notice that, in the logs from 2008-02-08, the planes are correctly swapped: "Display plane A is now enabled and connected to pipe B." So there was a time when planes were correctly setup.

I have read the comments of bug #13326 and this does indeed look quite similar. While I have not experienced all the described symptoms (e.g. my VGA display never spuriously blanked), I wouldn't be surprised if this was the same underlying issue.
Comment 31 Jesse Barnes 2008-03-28 14:47:49 UTC
Yeah, somehow the log from 2/8 shows that the adjustment occurred, but the most recent log doesn't.  And since you didn't have a VGA display connected, FBC was disabled on plane a...

It looks like 2.6.24 didn't have the swapped pipe/plane vblank fixes, so that would explain why the driver isn't adjusting them in your more recent logs.
Comment 32 Guillaume Melquiond 2008-04-02 02:38:30 UTC
I haven't had a chance to replace the DRM module from my kernel yet, but I would like to clear a potential misunderstanding (?) from comment 28: The disabling of FBC when two pipes are active does not fix the issue. Indeed, when LVDS is off and VGA is on (remember that the VGA pipe is currently on plane A), the image still stutters. As a consequence, unless the most recent DRM ensures that the VGA pipe is never on plane A (even when it is the only active pipe), the bug will still occur.
Comment 33 Jesse Barnes 2008-04-08 17:51:21 UTC
Pretty sure this is a DUP

*** This bug has been marked as a duplicate of bug 13326 ***

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.