By: Andrei F (andrei.delete@this.anandtech.com), September 14, 2021 7:55 am
Room: Moderated Discussions
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.
> 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.
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 |