Bug 23767

FBC is enabled on UMS mode. This issue only happens on KMS mode.

Support added:

commit 8082400327d8d2ca54254b593644942bed0edd25
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Sep 10 15:28:06 2009 -0700

    drm/i915: framebuffer compression for pre-GM45

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

Created attachment 30598 [details]
Dmesg file 

FBC is still disabled on 945GM and 915GM. please see attached dmesg file. So reopen this bug.

reopen this bug

The logs indicate FBC was disabled for a valid reason: the front buffer wasn't tiled.  It may work if you run X with a tiled front buffer, but only if there's enough stolen space to for the compressed buffer.

The question is why "framebuffer not tiled" under KMS but it doesn't have this issue under UMS with the same machine. Shall we file a separate bug to track it?

Or any suggestion how we could have more stolen memory to get tile/KMS working?

(In reply to comment #7)
> The question is why "framebuffer not tiled" under KMS but it doesn't have this
> issue under UMS with the same machine. Shall we file a separate bug to track
> it?

No, the fbcon framebuffer isn't supposed to be tiled (that would take a lot more memory), so that part isn't a bug.  If you start X with tiling enabled and see that FBC is disabled though you should file a bug.

> Or any suggestion how we could have more stolen memory to get tile/KMS working?

Sometimes the BIOS provides an option for controlling the stolen memory size.  In those cases you can adjust it appropriately.  If there's no BIOS control you're out of luck if your compressed frame buffer isn't big enough.

hi, Jesse, I start X with tiling enabled and see that FBC is disabled(you can see attached Xorg.log). should I file a bug?

It's the dmesg that should indicate whether it's enabled or not, if there's still an X log message for it then it's probably a left over from the UMS version and so it's inaccurate anyway.

We can not find tiling info in dmesg after start X, but we can see FBC is disabled in Xorg.log. So reopen this bug.

That message is gone in recent 2D drivers, so I don't see how you could see it?

What do you mean by recent?

With 2.9.1 I see in Xorg.0.log:
(***) intel(0): Kernel mode setting active, disabling FBC.
(***) intel(0): Framebuffer compression disabled
(***) intel(0): Tiling enabled
(***) intel(0): SwapBuffers wait enabled
 
that message seems to be in i830_driver.c, line 2604.

Post 2.9 drivers (e.g. the 2.10 snapshot and git) don't have that message.

I retest this problem on GM45, 945GM, 915GM and 965GM with unstable Kernel(drm-intel-next branch, 2.6.32-rc6_unstable). I see FBC disabled in dmesg:
[drm:i8xx_disable_fbc], disabled FBC
[drm:intel_crtc_mode_set], using SSC reference clock of 96 MHz
[drm:intel_crtc_mode_set], Mode for pipe B:
[drm:drm_mode_debug_printmodeline], Modeline 14:"1280x800" 60 71110 1280 1328 1360 1440 800 803 809 823 0x48 0xa
[drm:intel_pipe_set_base], Writing base 007DF000 00000000 0 0
[drm:intel_update_fbc], framebuffer not tiled, disabling compression
[drm:intel_update_fbc], unsupported config, disabling FBC
[drm:intel_update_fbc], framebuffer not tiled, disabling compression
[drm:intel_update_fbc], unsupported config, disabling FBC

I also see tiling enabled in Xorg.0.log.

By the way, if using stable Kernel, I can not find any FBC info in dmesg. 

Created attachment 31869 [details]
dmesg with drm.debug=0x06

Created attachment 31870 [details]
dmesg with drm.debug=0x06

Created attachment 31871 [details]
Xorg log

[drm:intel_pipe_set_base], Writing base 007DF000 00000000 0 0
[drm:intel_update_fbc], framebuffer not tiled, disabling compression
[drm:intel_update_fbc], unsupported config, disabling FBC
[drm:intel_update_fbc], framebuffer not tiled, disabling compression
[drm:intel_update_fbc], unsupported config, disabling FBC

Do these messages correspond to the X mode set or to the kernel's fbcon mode set?  If they're from fbcon, the "not tiled" is expected; we don't use tiling for the fb console.  Since X uses a tiled buffer, I'd expect later messages to indicate FBC was enabled, or if it wasn't, why (e.g. due to a compressed buffer that's too small).

These messages correspond to the X mode set.

Below are FBC registers reported by intel_gpu_dumper. FBC_CONTROL shows FBC is disabled.
        FBC_CFB_BASE: 0x5f800000
         FBC_LL_BASE: 0x3730f000
         FBC_CONTROL: 0x00000000
         FBC_COMMAND: 0x00000000
          FBC_STATUS: 0x20000000
        FBC_CONTROL2: 0x00000000
       FBC_FENCE_OFF: 0x00000000
         FBC_MOD_NUM: 0x00000000

This is 2.6.33-rc3 kernel on 945GM, in X mode (Xorg.0.log reports tiling enabled).

Sounds like X isn't tiling its front buffer object though; maybe it tries to enable it but fails later when the allocation actually occurs.  Performance should be really bad if tiling can't be used, does the kernel send any messages indicating that tiling can't be enabled?

Created attachment 32864 [details]
dmesg with drm.debug=0x06, 2.6.33-rc5, 945GM

this should be the reason:

[drm:intel_update_fbc], framebuffer too large, disabling compression

Full dmesg attached for the latest kernel, though the content seems similar to the previous one.

Ok, that's expected then.  If you don't have enough stolen space to handle the framebuffer, we can't enable FBC, which is too bad.

Closing old verified.