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:
> It's not snarky, I'm really wondering if you've actually seen middle
> frequencies like this software is designed to do.  I spend a lot of time
> looking at performance, and whenever I look at RPS state, it's either at
> highest or lowest, or not working.  I've never seen a functioning
> workload that stays at the middle.  Testing with the hsw values
> reverted:

Lemme step back here a minute too, since some people have had strong
reactions to this proposal.

My underlying assumption here is that we're not executing with as much
power efficiency as we could.  This is more the case with apps (desktop
environments, non-gaming apps) that don't stress the GPU much, but may
also be true for some games we can run faster than 60fps.

In an ideal world, we'd run everything at the minimum frequency
required to get it to whatever target framerate it has (60fps for
games, 24fps or whatever for video, or some variable number for a
compositor that has intermittent activity).  We'd do that because even
though we take more time to draw a frame, keeping the frequency low is
more efficient from a power perspective, so over a given time period we
end up consuming fewer joules than if we "race to idle" at the highest
frequency.

Unfortunately, achieving that ideal is difficult.  Today's
implementation doesn't take into account any fps target, and uses some
sw programmed weight values to figure out when to trigger a frequency
increase or decrease.  The values we have today came from data
collection done with the Windows driver, which uses a different gfx
stack and has very different behavior from ours.  We should probably
tune them based on our own workloads, on a per-platform basis.

But given that we don't give the hw any information about when we need
things done or whether we're doing what we want to do, I thought we
might be able to do better with some additional sw assistance.

It's possible we could combine the proposal I sent out earlier (which
boils down to userspace telling the kernel whether it's getting the
performance it wants or not) with the hw-assisted mechanism, along with
some additional tuning, or we could do something else entirely.

Anyway, that's the background and I probably should have sent it out
first.

Jesse


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