Created attachment 29293 [details] Xorg log System Environment: -------------------------- Host: x-945gm Arch: i386 Platform: 945GM Libdrm: (master)121b9648f846d900e67818869974ee82046e9b25 Mesa: (master)9778731732b4753e79a1b786c65325a52392411d Xserver: (master)1747120043cc5b5d201b7efd06b75ef08b032922 Xf86_video_intel: (master)94fc93d4e2b88565dca17f72903d8991213c9ee8 Kernel_unstable: (drm-intel-next)01dfba93d9dfcf6d7abfc55ff5d9d6e76fa01ba0 Bug detailed description: ------------------------- FBC disabled on 945GM. Please see attached Xorg.0.log. Reproduce steps ---------------- 1. xinit &
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.
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.