[Intel-gfx] hsw rps values regress RPS on Macbook Air

[Jesse Barnes]

On Fri, 12 Oct 2012 11:34:08 -0700
Eric Anholt <eric at anholt.net> wrote:

> Jesse Barnes <jbarnes at virtuousgeek.org> writes:
> 
> > On Tue, 09 Oct 2012 13:05:54 -0700
> > Eric Anholt <eric at anholt.net> wrote:
> >
> >> On my new MBA with danvet's drm-intel-next-queued, I'm not getting
> >> working RPS.  vblank_mode=0 glxgears never ups the frequency, and
> >> vblank_mode=0 openarena only makes it up to 500mhz.  Reverting
> >> 1ee9ae3244c4789f3184c5123f3b2d7e405b3f4c gets the machine to responsive
> >> RPS: fully on while the GPU is busy, fully lowered when it's not.
> >> 
> >> Since we're always just looking for all-on or all-off and never see
> >> workloads that actually want to be somewhere in between, could we please
> >> just move to race to idle for RPS?
> >
> > Ramping to the max freq is fine for benchmarking.  But for normal
> > vblank throttled activity, using the lowest freq (assuming it's
> > above our nominal freq) that can hit the refresh is the right answer
> > from a power perspective.
> 
> Have you seen any workloads where a middle frequency value is actually
> chosen by the current RPS system?

I can't tell if this is a snarky response or not. :)  But either way it
misses my point: I think the current RPS system isn't ideal for many of
our workloads and the way our GL stack runs things.  I've thought we
could do better for awhile now but couldn't think of a way that would
let userspace request lower frequencies if it didn't need the extra
processing power, but if we collect a little data in Mesa maybe we can
do it.

I propose a new ioctl, I915_FREQ_REQUEST, with 3 different parameters,
I915_MAX_FREQ, I915_MORE_FREQ, and I915_LESS_FREQ.  The first would
tell the kernel the app would like to run at the maximum possible
speed, regardless of power or throttling considerations.  MORE
would simply tell the kernel the app needs a higher frequency to meet
its frame rate target, and LESS would tell the kernel it could run
slower and still hit its target.

In Mesa, we'd need to track the FPS target for the app, the current FPS
(e.g. over the last second, or using a decaying average with some
weight toward recent activity), and the time between swapbuffers calls
(as an approximation of how long it takes us to draw each frame).

Periodically (maybe every second when we update our current FPS), Mesa
would either request more frequency if it wasn't hitting its FPS
target, or less frequency if its frame draw time was less than 90% of
the maximum alloted frame time (the period for the frequency we're
trying to hit).  The FPS target would be based on the swap interval for
the app.

In a benchmarking mode (i.e. vblank_mode=0 or swapinterval set to 0),
we could just make a I915_MAX_FREQ request and be done with it.

Within the kernel, we'd evaluate every app's requests and choose the
max frequency requested, re-setting things on every ioctl call and when
apps close.

Any thoughts?  Would collecting the above info in Mesa be pretty easy?
I think we already collect FPS info if certain debug flags are set, and
frame time seems like a pretty trivial calculation based on some
timestamping in a couple of places...

Thanks,
Jesse