Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Eric Anholt <eric@anholt.net>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: hsw rps values regress RPS on Macbook Air
Date: Tue, 16 Oct 2012 13:15:04 -0700	[thread overview]
Message-ID: <20121016131504.312b99ce@jbarnes-t420> (raw)
In-Reply-To: <87ehkynqm9.fsf@eliezer.anholt.net>

On Tue, 16 Oct 2012 12:50:22 -0700
Eric Anholt <eric@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

  reply	other threads:[~2012-10-16 20:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-09 20:05 hsw rps values regress RPS on Macbook Air Eric Anholt
2012-10-11 19:55 ` Jesse Barnes
2012-10-12 18:34   ` Eric Anholt
2012-10-16 13:53     ` Jesse Barnes
2012-10-16 14:38       ` Daniel Vetter
2012-10-16 14:53         ` Jesse Barnes
2012-10-16 19:50       ` Eric Anholt
2012-10-16 20:15         ` Jesse Barnes [this message]
2012-10-16 20:55         ` Jesse Barnes
2012-10-16 15:17 ` Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121016131504.312b99ce@jbarnes-t420 \
    --to=jbarnes@virtuousgeek.org \
    --cc=eric@anholt.net \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox