By: someone (someone.delete@this.somewehere.com), September 12, 2018 12:20 am
Room: Moderated Discussions
megabytephreak (roukemap.delete@this.gmail.com) on August 24, 2018 1:43 pm wrote:
> Maynard Handley (name99.delete@this.name99.org) on August 24, 2018 1:26 pm wrote:
> > Jeff S. (fakity.delete@this.fake.com) on August 24, 2018 12:24 pm wrote:
> > > Maynard Handley (name99.delete@this.name99.org) on August 24, 2018 12:03 pm wrote:
> > > > Is there a real (and realistic) fear that these instructions can generate so much heat so fast
> > > > that the existing thermal tracking is too slow? And something that could be fast enough (eg
> > > > as has been suggested, limiting instruction throughput at some point --- maybe issue, maybe
> > > > decode) is not realistic why? Because the entire thermal modeling system runs at say 100th
> > > > CPU frequency and it was too hard at the time to bolt on a new, better targeted, system?
> > >
> > > I have heard more concern around the input voltage sagging
> > > on sudden heavy draw more than heat accumulation,
> > > so maybe the thermal capacity of the die is larger in a sense than the electrical capacitance afforded by
> > > the on-die and on-package systems. It seems like the 512b
> > > FMA units can collectively suck down more than half
> > > a core's power budget by themselves, and it might not take very many cycles of suddenly doubled (or worse)
> > > power consumption to drain instantaneous power supply below the threshold of reliable operation.
> > >
> > > This is the kind of thing I suspect David would very succinctly summarize as "dI/dt
> > > concerns", but I don't have any real data or secret sources for you unfortunately.
> >
> > Hmm, yeah, makes sense.
> >
> > It seems that, in PRINCIPLE, you should be able to monitor the charge of a capacitor over time,
> > and dynamically engage in clock-by-clock throttling (through things like halting fetch, decode,
> > or issue); and that this would be more performant than just clubbing the frequency?
> > Of course it takes time to design a scheme like that, but this has been an issue for years...
> >
> > It will be interesting to see if Apple has anything along those lines in the A12. Obviously
> > the details are different, but they are clearly aware that they have their own problem
> > with SoC power draw possibly exceeding what an (aged) battery can supply.
> > One solution to that is the Intel solution, just reducing frequency (and only improved
> > over the A11 and earlier solution in that there might be more intermediate frequency steps
> > available, and/or a more dynamic monitor of when current draw is going high).
> > But a more performant solution would be a variant of what I've described for AVX, something that perhaps
> > monitors the big capacitor rather than the battery current, and throttles on a cycle by cycle basis.
>
> AMD seems to have an implementation of this idea:
> https://www.realworldtech.com/steamroller-clocking/
>
> I wonder if they still use it. It seemed to make a lot of sense to me at
> the time in terms of allowing lower voltage for the same frequency.
>
Funnily enough Sam Naffziger - the architect of Intel Foxton - is responsible for much of this...
> Maynard Handley (name99.delete@this.name99.org) on August 24, 2018 1:26 pm wrote:
> > Jeff S. (fakity.delete@this.fake.com) on August 24, 2018 12:24 pm wrote:
> > > Maynard Handley (name99.delete@this.name99.org) on August 24, 2018 12:03 pm wrote:
> > > > Is there a real (and realistic) fear that these instructions can generate so much heat so fast
> > > > that the existing thermal tracking is too slow? And something that could be fast enough (eg
> > > > as has been suggested, limiting instruction throughput at some point --- maybe issue, maybe
> > > > decode) is not realistic why? Because the entire thermal modeling system runs at say 100th
> > > > CPU frequency and it was too hard at the time to bolt on a new, better targeted, system?
> > >
> > > I have heard more concern around the input voltage sagging
> > > on sudden heavy draw more than heat accumulation,
> > > so maybe the thermal capacity of the die is larger in a sense than the electrical capacitance afforded by
> > > the on-die and on-package systems. It seems like the 512b
> > > FMA units can collectively suck down more than half
> > > a core's power budget by themselves, and it might not take very many cycles of suddenly doubled (or worse)
> > > power consumption to drain instantaneous power supply below the threshold of reliable operation.
> > >
> > > This is the kind of thing I suspect David would very succinctly summarize as "dI/dt
> > > concerns", but I don't have any real data or secret sources for you unfortunately.
> >
> > Hmm, yeah, makes sense.
> >
> > It seems that, in PRINCIPLE, you should be able to monitor the charge of a capacitor over time,
> > and dynamically engage in clock-by-clock throttling (through things like halting fetch, decode,
> > or issue); and that this would be more performant than just clubbing the frequency?
> > Of course it takes time to design a scheme like that, but this has been an issue for years...
> >
> > It will be interesting to see if Apple has anything along those lines in the A12. Obviously
> > the details are different, but they are clearly aware that they have their own problem
> > with SoC power draw possibly exceeding what an (aged) battery can supply.
> > One solution to that is the Intel solution, just reducing frequency (and only improved
> > over the A11 and earlier solution in that there might be more intermediate frequency steps
> > available, and/or a more dynamic monitor of when current draw is going high).
> > But a more performant solution would be a variant of what I've described for AVX, something that perhaps
> > monitors the big capacitor rather than the battery current, and throttles on a cycle by cycle basis.
>
> AMD seems to have an implementation of this idea:
> https://www.realworldtech.com/steamroller-clocking/
>
> I wonder if they still use it. It seemed to make a lot of sense to me at
> the time in terms of allowing lower voltage for the same frequency.
>
Funnily enough Sam Naffziger - the architect of Intel Foxton - is responsible for much of this...