On 1 May 2010 17:42, Pedro Ribeiro <ped...@gmail.com> wrote: > On 1 May 2010 17:22, Jesse Barnes <jbar...@virtuousgeek.org> wrote: >> On Sat, 1 May 2010 01:01:12 +0100 >> Pedro Ribeiro <ped...@gmail.com> wrote: >> >>> On 1 May 2010 00:06, Jesse Barnes <jbar...@virtuousgeek.org> wrote: >>> > On Fri, 30 Apr 2010 13:04:23 +0100 >>> > Pedro Ribeiro <ped...@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 >
A follow-up: decided to revert "drm/i915: remove render reclock support" on 2.6.34-rc6 (only conflicts on chunk 3 but easily solvable) - I got at least 1w savings! This is impressive and I've done a few hibernate/thaw cycles as well as VT-switching and back to Xorg and no corruption at all (doing this on 2.6.32.5 with the patch reverted would cause corruption). I'm going to test it for a while to be sure, but it seems to be working pretty well. I'll keep you posted if it starts going nasty. Pedro _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
