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.