David Kanter (dkanter.delete@this.realworldtech.com) on September 16, 2021 12:04 pm wrote:
> Andrei F (andrei.delete@this.anandtech.com) on September 16, 2021 8:12 am wrote:
> > David Kanter (dkanter.delete@this.realworldtech.com) on September 15, 2021 11:46 am wrote:
> > > > > Isn't the point to deliver max perf with min energy?
> > > >
> > > > 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*.
> > >
> > >
> > > Wouldn't you want to run at lower voltage/frequency if possible?
> >
> > My point is you're already running at the lowest frequency without failing to deliver the QoS/frame.
> > If the performance window is smaller, then you'd be running at higher frequencies to service the
> > higher load periods, and low frequencies during lower load periods, which costs more energy than
> > running medium frequency the whole time and spreading out the load over the frame.
>
> My point is that even within 10ms, the optimal voltage will
> probably vary quite a bit (assuming fixed frequency).

Are you alluding to vdroop? This is a completely different discussion. The margins for efficiency gains are an order of magnitude lower than actual V/F switching.

>
> > >
> > > Generally the point is changing V/F should be inexpensive to enable using the optimal V/F combo.
> > >
> > > > So your 120MHz FIVR is completely and utterly pointless. You would be wasting energy at higher
> > > > voltages for no gain in user performance.
> > >
> > > Shifting to low voltage fast seems valuable, right?
> >
> > It doesn't because of the above reasons. You should be running
> > at the "just right" F/V servicing the workload.
>
> Let's say you are running at 2GHz. 8ms is 16M cycles. The 'best' voltage will
> vary over those 16M cycles based on activity in the chip, temperature, etc.

We already have these mechanisms in products right now / vdroop / temperature DVS. Yes you can have DVS that goes infinitely fast and does envelope tracking to the load. But that's a layer that sits underneath the DVFS logic.

>
> > > > 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.
> > >
> > > Would that change if V/F switch took nanoseconds and cost little energy?
> > >
> > > Seems like you would want to dynamically adjust voltage...even if at fixed frequency.
> > >
> > > David
> >
> > If it would take nanoseconds to change V/F then all you're doing is having two states - Fmax and Fmin.
> > A that point Fmin becomes meaningless as a state and it's better to just clock gate/power gate. Your
> > most prevalent state in which you do computation would be Fmax and you defeat the purpose of DVFS.
>
> Well voltage can change quite rapidly. I think Intel's FIVR is around 1V
> in 0.5us. So if you wanted to change 50mV, that's probably quite quick.
>
> David

Again, I agree, but it's a different discussion topic. Currently vendors can't even rationalise dedicated voltage rails much less something like a FIVR - Qualcomm notes they use 1+3 on the same voltage rail because the increased capacitance of the larger rail brings more benefits than a dedicated rail. 50mV is an extremely excessive swing at constant frequency, but I guess it could happen on very high power cores, but that's a different market segment.