Playstation 5 [PS5] [Release November 12 2020]

By the results of the boost mode on the PS4 Pro, I doubt it only runs at 18 CUs according to the performance bump (well, you'd only see like a 15% bump which is close to nothing). Boost mode just didn't require the devs' input on the settings and ran at the original resolutions as fast as possibl, while proper PS4 pro versions had the devs tweak the settings for optimized results.

Just double checked, "Boost Mode" does indeed just run at the higher frequency. It's used for software that doesn't have a PS4 Pro patch.


Or 14%.

Maybe we'll now *finally* get Knack running at 60hz when the PS5 has Boost Mode assigned in BC. ;)
 
then my bad going on assumptions.
Just double checked, "Boost Mode" does indeed just run at the higher frequency. It's used for software that doesn't have a PS4 Pro patch.


Or 14%.

Maybe we'll now *finally* get Knack running at 60hz when the PS5 has Boost Mode assigned in BC. ;)[/QUOTE
 
I think it is. XSX is having fixed clocks while PS5 is not. Also, XSX is having more than 17% more memory bandwidth as well.

You'd need to make bandwidth proportional to the tflops, not as a standalone value. So bandwidth as a proportion of flops. I seem to remember looking at it before and it was only like 5% different.
 
Last edited by a moderator:
You'd make to make bandwidth proportional to the tflops, not as a standalone value. So bandwidth as a proportion of flops. I seem to remember looking at it before and it was only like 5% different.
Official numbers are 560gb/s vs 448Gb/s.

the whole debate around split pools I would generally ignore, largely speculation and not representative of what Scarlett is doing, which is asymmetrical memory sizes which allows the cpu and GPU to access at different speeds.
A large difference to the asymmetrical design on nvidia where the GPU was required to use everything.
 
Official numbers are 560gb/s vs 448Gb/s.

the whole debate around split pools I would generally ignore.

Xbox Series X = 12.1tflops @ 560GB/s (560/12.1=46.2). So 46.2/tflop.

PS5 = 10.3tflops @ 448 (448/10.2=43.5). So 43.2/tflop.

That's a difference of 5.85%.
 
Xbox Series X = 12.1tflops @ 560GB/s (560/12.1=46.2). So 46.2/tflop.

PS5 = 10.3tflops @ 448 (448/10.2=43.5). So 43.2/tflop.

That's a difference of 5.85%.
oh. Yea I don't like the whole bandwidth per teraflop metric.
Not every process uses bandwidth, with GPU dispatch based engines, you might be lucky enough to run several processes by keeping things in cache before writing out, but more importantly excluded from that equation is CPU contention for the same resources.

That metric will matter most around the largest consumer of bandwidth, which I think consistently will likely be the ROPs as most operations in that space are bandwidth limited and not ROP limited.
 
oh. Yea I don't like the whole bandwidth per teraflop metric.
Not every process uses bandwidth, with GPU dispatch based engines, you might be lucky enough to run several processes by keeping things in cache before writing out, but more importantly excluded from that equation is CPU contention for the same resources.

I'd argue it's much more accurate than stating simply 17%. CPU contention should be broadly similar between both consoles for the same games.
 
Xbox Series X = 12.1tflops @ 560GB/s (560/12.1=46.2). So 46.2/tflop.

PS5 = 10.3tflops @ 448 (448/10.2=43.5). So 43.2/tflop.

That's a difference of 5.85%.
Now do it based on gpu frequency which is now also a big thing.
Fillrate always has been, but front end not so much, as compute seemed to be the bigger comcern up until now.
 
Last edited:
10GB at 560BGps and 6GB at 336GBps vs 16GB at 448GBps.
It's not really that relevant since CPU contention pulls priority and eats the entire cycle. When the CPU is pulling the GPUs are waiting.

You're going to want to look at the major consumers of bandwidth for those things to matter. If the 80/20 rules apply here, XSX will lean heavily into the 560 GB/s for the majority of the operations, at least the ones that matter to keep it performant.

If we want to be realistic, no console will ever hit it's total bandwidth number over the course of the second. There's a lot of waste, it's only for a split moments of the frame will the full speed be maintained for a consistent number of cycles.
 
  • Like
Reactions: Jay
Now do it based on gpu frequency which is now also a big thing.
Fillrate always has been, but front end not so much, as compute seemed to be the bigger comcern up until now.

How does figures match up?

No matter how you choose to cut it; 17% is less accurate than measuring as a proportion of power.

I *do* think the Series X will perform higher based on the more powerful hardware, I just disagree that you can stack both tflops AND bandwidth thereby suggesting it's even *more* powerful because that is obviously false.
 
It's not really that relevant since CPU contention pulls priority and eats the entire cycle. When the CPU is pulling the GPUs are waiting.

You're going to want to look at the major consumers of bandwidth for those things to matter. If the 80/20 rules apply here, XSX will lean heavily into the 560 GB/s for the majority of the operations, at least the ones that matter to keep it performant.

The major consumer will be the GPU no doubt. What happens when the GPU runs out of that 10GB of 560GBps?
 
The major consumer will be the GPU no doubt. What happens when the GPU runs out of that 10GB of 560GBps.
Devs should be designing around it, but even if you couldn't, then 336Gb/s is not a slouch either. You're going to want to keep the data you need that is going to be used for high bandwidth operations in the 10GB. The remaining data can be held in the slower, but still very competent 336Gb/s.

I'm not going to say it's not going to have some sort of effect. But I wouldn't re-write the numbers to portray the numbers provided as unrealistic. I would definitely look at ways to keep things in the 10GB pool, and slower stuff in the 336 pool.

Where it would hurt XSX, is on the CPU side of things, not the GPU sides of things. Some things are just better for the CPU to do than the GPU. And in those cases the bandwidth is less. Like even now, some calculations are just better on the CPU. They can handle much more complex type functions etc.
CPUs are really good still, lol, it's the scale of the workload that keeps them from competing with GPUs. Once you reach a certain point, single threaded is useless. Then those AVX instructions might be useful, depending on what you're doing. And after a certain scale, AVX is useless. All you got left is GPU power.
 
I'd argue it's much more accurate than stating simply 17%. CPU contention should be broadly similar between both consoles for the same games.

Forgive me, but I don't understand this obsession with "17%". Even using (as presented above) a fixed 10.3 TF for PS5, and saying MS were lying about 12.155 TF and that it's actually 12.147, XSX is still 18% faster in pure compute.

Anyway, while I think you're right about CPU BW requirements being broadly similar for both consoles playing the same games, things get a bit more complicated in that the same CPU traffic is proportionally a greater consumer of BW on PS5, and that XSX has 25% more memory channels to schedule across and (probably) 25% more L2 GPU to potentially reduce pressure on the memory bus. Perhaps this won't amount to much in reality though.

It all seems rather complicated. Some of the shit-tier internet rumour mongers have claimed Sony invented the idea of larger caches and that they've used them in PS5, and that AMD didn't realise this worked and that they will copy this for RDNA3. That seems unlikely, but I guess there's still the possibility of some Sony Secret Sauce (SSS).
 
Devs should be designing around it, but even if you couldn't, then 336Gb/s is not a slouch either. You're going to want to keep the data you need that is going to be used for high bandwidth operations in the 10GB. The remaining data can be held in the slower, but still very competent 336Gb/s.

Oh I agree that Devs will design around it. It's still a lot slower though and if third party devs don't design for it, it will be a hindrance.
 
I think it is. XSX is having fixed clocks while PS5 is not. Also, XSX is having more than 17% more memory bandwidth as well.


Forgive me, but I don't understand this obsession with "17%". Even using (as presented above) a fixed 10.3 TF for PS5, and saying MS were lying about 12.155 TF and that it's actually 12.147, XSX is still 18% faster in pure compute.

Anyway, while I think you're right about CPU BW requirements being broadly similar for both consoles playing the same games, things get a bit more complicated in that the same CPU traffic is proportionally a greater consumer of BW on PS5, and that XSX has 25% more memory channels to schedule across and (probably) 25% more L2 GPU to potentially reduce pressure on the memory bus. Perhaps this won't amount to much in reality though.

It all seems rather complicated. Some of the shit-tier internet rumour mongers have claimed Sony invented the idea of larger caches and that they've used them in PS5, and that AMD didn't realise this worked and that they will copy this for RDNA3. That seems unlikely, but I guess there's still the possibility of some Sony Secret Sauce (SSS).

It was in reply to the guy stating that there is a 17% bandwidth difference. See first quote.
 
Oh I agree that Devs will design around it. It's still a lot slower though and if third party devs don't design for it, it will be a hindrance.
I would say like, the ideal case where PS5 may be ahead of XSX is at the 120fps markers. That's where the CPU is ripping through the frame quickly, and you're dropping off all sorts of big workloads. So you're left to rely on smaller workloads and likely more fixed function stuff. That's where PS5 is going to hold some major advantages over XSX. And I think the bandwidth could help out PS5 here in that respect, because moving that quickly through the frame and lowering the resolution works in its favour.

PS5 will operate better than XSX the further it gets away from 4K. That's just a workload thing, it's designed to work on smaller loads faster, and it's not as well tuned to operate on bigger loads. Faster clock speeds, lower bandwidth, lower CUs all point to superior lower resolution performance.
 
Back
Top