Playstation 5 [PS5] [Release November 12 2020]

If the CPU doesn't use its power budget - for example, if it is capped at 3.5GHz - then the unused portion of the budget goes to the GPU. That's what AMD calls SmartShift.

My take on this: Smartshift can allocate CPU power to the GPU, while still running at 3.5ghz.

Another interesting power saving measure: when CPU or GPU are idle for some time (and not point of increasing the clocks because of waiting for next vsync), then the frequency will be reduced (or not increased ?) during that short time, he calls this 'race to idle':

There's another phenomenon here, which is called 'race to idle'...the GPU is not doing much for that five milliseconds - and conclude that the frequency should be increased. But that's a pointless bump in frequency...So, when I made the statement that the GPU will spend most of its time at or near its top frequency, that is with 'race to idle' taken out of the equation

So with all those power saving measures (I counted 3 differents):
- Variable frequency based on current max load (100% deterministic, he confirms silicon lottery or room temp won't have an impact on the variable clocks) of both CPU / GPU,
- Smartshift (CPU unused power given to GPU)
- 'race to idle' (decreasing, or not increasing ?, frequency of either CPU or GPU when those are scheduled to do nothing for a few ms)

Cerny expect CPU and GPU to run at max frequency most of the time (the time needed to usefully run at max clocks). so this means it's totally normal that the CPU is downclocked, but it should usually not mean the downclock will make the game run slowly. In many cases CPU and GPU should be downclocked without impacting game performance.

This is really some innovative stuff. I mean, they wouldn't have needed this if they had 52CUs in the first place.
 
I felt the rest of the interview, the bits that you chopped out, really explained that quite well. Why run your processor at full speed if its not doing anything? I doubt the real meaning of developer comments that they're 'throttling back'. If they are creating workloads that aren't using the CPU fully, then the CPU will be clocked lower because it doesn't need to run higher. That's very different from the devs choosing to throttle back to free up power for the GPU, or finding when they try to put what they want on the CPU, the GPU slows down.

Looks at this line:
"There's enough power that both CPU and GPU can potentially run at their limits of 3.5GHz and 2.23GHz, it isn't the case that the developer has to choose to run one of them slower."

If that's the case, the devs don't have to choose, then the line that devs are saying they are 'throttling back the CPU' is a misrepresentation of what's going on because they don't need to throttle.

Honestly, it sounds to me like Sony made a move for a more power-efficient hardware and now they're getting crucified for it! Like a US car company saying, "we changed from an inefficient 6 litre V8 to a super efficient 2 litre inline 6 that can generate the same BHP," and having customers up in arms that it's a gimped design. ;)

I don't think your representation is quite right. The CPU and GPU can run at their maximum clocks when both are being utilized in a way that allows them to remain within their power allocation. It is possible, though, for a developer to allow utilization of one or both to exceed their allocation and this will cause some combination of power shifting to/from and throttling of one or the other parts to some degree in order to bring the total power allocation within limits. In this sense, developers would absolutely be choosing to run one of the CPU or GPU slower in order to have excessive (beyond budget) utilization of the other.
 
Who knows what it will be like with RDNA2 but most damning thing about that DF video is that performance scales much better with additional CU's than with higher clocks...the gap between XSX and PS5 could be larger than on paper if that's the case.
 
Another interesting power saving measure: when CPU or GPU are idle for some time (and not point of increasing the clocks because of waiting for next vsync), then the frequency will be reduced during that short time, he calls this 'race to idle':



So with all those power saving measures (I counted 3 differents):
- Variable frequency based on current max load (100% deterministic, he confirms silicon lottery or room temp won't have an impact on the variable clocks) of both CPU / GPU,
- Smartshift (CPU unused power given to GPU)
- 'race to idle' (decreasing, or not increasing ?, frequency of either CPU or GPU when those are scheduled to do nothing for a few ms)

Cerny expect CPU and GPU to run at max frequency most of the time (the time needed to usefully run at max clocks). so this means that it's totally normal that for instance the CPU is downclocked, but it should not mean that the downclock will make the game run slowly. In many cases CPU and GPU will be downclocked without impacting game performance.

This is really some innovative stuff. I mean, they wouldn't have needed this if they had 52CUs in the first place.

I don't think this was clear. He never said the CPU or GPU would clock down when not loaded. He just said the GPU/CPU clocking up under low loads was pointless (in a console) and therefore was not included in their estimates that the CPU and GPU would stay at max clocks most of the time.

Literally, the summation of the section was:

So, when I made the statement that the GPU will spend most of its time at or near its top frequency, that is with 'race to idle' taken out of the equation

Everything else is your speculation.
 
Developers dont get to choose, of which to run slower, it probably is automatic with this smartshift tech, it probably had to do with profiling. Alex from DF explained this before here. Like i said nothing new.
That’s not accurate, and actually the opposite of what he said. He stated that developers can choose which to prioritize, which is in complete keeping with Richard’s characterization of “profiles” for the developers to choose from.
 
That’s not accurate, and actually the opposite of what he said. He stated that developers can choose which to prioritize, which is in complete keeping with Richard’s characterization of “profiles” for the developers to choose from.

Yes my fault, its what i ment with the profiling. Its not like devs dont have to choose, or the system will do it for them, most likely.

@mpg1 besides the vrs support, seems unknown? (Hate writing on phones....)
 
Unfortunately he completely dodges the base clock question. Probably never going to get an answer on that directly from Sony. I still love the implementation, it's very innovative.
 
Unfortunately he completely dodges the base clock question.
The base clock is the max clock. How low it drops in use, and how much that actually impacts game performance, will have to wait until the console is out and running games. Cerny can't dodge a question he can't know the answer to - how will devs be using the processors in five years' time and how will the power budget be distributed and will the processing of jobs be running slower as a result.
 
"There's enough power that both CPU and GPU can potentially run at their limits of 3.5GHz and 2.23GHz, it isn't the case that the developer has to choose to run one of them slower."

If that's the case, the devs don't have to choose, then the line that devs are saying they are 'throttling back the CPU' is a misrepresentation of what's going on because they don't need to throttle.
I mean, it actually does sound like they are throttling. Because running them at full speed would sort of explain the opposite entirely. Chips have a red line of how much voltage they can receive, cores themselves had a max voltage as well. Once they exceed the voltage the chip dies or suffers issues in terms of being able to work properly, so there are hard limits on voltage and frequency etc that is entirely based on the physical properties of the chip.

In the case of _boosting_ the cores can give up some of their power to give the other cores more voltage to clock higher in frequency. And even then there is still probably left over voltage, so that voltage has no where to go, and the chip is at max frequency, so where does it go? It goes to the GPU with power shift.

So this is how PS5 supports both at their maximum cap. But then you run into the issue that if you want to guarantee the load on the GPU, as the workload increases the operations per clock cycle increases, you need more power to feed the cores individually. So normally you'd draw back frequency and spread it back over to the other cores to do more work. In this case, it's grabbing more power from the CPU forcing it to throttle, to feed the GPU.

This was at least my interpretation of what devs are doing. Cerny talked about hoping developers learn to optimize for power, meaning learning how ot code in such a way that you use less power, or use less power hungry operations or just being more efficient with your operations per cycle. I believe this was also in reference to this.

This is a cubic relationship. 0.9^3 = 72.9%. That means drastic reductions in power. Downclocks should indeed be minor.
Indeed, I will say it is coincidence that Cerny just those numbers 10% frequency drop = 27% reduction in power. Because a 10% frequency boost from 2.0GHz is nearly 2.223Ghz. How that works out in terms of what the chip can handle or works with each other is unknown. But an interesting remark made, it's not like Richard asked him if the chip was 9.2 TF.

He also did not want to answer the worst case scenario for down clocks.
Though I'm sure both MS and Sony know what the base clocks are for both chips that no amount of load would force it down any further.
 
Honestly, it sounds to me like Sony made a move for a more power-efficient hardware and now they're getting crucified for it! Like a US car company saying, "we changed from an inefficient 6 litre V8 to a super efficient 2 litre inline 6 that can generate the same BHP," and having customers up in arms that it's a gimped design. ;)

2 things - in jest (it's April, it still counts)

People have bitched endlessly for years on end about a V8 being replaced with something with fewer cylinders and or smaller capacity. Right or wrong, they do. How often have you heard the derisive term "4-banger"?

In the further interest of playfully batting around with the analogy. The 2.0 6 cylinder would be a better comparison if you had said it was turbocharged. Then we can argue about turbo lag and "real horsepower". Seems to be where the discussion in headed in most parts.
 
I felt the rest of the interview, the bits that you chopped out, really explained that quite well. Why run your processor at full speed if its not doing anything? I doubt the real meaning of developer comments that they're 'throttling back'. If they are creating workloads that aren't using the CPU fully, then the CPU will be clocked lower because it doesn't need to run higher. That's very different from the devs choosing to throttle back to free up power for the GPU, or finding when they try to put what they want on the CPU, the GPU slows down.

Looks at this line:
"There's enough power that both CPU and GPU can potentially run at their limits of 3.5GHz and 2.23GHz, it isn't the case that the developer has to choose to run one of them slower."

If that's the case, the devs don't have to choose, then the line that devs are saying they are 'throttling back the CPU' is a misrepresentation of what's going on because they don't need to throttle.

Honestly, it sounds to me like Sony made a move for a more power-efficient hardware and now they're getting crucified for it! Like a US car company saying, "we changed from an inefficient 6 litre V8 to a super efficient 2 litre inline 6 that can generate the same BHP," and having customers up in arms that it's a gimped design. ;)

With that GPU clock speed IS it more efficient though?...
 
Last edited:
The part about managing power based on deadlines of operations is remarkable (race to idle), it was in one of Cerny's patent about clock control. The circuitry they added to profile operation, to predict and meet a deadline of macro sections of code, might be as much about BC as it could be about this power scheme.
 
Really comes down to what "most of the time" means, and how low the clocks can drop. Is most of the time 51% or 99%? And then in practice how far will the clocks actually drop? Seems like it'll be less than 10%, so essentially for the console warriors that want to compare numbers, the Series X gpu is already faster, so it's a matter of whether it's faster by 20% or 30%. Ultimately, I don't think it matters at all unless you're just interested in fighting over the specs.
 
Really comes down to what "most of the time" means, and how low the clocks can drop. Is most of the time 51% or 99%? And then in practice how far will the clocks actually drop? Seems like it'll be less than 10%, so essentially for the console warriors that want to compare numbers, the Series X gpu is already faster, so it's a matter of whether it's faster by 20% or 30%. Ultimately, I don't think it matters at all unless you're just interested in fighting over the specs.
I believe the infatuation with clocks, percentages, and trying to map the thinking onto what we already know from PC gpu/cpu boost methods, are making everyone miss what is happening here and why it's made that way.
 
The base clock is the max clock. How low it drops in use, and how much that actually impacts game performance, will have to wait until the console is out and running games. Cerny can't dodge a question he can't know the answer to - how will devs be using the processors in five years' time and how will the power budget be distributed and will the processing of jobs be running slower as a result.
Do you really think so? Seems implausible. The system clocks are pre-determined based on activity counters using their model SOC. Which means they've already defined a curve which establishes clock frequency for a given activity level. It's the same curve for all machines and not dynamic, and therefore known. They've shared the curves' upper bound, but aren't sharing the lower bound. It must exists, even if you truly believe an application could never reach that condition. Which is admitted in the part of the comment describing dealing with that situation more gracefully. I don't think anyone can or is asserting how many games, if any, ever reach that point. But there is a frequency at which the system could be 100% busy, that keeps it within their power, thermal, and acoustic envelope. They couldn't have simply said, no ones ever going to get here so we don't let's not bother defining a frequency for it.
 
Really comes down to what "most of the time" means, and how low the clocks can drop. Is most of the time 51% or 99%?

This is the big question but I can't help but think if it was in any way a problem, this was have leaked by now. Developers would have spoken out, like they have expressed doubts about Lockhart's capabilities to Jason Schreier. These kind of issues just do not stay contained.
 
I feel like whether it maintains a high clock is irrelevant if there a significant diminishing returns on performance with higher clocks...

If the difference between 1.7GHZ and 2.1GHZ is an extra 5fps like DF showed who gives a shit about weather or not it is reaching it's max clock?
 
Come to think of it he can't tell you an exact number, because this number actually depends on the workload.
If we find some "lazy devs" (how long have we not seen this phrase!) that choose to run a very power heavy workload on a fairly unneeded area *cough* horizon overworld map *cough* then you'd most probably see a downclock.
You can then say "it downclocks most of the time".
But is this a typical workload? No.
Does running the game at the capped frequency help? probably not?
Is there more incentive for the devs to fix the code? It sure looks like it.
Should the devs fix their code? I hope they're competent enough to do at least that.


Then, if the devs optimized for the code to not be power intensive, we'd probably see the clocks locked at the max clocks.

It does appear to provide good feedback to "coax" devs into running more "energy efficient" code.

Anyway, at the very least it's probably clear that we won't hear our PS5s run like jet engines unless we clog the vents up or put the machine in an oven.
 
Back
Top