Re: i915: Regression: +4W in idle power use on Macbook Pro 15 (late 2013)

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Tue, Aug 26, 2014 at 04:00:51PM -0700, Eric Rannaud wrote:
> On Tue, Aug 26, 2014 at 1:59 PM, Daniel Vetter <daniel.vetter@ffwll.ch> 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

Seems to have gotten messed up somehow. I can't see the package c-state
info there at all for some reason. Also core c-states go only up to c7s.
On hsw I would have expected to see deeper c-states, but maybe it's not
a ult machine or something. My hsw-ult goes up to c10.

> 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.

I guess the monster resolution just really hurts w/o fbc. My hsw has
1920x1080 panel which, assuming the same refresh rate, means your
display refresh requires 2.5x the bandwidth mine does. Sadly my hsw
seems to have a a dead battery so i can't check the power consumption
figures. pc7 residency definitely drops quite a bit on that machine if
I disable fbc. I don't remember if I ever measured the effect of fbc
on that thing before the battery died, but on my ivb it's definitely
somewhere in the .3W ballpark, though that machine has an even lower
resolution than the hsw.

> 
> Anything an outsider can do to help getting FBC enabled by default again?

Either someone needs to review my patches or fix the fbc code in
some other way. Even if someone wants to do the frontbuffer tracking
some other way, there was plenty of stuff in my patches that can
still be applied (there were even simple bugfixes included iirc).

-- 
Ville Syrjälä
Intel OTC