By: Andrei F (andrei.delete@this.anandtech.com), September 14, 2021 12:07 am
Room: Moderated Discussions
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.
> 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.
Topic | Posted By | Date |
---|---|---|
alder lake. | inteluser | 2021/09/10 01:52 AM |
alder lake. | Andrei F | 2021/09/10 09:31 AM |
alder lake. | Andrey | 2021/09/10 09:38 AM |
alder lake. | rwessel | 2021/09/10 11:18 AM |
alder lake. | Andrei F | 2021/09/10 12:49 PM |
alder lake. | Andrey | 2021/09/10 04:12 PM |
alder lake. | David Hess | 2021/09/10 07:39 PM |
alder lake. | Andrey | 2021/09/11 12:28 AM |
alder lake. | --- | 2021/09/10 05:24 PM |
alder lake. | Andrei F | 2021/09/12 01:09 AM |
DVFS | David Kanter | 2021/09/12 09:58 PM |
DVFS | Andrei F | 2021/09/13 01:02 AM |
DVFS | Anon | 2021/09/13 03:28 AM |
DVFS | Jukka Larja | 2021/09/13 05:35 AM |
DVFS | Andrei F | 2021/09/14 12:07 AM |
DVFS | Jukka Larja | 2021/09/14 04:11 AM |
DVFS | Andrei F | 2021/09/14 07:55 AM |
DVFS | Jukka Larja | 2021/09/14 10:23 AM |
DVFS | --- | 2021/09/13 10:19 AM |
DVFS | Doug S | 2021/09/13 10:57 AM |
DVFS | David Hess | 2021/09/13 11:32 AM |
DVFS | --- | 2021/09/13 01:06 PM |
DVFS | David Hess | 2021/09/13 02:21 PM |
DVFS | David Kanter | 2021/09/15 03:05 PM |
DVFS | David Hess | 2021/09/13 11:46 AM |
DVFS | Jukka Larja | 2021/09/14 04:35 AM |
Quick shutdown? | David Kanter | 2021/09/15 10:46 AM |
Quick shutdown? | Andrei F | 2021/09/16 07:12 AM |
Quick shutdown? | David Kanter | 2021/09/16 11:04 AM |
Quick shutdown? | Andrei F | 2021/09/17 01:35 AM |
Quick shutdown? | Andrei F | 2021/09/17 01:38 AM |
and weren't 'they' right? | Daniel B | 2021/09/13 04:20 AM |
and weren't 'they' right? | Andrei F | 2021/09/13 04:51 AM |
and weren't 'they' right? | Daniel B | 2021/09/13 06:29 AM |
and weren't 'they' right? | anon | 2021/09/13 05:07 AM |
and weren't 'they' right? | Jukka Larja | 2021/09/13 05:26 AM |
and weren't 'they' right? | anon | 2021/09/13 11:37 PM |
Alder Lake has no little cores | Heikki Kultala | 2021/09/13 06:33 AM |
Alder Lake has no little cores | Michael S | 2021/09/13 07:33 AM |
Alder Lake has no little cores | me | 2021/09/13 10:45 AM |
Alder Lake has no little cores | Heikki Kultala | 2021/09/13 01:49 PM |
Alder Lake has no little cores | anon | 2021/09/13 11:42 PM |
why stop at two core sizes? | hobold | 2021/09/14 05:47 AM |
Memory caches did this, right? | Mark Roulo | 2021/09/14 02:51 PM |
Memory caches did this, right? | Brett | 2021/09/14 07:17 PM |
Memory caches did this, right? | Kevin G | 2021/09/16 03:10 PM |
Large reorder buffers (L1+L2) | ⚛ | 2021/09/15 11:24 AM |
Large reorder buffers (L1+L2) | hobold | 2021/09/15 12:06 PM |
Alder Lake has no little cores | Adrian | 2021/09/14 08:33 AM |
and weren't 'they' right? | David Hess | 2021/09/13 12:00 PM |
Battery vs Performance | Mark Roulo | 2021/09/13 12:18 PM |
Battery vs Performance | Doug S | 2021/09/13 02:05 PM |
Battery vs Performance | David Hess | 2021/09/13 02:28 PM |
Battery vs Performance | --- | 2021/09/13 05:08 PM |
Battery vs Performance | --- | 2021/09/13 05:08 PM |
Battery vs Performance | Doug S | 2021/09/13 08:53 PM |
Battery vs Performance | Anon | 2021/09/14 06:42 AM |
and weren't 'they' right? | Daniel B | 2021/09/13 12:57 PM |
and weren't 'they' right? | David Hess | 2021/09/13 02:11 PM |
and weren't 'they' right? | --- | 2021/09/13 02:38 PM |
and weren't 'they' right? | --- | 2021/09/13 02:32 PM |
and weren't 'they' right? | Brendan | 2021/09/14 03:30 AM |
and weren't 'they' right? | Jukka Larja | 2021/09/14 04:31 AM |
and weren't 'they' right? | Etienne Lorrain | 2021/09/14 12:29 AM |