Playstation 5 [PS5] [Release November 12 2020]

[Shifty Geezer]

sorry, just CPUs and GPUs then

Or rather, PC parts that get boosts, for PCs. PS5 isn't a PC and it doesn't make sense to describe it as if it was. You can expect a PC part to fluctuate between base and boost opportunistically, but PS5 isn't going to work that way, so using those same two figures will present a false idea of what's going on.

Putting it another way, if Sony gave two clock speeds, people would relate it to the PC variable boost clocks and think the typical clock speed wanders between the two.

 

[Karamazov]

all in in all holes

 

[PSman1700]

Putting it another way, if Sony gave two clock speeds, people would relate it to the PC variable boost clocks and think the typical clock speed wanders between the two.

It's also different in that, my 2080Ti is having it's lowest clock advertised, and the TF number is there after the default base clock. A 2080Ti is 14TF (somewhere?) when taking boost clocks in consideration. The PS5 seems to use a further developed version of smart shift to control the variable clocks (when needed under heavy work load).

 

[Shifty Geezer]

Ok, I'm very fine on this and I'm not contesting it.
Where I get lost in the narration is the passage "and only sony noticed this, so no other had the idea of designing the system taking it in consideration".

PCs can't control the workload so IHVs would have considered it. eg. A PC GPU may be used for compute workloads, and you don't know what CPU you'll have and if supports some power management features, and if it has a decent profile to fit the power management. It's also a considerable engineering feat and there's no need in the PC space, whereas Sony were willing to take up the cost. Also, you can typically just go wider etc. so don't need to worry about squeezing juice from high clocks and push efficiency that much more. Sony finding themselves limited to 36 CUs thanks to BC may have looked harder at the squeezing more out the silicon - necessity is the mother of invention!

We shouldn't assume anything fabulous on Sony's part until we see the final product and what it can do. It may not live up to optimistic expectations. Only when the hardware is released and evaluated can we see if it's a good approach. Then perhaps the PC space will look into it more, and have to arrange some form of protocol for the IHVs to adhere to.

 

[fehu]

Isn't plain smartshift already based on heuristic data based on load?

 

[Shifty Geezer]

It's also different in that, my 2080Ti is having it's lowest clock advertised, and the TF number is there after the default base clock. A 2080Ti is 14TF (somewhere?) when taking boost clocks in consideration.

And if the RTX 2080 Ti sat mostly at its boosted clock speed for all users, would nVidia be calling it a 13 TF part or a 14 TF part?

 

[AlNom]

nVidia measures in MSRP $.

 

[PSman1700]

And if the RTX 2080 Ti sat mostly at its boosted clock speed for all users, would nVidia be calling it a 13 TF part or a 14 TF part?

No idea really, good one, for PR 14TF would work the best Now your saying it, the RTX GPU's are mostly on their boosted clocks, but NV advertises a whole TF lower anyway. I think it depends, im seeing the 2080Ti as a 13.4TF product, it's the absolute performance im getting.

 

[iroboto]

Agree, smart shift is probably the foundation of the tech though.

My understanding is that smartshift is 1/2 the solution.
The bespoke technology that they built was the algorithm that detects workloads and controls the frequencies between the CPU and GPU.
So the workloads will dictate the frequencies on both.
The power to the SOC stays constant however (but the individual cores on both the CPU and GPU have their limits, thus clocking limits)
So while their tech controls the frequency on both the CPU and GPU, it does not shift the power between the 2 units.

Smartshift is the technology that transfers any residual power back and forth between the two.

So Sony's tech without smart shift just would have meant downclocking under heavy loads.
With Smart Shift they can handle larger loads than without as a result of the power shift from CPU to GPU.

So the easiest way to look at it:
GPU 2.23 GHz because the GPU cores are not heavily burdened so they give more power to less cores to work faster.
When a workload comes along and it requires all workloads to fire it will need to downclock to say, 2.0GHz because the power is now equally divided back among the cores.
there may be some additional sharing of power back and forth between the cores to keep the frequency up or TDP down as well.

Smart shift comes into play in which when those loads come and utilize everything on the GPU and it still needs more power or a downclock will occur, the smartshift will pull available CPU power over to the GPU.
In essence it is a reinforcement.

If that limit is broken, depending on the profile the devs picked, it could downclock the CPU further to sustain the GPU.

Further than that, the GPU will need to downclock.

All of this happening very quickly of course.

 

[Globalisateur]

Isn't plain smartshift already based on heuristic data based on load?

Smartshift should be based on pure power consumption (of the CPU). PS5 variable frequency is based on such a load.

 

[Globalisateur]

My understanding is that smartshift is 1/2 the solution.
The bespoke technology that they built was the algorithm that detects workloads and controls the frequencies between the CPU and GPU.
So the workloads will dictate the frequencies on both.
The power to the SOC stays constant however (but the individual cores on both the CPU and GPU have their limits, thus clocking limits)
So while their tech controls the frequency on both the CPU and GPU, it does not shift the power between the 2 units.

Smartshift is the technology that transfers any residual power back and forth between the two.

So Sony's tech without smart shift just would have meant downclocking under heavy loads.
With Smart Shift they can handle larger loads than without as a result of the power shift from CPU to GPU.

So the easiest way to look at it:
GPU 2.23 GHz because the GPU cores are not heavily burdened so they give more power to less cores to work faster.
When a workload comes along and it requires all workloads to fire it will need to downclock to say, 2.0GHz because the power is now equally divided back among the cores.
there may be some additional sharing of power back and forth between the cores to keep the frequency up or TDP down as well.

Smart shift comes into play in which when those loads come and utilize everything on the GPU and it still needs more power or a downclock will occur, the smartshift will pull available CPU power over to the GPU.
In essence it is a reinforcement.

If that limit is broken, depending on the profile the devs picked, it could downclock the CPU further to sustain the GPU.

Further than that, the GPU will need to downclock.

All of this happening very quickly of course.

No smartshift only transfers (virtually or really ?) power from CPU to GPU and allow GPU to be clocked higher (by their variable clocks tech).

 

[iroboto]

No smartshift only transfers (virtually or really ?) power from CPU to GPU and allow GPU to be clocked higher (by their variable clocks tech).

right, it's a one way direction you mean? That makes sense. the CPU will never need more power likely, the GPU is going to be 3x-4x more power hungry.

edit: nah, it's gotta go back and forth

 

[PSman1700]

All of this happening very quickly of course.

Ok nice explained, sounds like a very good tech for laptops too.

 

[fehu]

Smartshift should be based on pure power consumption (of the CPU). PS5 variable frequency is based on such a load.

https://www.amd.com/en/technologies/smartshift

AMD SmartShift technology allows the processor and the graphics to consume power from a shared power budget by dynamically shifting power depending on the task at hand.​

 

[Scott_Arm]

Benchmarks of games reveal that there is no game that uses 100% of CPU and GPU at the same time. It's almost inconceivable for a perfect engine powering a game consisting of perfect placement of asset by level design resulting in the CPU using 99%+ of it's ability and feeding the GPU to 99%+ of its utilisation. PS5's appears design is predicated on the sad fact that there is always something not fast enough, beit CPU or GPU. If you can get close, you can tip it this way or that way.

The benchmarks on GPU utilization running games in DF's last videos for PS5 videos show this to be the case.

I don't disagree with that. There will always be times when the CPU waits on DRAM accesses, or the workload shifts etc.

 

[mrcorbo]

However the details shake out, it seems this is clearly a smart optimization.

 

[Rockster]

The disclosure of Sony's frequency curve at given activity levels is inevitable in my mind. Seems better to get out in front of it now, so there is time for people to forget prior to launch and allow the focus to shift to the games as it should. And honestly, I think that is what they are "trying" so hard to do now. Unfortunately, that obvious lack of transparency is going to continue to raise questions rather than simply putting them all to rest with hard facts.

 

[MrFox]

The disclosure of Sony's frequency curve at given activity levels is inevitable in my mind. Seems better to get out in front of it now, so there is time for people to forget prior to launch and allow the focus to shift to the games as it should. And honestly, I think that is what they are "trying" so hard to do now. Unfortunately, that obvious lack of transparency is going to continue to raise questions rather than simply putting them all to rest with hard facts.

Hahaha, no. People will move on to the next FUD.

 

[mpg1]

Is there any feature in the PS5 that would mitigate potential memory bandwidth issues?

 

[shiznit]

It's because with portable and productivity devices (or IoT), the dominant power is the quiescent current (the amount of power when everything is powered but idling) and the power management have extremely low idling modes to counter this, so it does something for a few ms, then it shuts down almost completely for a second until the user clicks something, or an email is received, etc.... Also with low power devices there isn't as much of an exponential relationship with clocks.

With the high power used here, any reduction of quiescent current is dwarfed by the exponential (cubic!) power at the top of the frequency curve. And there isn't much opportunities to power down, if any.

So if you have a task for the frame which is using the max clock at 3.5, filled with AVX256 instructions, but it finishes within 80% of the time allowed before the next frame, you end up wasting a massive amount of power compared to running it at 3.0 for the 100% time allowed. There is zero difference in cpu performance between the two, but the former is consuming a LOT more energy, since power use is cubic, while the time slice is linear versus frequency.

So that means an additional chunk of watts "for free" which the GPU might have used at that particular point in the pipeline. Hence "squeezing every last drop". It's minimizing the possibilities of the GPU clocking down from 2.23, but the CPU would normally stay at the same effective performance as if it was always locked at 3.5. The power hungry device here is much more the GPU than the CPU, if there's any drop of frequency, it's the GPU that provides the most gain. It's just logical the CPU never drops unless it can do so for free.

The required real time profiling is no different from trying to predict a resolution downscale or LoD to keep the frame rate consistent, but it's doing the reverse. Estimate if the operation will finish much earlier than the next frame cycle, and lower the clock proportionately, with some safety margin?

So the opposite of race-to-idle, run the CPU at the slowest clock speed your frametime budget allows. This doesn't bode well for VRR support and I still don't see how it would allow both CPU and GPU to average clocks above 2.0/3.0 if you're throttling the CPU to free up GPU power budget.