From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Rannaud Subject: Re: i915: Regression: +4W in idle power use on Macbook Pro 15 (late 2013) Date: Tue, 26 Aug 2014 16:00:51 -0700 Message-ID: References: <87vbpglvmu.fsf@intel.com> <87sikklvhu.fsf@intel.com> <20140826110604.GI4193@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by gabe.freedesktop.org (Postfix) with ESMTP id 1DF156E137 for ; Tue, 26 Aug 2014 16:00:52 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x48so15454423wes.33 for ; Tue, 26 Aug 2014 16:00:52 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: Jani Nikula , Jon Kristensen , "intel-gfx@lists.freedesktop.org" , Greg Kroah-Hartman List-Id: intel-gfx@lists.freedesktop.org On Tue, Aug 26, 2014 at 1:59 PM, Daniel Vetter wrote: >> Forcing FBC with i915.enable_fbc=1 brings the idle power consumption >> back to under 7W, however. >> This is all on 3.15.4-ARCH-00041-gf4db98240ac2. > > Any significant changes in package C state as reported in powertop? > Indeed fairly impressive how much fbc saves here ... Not that I can tell. Powertop report with FBC: http://pastebin.com/5qfJKpTQ Without FBC: http://pastebin.com/NaYkR4n0 Some highly uneducated guesses on what could explain a +4W jump with no FBC: #1- The higher DRAM and bus duty cycle during scanout is enough to prevent some DRAM subsystems from sleeping, by crossing some tight threshold (maybe Apple has FBC enabled, so parameters somewhere in firmware are tuned for the lower level of background activity they expect with FBC on?). Not much we can do about that, unless such parameters can be tweaked by us. #2- Without FBC, the FB doesn't fit in L3 (i7-4750HQ has 6MB, 2880x1800 compressed at least 1:4 fits), keeping the DRAM awake more. #3- Disabling FBC somehow affects the layout of the framebuffer in DRAM, keeping more of the DRAM active and awake during scanout. Different tiling, swizzling, etc. parameters? Is it worth looking at the code for that kind of thing? To be clear, I'm (blindly) suggesting that it might be possible to increase the locality of the framebuffer in physical DRAM, even without compression enabled. Actually, with an image of white-noise displayed fullscreen while powertop takes a 20 second measurement, the idle power consumption shoots up to 11W, with FBC enabled. This experiment actually invalidates my guess #3. The white noise image will not compress much at all, while my typical test screen is a couple of static black-and-white terminal windows (filling up the screen), which will compress well. So it would appear 4W is the actual cost of having a full-size 20MB framebuffer on this system. Anything an outsider can do to help getting FBC enabled by default again? Thanks, Eric