hsw rps values regress RPS on Macbook Air

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 16 Oct 2012 12:50:22 -0700
Eric Anholt <eric at anholt.net> wrote:
> I'd like to replace "not working" with "high when busy, low when not",
> while you're saying that we have to support a middle frequency like the
> complicated software is trying to achieve.

Well I think this is pretty simple; much simpler than the underlying hw
system at least, and comparable to our sw support of it.

But for frequencies, you're correct.  We should run at the minimum
frequency we can that will still achieve our target framerate.

> Unfortunately, enough apps don't use swap interval, and instead of use
> SGI_video_sync or OML_sync_control.  In that case, we don't know the
> swap interval outside of a blocking call, unless we look at their
> history and try to guess.  It sounds ugly, and I guess we'd basically
> end up with I915_MAX_FREQ as our policy.

Don't all apps have a default swap interval at least?  If they're doing
additional blocking beyond that we'd lose the target fps information, I
agree.

> The design is also predicated on some bad assumptions.  One is that
> frame-to-frame workloads stay consistent.  3x difference in work between
> high and low-framerate scenes within an app I'd say is normal, and you'd
> need to be able to recognize that change and fix the frequency within
> half a second in the worst case I'd think.  Think about your compositor,
> too: right now it's updating a character at a time as I type, then I go
> hit the expose button and it has to redraw the whole screen and that's a
> waaay different workload.  I want responsiveness.

I don't want to assume constant work at all; I know scenes vary widely
in complexity over time.  If we timestamp the execution of buffers we
send in, we can do very fine grained requests if we notice they're
starting to take longer.

> The other bad assumption I think is that there's a bunch headroom for us
> to reduce the frequency.  Games are tuned to the hardware, to be able to
> barely hit 60fps -- if you're way over 60, then either the app turns on
> more pretty graphics options or you do.  You don't have a bunch of extra
> space to play with turning down the frequency.

Yeah, games are generally demanding.  But we also have desktops and
phone UIs that aren't, and those are pretty common cases too.

Jesse


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux