[Intel-gfx] Framebuffer compression on GM45 disabled with KMS

Pedro Ribeiro pedrib at gmail.com
Sat May 1 18:42:58 CEST 2010


On 1 May 2010 17:22, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> On Sat, 1 May 2010 01:01:12 +0100
> Pedro Ribeiro <pedrib at gmail.com> wrote:
>
>> On 1 May 2010 00:06, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
>> > On Fri, 30 Apr 2010 13:04:23 +0100
>> > Pedro Ribeiro <pedrib at gmail.com> wrote:
>> >
>> >> Hi all,
>> >>
>> >> My Xorg.log shows
>> >>
>> >> (**) intel(0): Kernel mode setting active, disabling FBC.
>> >> (**) intel(0): Framebuffer compression disabled
>> >>
>> >> Is this normal? I'm trying to lower power consumption for my
>> >> laptop... Enabling FBC should do it?
>> >>
>> >> I have
>> >> fbpercrtc=0
>> >> modeset=1
>> >> powersave=1
>> >> lvds_downclock=1
>> >> enabled on the i915 module.
>> >
>> > It's just a stale message, I'll remove it.  FBC will be enabled by
>> > your kernel if possible (you can check /sys/kernel/debug/dri/0/ for
>> > status info if you have debugfs mounted).
>> >
>> > Jesse
>> >
>>
>> Thanks for the heads up, actually measuring the power consumption
>> between KMS and UMS with FBC enabled it seems that KMS wins by a very
>> slim margin.
>>
>> Its a great job you guys are doing with this driver!
>> I see it improve steadily on every kernel release. The only things I
>> still miss is the render reclock support which was removed in 2.6.32.4
>> - it worked wonderfully in my machine, reducing power consumption by
>> 2w when idle; and multiple ring buffer support(for libva H.264) which
>> seems to be coming in the Q3 this year :-)
>
> 2W!!?  If so it would be worth resurrecting for you in the form of a
> boot option or something.  The main problem is that it's not very
> general; may chips will lock up when we try to reclock them this way.
> But enabling it by force on specific machines is probably ok.
>
> Jesse
>

Yes, the difference was that big with the monitor on DPMS off on my
X4500. Don't know if it is related to it, but that it was what I
observed. Overall, at least 1w with the computer sitting idle.

It was rock-solid till 2.6.32.4. I was annoyed when the patch got
removed and reversed the patch in 2.6.32.5 but it caused serious
graphic corruption and lockups. I haven't tried again in any of the
newer kernels (.33 or .34).

Regards,
Pedro



More information about the Intel-gfx mailing list