Andrei F (andrei.delete@this.anandtech.com) on September 14, 2021 8:55 am wrote:
> 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.

You are right that no matter how fast the frequency goes up, you can't get to 100 % immediately. But there's a big difference whether you can go from 10 % to 20 % or 40 %.

I'm not trying to say anything about relative importance of good DVFS compared to scheduler or what the situation was ten years ago, but it's frankly weird to try to paint it as something that doesn't matter at all. Not all loads are predictable.

-JLarja