Jukka Larja (roskakori2006.delete@this.gmail.com) on September 14, 2021 5:11 am wrote:
> Andrei F (andrei.delete@this.anandtech.com) on September 14, 2021 1:07 am wrote:
> > Jukka Larja (roskakori2006.delete@this.gmail.com) on September 13, 2021 6:35 am wrote:
> > > Andrei F (andrei.delete@this.anandtech.com) on September 13, 2021 2:02 am wrote:
> > >
> > > > The point is that your window of user experience is 16/8ms. If the workload completes
> > > > interactively to fill that "QoS" at the current frequency without going over a utilisation
> > > > threshold in that sliding window, you *do not want to go any higher*.
> > >
> > > Unfortunately this doesn't work well for e.g. games, since at any given time it's hard to know
> > > how much performance is required during next "window of use experience". It's often possible
> > > to know, that nothing needs to be done until next vsync (which may be nearly 16 ms away), but
> > > it's hard to know how much performance is needed during that next 16 ms interval.
> > >
> > > > So your 120MHz FIVR is completely and utterly pointless. You would be wasting energy at higher
> > > > voltages for no gain in user performance. Fmax should only every be reached and triggered after
> > > > continuous load of 2-3x of user experience window - current mobile phones do that in around 40-50ms,
> > > > anything faster than that is waste of energy and battery life. These are not HW limitations, but
> > > > learning the hard way what the most efficient way to design battery powered DVFS logic.
> > >
> > > We once ported a game to pretty standard Android system. The CPU should have been more than good enough,
> > > but there was huge stuttering and missed frames. Turned out
> > > that it was too slow to speed up, and too agressive
> > > (in comparison) to slow down. By running a background thread busily doing nothing on one core, we got much
> > > more stable FPS (final solution was more sensible, but nothing you could call elegant).
> > >
> > > -JLarja
> >
> > If this was several years ago, yes, some devices still shipped with naïve settings.
> > This has been pretty much solved now in terms of load tracking algorithms.
>
> The first problem (variable performance requirements) haven't though.
>
> -JLarja

If a thread does low load within a frame and then goes to 100% next frame then yes, there's nothing out there to avoid this and you'll skip a beat until the thread gets its load utilisation updated. Only stuff like preventative interaction boosters will help here.

If you however need to have a thread that only intermittently does work (i.e. it's allowed to idle), schedulers will remember the load of last work period and you'll immediately get boosted to the required perf state upon resuming/context switch.