• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Digital Foundry - Playstation 5 Pro specs analysis, also new information

Reallink

Member
Wait, 45% because it's the average of 28% faster memory and 67% faster Tflops (using single issue)? They really don't know how faster it really is, do they?

Why is this here? and again, this is wrong. Pro CPU won't dictate if the game runs at 60fps. What are they afraid at?

I just want to see Leadbetter being wrong, that would be hillarious.

Percentage numbers change depending on which comparative and which direction you report/refer to them as. So 65% higher than x can simultaneously be 45% lower than y, or vise versa. So technically both figures can be accurate. For example 45% less than Pro's 16.X TF's is basically 10.X TF (i.e. base PS5), but simultaneously 65% more than 10.X TF is 6.X TF, and 10.X + 6.X = 16.X TF (i.e. Pro). It's unintuitive and confusing, but such is most of math.
 
Last edited:
You absolutely should as that would be the primary motivation for the Pro: to take base PS5 fidelity modes and push to 60fps. The combination of the GPU perf increase and PSSR should absolutely be able to take a 2160p/30 title and push to 4K/60fps.

The leaked documents already alluded to this as the "Game1" use case mentions fidelity mode quality at 60fps.

My worry is the devs have been notoriously lazy this gen, and Sony has shown they want to be "hands off" with 3rd party, so while newly released games will have thr equivalent of Quality modes boosted to 60 fps, what about all the games that have released this gen that have locked 30 fps quality modes? I just don't see many devs going back and patching them to remove the 30 lock, let alone improving image quality or RT....cyberpunk, Alan Wake 2, doing light 2 all come to mind because those are games that really fell short on the console side of things.
 
Wasn't it the same for the PS5?
Yes. Except it was worse for PS5 back then. Here the only thing they can criticize is the lack CPU upgrade (I mean AI upscaling + new RT hardware, that should be a dream for them, except it isn't, they prefer to make hit pieces against the CPU). But it doesn't work as most informed people in social medias (like John) know PS5 games usually have no problem with the CPU.
 

shamoomoo

Member
Up to a certain point, yes. The lack of memory bandwidth on consoles is recurring and it's the main reason why consoles use low levels of Anisotropic filtering or none at all.
But the PS5 has much better optimizations for dealing with memory bandwidth, than the PS4, for example.
Not only it uses a tile based renderer, which significantly reduces memory accesses. But it also has delta color compression.
And the cache scrubbers.
 

Lysandros

Member
A little secret, all modern CPUs and GPUs have cache scrubbers.
The thing that the PS5 has, is that the SSD controller can also do that.
I am not sure to follow, in Road to PS5 Cerny clearly presented the Cache Scrubbers as a hardware feature unique to PS5. The scrubbers themselves are shown within the GPU diagram.
Are you talking about the coherency engines within the APU integrated I/O complex (not the SSD controller)? I know those inform the Scrubbers which data to replace instead of flushing the entire cache to avoid wasting bandwidth.
 
Last edited:

ShakenG

Member
Of all the developers CD Projekt Red are pretty much the most likely 3rd party dev to go back and polish their game for the Pro. They love implementing the best tech they can in their games.
They were the 1st developer that came to mind for me. For 3rd party like you say. Cyberpunk specifically. Bit unsure about The Witcher.
 
My worry is the devs have been notoriously lazy this gen, and Sony has shown they want to be "hands off" with 3rd party, so while newly released games will have thr equivalent of Quality modes boosted to 60 fps, what about all the games that have released this gen that have locked 30 fps quality modes? I just don't see many devs going back and patching them to remove the 30 lock, let alone improving image quality or RT....cyberpunk, Alan Wake 2, doing light 2 all come to mind because those are games that really fell short on the console side of things.
Dying Light 2 for sure will have patched 30fps modes. Those devs will do whatever they can to bring players back to their game.
 

Panajev2001a

GAF's Pleasant Genius
Not only it uses a tile based renderer
You are talking about the way they render to the frame buffer right not any change to how geometry is submitted, rasterised, and renderer? If not I think I would have missed how they switched the rendering pipeline majorly: for me tile based renderer / tilers are those scene capturing GPUs that require all the geometry to be processed and stored in VRAM (for the current rendering pass) before they can capture the scene / bin it into tiles and then render tile by tile.

You are talking about RDNA2 doing this: https://www.realworldtech.com/tile-based-rasterization-nvidia-gpus/

Not this: https://developer.arm.com/documentation/102662/latest/Tile-based-GPUs

Right?
 

winjer

Gold Member
You are talking about the way they render to the frame buffer right not any change to how geometry is submitted, rasterised, and renderer? If not I think I would have missed how they switched the rendering pipeline majorly: for me tile based renderer / tilers are those scene capturing GPUs that require all the geometry to be processed and stored in VRAM (for the current rendering pass) before they can capture the scene / bin it into tiles and then render tile by tile.

You are talking about RDNA2 doing this: https://www.realworldtech.com/tile-based-rasterization-nvidia-gpus/

Not this: https://developer.arm.com/documentation/102662/latest/Tile-based-GPUs

Right?

Those 2 are doing Tile Based Rendering.
The first company to have a GPU with that tech was PowerVr, in the early 2000s. with their Kyro and Kyro II cards.
They also made the GPU for the Dreamcast. So that was the first console to have a Tile based Renderer.
They were mid range GPUs, that in several games performed well above their weight, because of the Tile Based rendering.
But most consumers ignored the company and they went almost bankrupt. Eventually, they got back on their feet by making GPUs for mobile phones, and were successful.
Nvidia, then decided to also use the tech, with Kepler. And AMD followed suit with RDNA1.

If you are interested, here is a review of the Kyro II, compared to the GPUs of it's era.
Consider that this is basically a card that cost as much as a Geforce II MX200-400, but often was trading punches with the GTS.

 

Panajev2001a

GAF's Pleasant Genius
Those 2 are doing Tile Based Rendering.
The first company to have a GPU with that tech was PowerVr, in the early 2000s. with their Kyro and Kyro II cards.
They also made the GPU for the Dreamcast. So that was the first console to have a Tile based Renderer.
They were mid range GPUs, that in several games performed well above their weight, because of the Tile Based rendering.
Thanks for the recap, but I am aware of PowerVR (I was there when Commodore 64, Amiga 2000, and the first 386 machines were around, albeit a tad young with C64…) :). Sorry, it came out very passive aggressive, apologies.

It was arguably much more the hidden surface removal (the DR part of TBDR), HW based OIT, and volume modifiers (arguably both were console chip exclusives IIRC and both never made their way back to PowerVR designs) that were helping those chips punch above their weight, but sure having a 32x32 on-chip tile buffer to write to would remove a lot of bandwidth waste (as well as make AA cheaper in those architectures, see A series chips from Apple, as you can resolve samples before you write to external memory). Sure, being able to bin geometry to tiles was a pre-requisite.

Again, not the point, it is not really that important, but between the nVIDIA GPU in the example and the ARM one, there is quite a lot of difference in the way they do tiling: one would still get geometry you submit to the GPU, process it, buffer it, try to rasterise and render one tile at a time) while the other gets geometry, performs all necessary vertex processing, writes it back to memory, bins it, and then starts rendering tile by tile. This part of tiling also affected designs like Dreamcast which would use VRAM storing the complete scene geometry for the current rendering pass (also reading geometry, binning and sorting, and then you can render) so the more geometry in the scene the more VRAM used.

Again back to the RWT video ( where they already made the distinction from Tile Based Rendering, Immediate Mode Rendering or IMR, and Tile Based Rasterisation which is what nVIDIA is using or how the article calls it in the video tile based Immediate [mode rendering] technique)…

nVIDIA’s solution is buffering vertex data you submit to the GPU (2k worth at a time or so: https://forum.beyond3d.com/threads/tile-based-rasterization-in-nvidia-gpus.58296/ ) but there is no requirement that all the geometry is processed before rendering can start, there is no separate binning phase ( https://forum.beyond3d.com/threads/tile-based-rasterization-in-nvidia-gpus.58296/post-1934231 geometry is submitted in normal order), no additional RAM storage requirements, and the same screen tile can be written to more than once (I imagine that in most cases you submit geometry with good screen spatial locality so effectively you get the tiling benefit in most cases).

Samsung has a surprisingly good overview of IMRs and Tile Based Renderers: https://developer.samsung.com/galaxy-gamedev/resources/articles/gpu-framebuffer.html and how they use memory:
qO8LGBf.jpg


While nVIDIA’s Tile based rasterisation memory usage probably is a lot closer to this and does not 100% ensure a tile is never written to memory more than once (but I would think it happens rarely enough, 80-20 rule at its finest :)):
zbBhuHa.jpg


The article of course does not cover nVIDIA’s tile based immediate rendering innovation (tile based rasterisation) which I think RWT and the B3D thread I linked to do a very good job discussing (but I am sure it is nothing you have not seen before, not saying you do not know your history :)).

But most consumers ignored the company and they went almost bankrupt. Eventually, they got back on their feet by making GPUs for mobile phones, and were successful.
Nvidia, then decided to also use the tech, with Kepler. And AMD followed suit with RDNA1.

If you are interested, here is a review of the Kyro II, compared to the GPUs of it's era.
Consider that this is basically a card that cost as much as a Geforce II MX200-400, but often was trading punches with the GTS.


👍.
 
Last edited:

Loxus

Member
Some new RDNA 4 info.



So if the rumor about 64CUs in Navi48 are true. It'll only have 8 WGP or 16 CU per Shader Engine, with 4 Shader Engines total.
The same as RDNA3.

Question is, where does this put the PS5 Pro rumor of having 2 Shader Engines with 16 WGP or 32 CU per Shader Engine?

Still old RDNA2, like the CPU but with added CUs, AI Accelerators, upgraded RT and dual-issue the old SIMD32?
 
Last edited:

winjer

Gold Member
I am not sure to follow, in Road to PS5 Cerny clearly presented the Cache Scrubbers as a hardware feature unique to PS5. The scrubbers themselves are shown within the GPU diagram.
Are you talking about the coherency engines within the APU integrated I/O complex (not the SSD controller)? I know those inform the Scrubbers which data to replace instead of flushing the entire cache to avoid wasting bandwidth.

Those scrubbers in the GPU, are a part of the I/O coherency engine.
The PS5 I/O engine, talks directly to those scrubbers, coordinating what data to eliminate in certain GPU caches.

 

blastprocessor

The Amiga Brotherhood
Be very disappointing if it's N5/N6 but would be inline with the RDNA 3 desktop GPUs.
I'd hope for N4 or better given a late 2024 release.
Even then it's not cutting edge.
 
Last edited:

Lysandros

Member
Those scrubbers in the GPU, are a part of the I/O coherency engine.
The PS5 I/O engine, talks directly to those scrubbers, coordinating what data to eliminate in certain GPU caches.


Yes, i know about this like i said. They work together. The distinction being the Scrubbers (capable of being informed by the coherency engines) themselves are physically located within the GPU caches. Whereas the coherency engines are part of the I/O complex. Cache Scrubbers (GPU part of the sub-system) is (also) unique to PS5 and it is clearly stated as such in the presentation.

At ~25:40 onwards (Cerny talking about collaboration with AMD) "[...] If the ideas are sufficiently specific to what we are trying to accomplish like the GPU Cache Scrubbers then they end up being just for us."
 
Last edited:
I'm no expert but I don't see how Sony can still use a chip based on 7 nm, when they have to "fit" a 67% larger GPU in there. And I mean "fit" in both size and power consumption

It seems logical to move to 5 nm
 

Bojji

Member
I'm no expert but I don't see how Sony can still use a chip based on 7 nm, when they have to "fit" a 67% larger GPU in there. And I mean "fit" in both size and power consumption

It seems logical to move to 5 nm

Rdna3 is using 6nm and 5nm mix so I don't expect anything different here.
 

Tqaulity

Member
My worry is the devs have been notoriously lazy this gen, and Sony has shown they want to be "hands off" with 3rd party, so while newly released games will have thr equivalent of Quality modes boosted to 60 fps, what about all the games that have released this gen that have locked 30 fps quality modes? I just don't see many devs going back and patching them to remove the 30 lock, let alone improving image quality or RT....cyberpunk, Alan Wake 2, doing light 2 all come to mind because those are games that really fell short on the console side of things.
Of course it will be up to the dev and their time/resources etc to go back and patch. That said, if this approach by Sony is what it appears to be, it should be very little effort to do so. At the very least, they could just use PSSR to take the existing quality mode and deliver it at 60fps as is, whether it's running natively at 2160p, 1440p, or something in between. The result with minimal effort should be the same quality mode running much faster. With some more effort, they could do other things to clean up the IQ (i.e. push DRS targets higher, push native internal res higher, add higher quality graphics settings) and add RT effects if desired.

I expect that we'll see some Sony 1st Party games do the extra work to deliver on the full promise of the Pro. Titles like Returnal, GT7, Spiderman 2, and Ratchet & Clank will be the poster children for the Pro (at least initially) with added and/or improved RT effects running at 60fps with fidelity mode visuals. Recent releases such as Rise of the Ronan, Stellar Blade, and Helldivers 2 should also be improved quite a bit. As for third parties, it'll depend on the amount of effort to update but Sony knows this and I suspect it will be pretty painless to update.
 


- Navi 48

- N4P Node


All specs confirmed

- 32 WGP = 64 CUs

- GDDR6 256-bit bus

- 693 GB/s memory bandwidth and 2770 GB/s effective memory bandwidth
- 2708 Mhz memory clock = 21.7 GT/s
 
Last edited:

Mr.Phoenix

Member
Well there it is. That is the PS5pro GPU. The navi 48. Albeit a highly modified one.

Eg.

- On PS5pro, only 30 of the 32WGPs will be active.
- PS5pro will be using 18Gbs RAM
- Will be grossly downclocked, so under 2.3Ghz?

Looks to me like the PS5pro is going to be a 300-320mm2 chip, unlike the Navi 48, PS5pro mem bus will be on the chip as opposed to be on a MCD chiplet, and then there is the CPu and cache too. Or maybe even like 280mm2. I can see it not pulling anything more than 230W too. Max 240W.
 
Last edited:

Loxus

Member
Well there it is. That is the PS5pro GPU. The navi 48. Albeit a highly modified one.

Eg.

- On PS5pro, only 30 of the 32WGPs will be active.
- PS5pro will be using 18Gbs RAM
- Will be grossly downclocked, so under 2.3Ghz?

Looks to me like the PS5pro is going to be a 300-320mm2 chip, unlike the Navi 48, PS5pro mem bus will be on the chip as opposed to be on a MCD chiplet, and then there is the CPu and cache too. Or maybe even like 280mm2. I can see it not pulling anything more than 230W too. Max 240W.
Something is still missing.
N48 has 4 Shader Engines, while PS5 Pro has 2.



The PS5 Pro having only 2 SE with 64CUs isn't adding up.
 

Loxus

Member
You compared RDNA 3,5 vs RNDA4. Difference story.
But anyway RDNA 3.5 is fixed RDNA3. Missed perfomance is back
I probably wasn't digging deep enough.
As far as I know, RDNA3.5 has the same 8-10 WGP per Shader Engine as RDNA3.

PS5 Pro having 16 WGP per Shader Engine is quite extreme.

These are all the RDNA3.5 GPU chips I know of. This is base on info I collected over time.

Kraken Point
TSMC N4P
CPU: 8c Zen 5
iGPU: RDNA3.5
XDNA 2: 64 AIE-ML tiles
: 45-50 TOPs

Strix Point
Ryzen 3: 4c Zen5C
Ryzen 5: 4c Zen5 + 4c Zen5C

Ryzen 7/9
TSMC N4P 225mm²
CPU: 4c Zen5 L2: 4 MB L3: 16 MB
: 8c Zen5C L2: 8 MB L3: 8 MB
iGPU: 8 WGP RDNA3.5 (1SE, 16CU)
XDNA2: 64 AIE-ML tiles
:45-50 TOPs
Memory: DDR5-6400 / LPDDR5X-8533
128-bit bus
Power: 28-54 W

Strix Halo
TSMC N4P
CPU: 8c Zen5 L2: 4 MB L3: 32 MB
: 8c Zen5 L2: 4 MB L3: 32 MB
: 6.0GHz
iGPU: 20 WGP RDNA3.5 (2SE, 40CU)
: 3.0GHz
: ~30.7 TFLOPs
Infinity Cache: 32MB
XDNA2: 64 AIE-ML tiles
: 45-50 TOPs
Memory: 256-bit bus
Power: 55-120 W
 
Last edited:

Loxus

Member
That is answer about what is RDNA 3.5
296d5288cb9efef80f82cbef13b12fc7.png
That has nothing to do with the number of WGP per Shader Engine.

Below you can see 8 WGP per Shader Engine.
Navi48 is the same, but with 4 Shader Engines.
bDatbVp.jpg



RDNA3.5
Strix Point: 1SE, 8WGP, 16CU (8WGP per SE)
Strix Halo: 2SE, 20WGP, 40CU (10WGP per SE)

RDNA4
Navi44: 2SE, 16WGP, 32CU (8WGP per SE)
Navi48: 4SE, 32WGP, 64CU (8WGP per SE)

PS5 Pro: 2SE, 30WGP, 64CU (16 WGP per SE)
See how different the PS5 Pro Shader Engines are compared to RDNA3.5/4?

Like I said. Something is missing from the puzzle in regards to the PS5 Pro Shader Engines.
 

SolidQ

Member
Like I said. Something is missing from the puzzle in regards to the PS5 Pro Shader Engines.
That maybe because is difference WGP and how they work in RDNA 3.5 and 4
P.S Ok got for you answer from Kepler - Area reasons. 2 SE design is smaller.
 
Last edited:

Mr.Phoenix

Member
I probably wasn't digging deep enough.
As far as I know, RDNA3.5 has the same 8-10 WGP per Shader Engine as RDNA3.

PS5 Pro having 16 WGP per Shader Engine is quite extreme.

These are all the RDNA3.5 GPU chips I know of. This is base on info I collected over time.

Kraken Point
TSMC N4P
CPU: 8c Zen 5
iGPU: RDNA3.5
XDNA 2: 64 AIE-ML tiles
: 45-50 TOPs

Strix Point
Ryzen 3: 4c Zen5C
Ryzen 5: 4c Zen5 + 4c Zen5C

Ryzen 7/9
TSMC N4P 225mm²
CPU: 4c Zen5 L2: 4 MB L3: 16 MB
: 8c Zen5C L2: 8 MB L3: 8 MB
iGPU: 8 WGP RDNA3.5 (1SE, 16CU)
XDNA2: 64 AIE-ML tiles
:45-50 TOPs
Memory: DDR5-6400 / LPDDR5X-8533
128-bit bus
Power: 28-54 W

Strix Halo
TSMC N4P
CPU: 8c Zen5 L2: 4 MB L3: 32 MB
: 8c Zen5 L2: 4 MB L3: 32 MB
: 6.0GHz
iGPU: 20 WGP RDNA3.5 (2SE, 40CU)
: 3.0GHz
: ~30.7 TFLOPs
Infinity Cache: 32MB
XDNA2: 64 AIE-ML tiles
: 45-50 TOPs
Memory: 256-bit bus
Power: 55-120 W
the XSX has 14 WGs per shader engine though. So adding two more may not be that extreme. But you are right, something is missing. Could it also be that the PS5pro just uses 4 shader engines? If it does or doesn't isnt really something leakers will know.
 

Loxus

Member
the XSX has 14 WGs per shader engine though. So adding two more may not be that extreme. But you are right, something is missing. Could it also be that the PS5pro just uses 4 shader engines? If it does or doesn't isnt really something leakers will know.
The thing with the XBSX, all CUs wasn't properly utilized with that many CUs per Shader Engine.

Which is why the PS5 with it's 36CUs can often match or out perform the XBSX with 52CUs.


 

Loxus

Member
Could it also be that the PS5pro just uses 4 shader engines? If it does or doesn't isnt really something leakers will know.
4 Shader Engines seems logical to me, but at that point, might as well use 10 WGP per SE like with the PS5 instead of 8.

That would be 80CUs total, with a 72CUs active. And it would still play nice with BC.

PS4: 1SE, 18CU on.
PS4/PS5: 2SE, 36CU on.
PS5 Pro: 2SE + 2SE / 36CU + 36CU
Butterfly mode like PS4 Pro.

Then PS6 can use the same strategy as how the PS5 kept the same CUs as the PS4 Pro and keep the same CUs as the PS5 Pro.
 

Lysandros

Member
The thing with the XBSX, all CUs wasn't properly utilized with that many CUs per Shader Engine.

Which is why the PS5 with it's 36CUs can often match or out perform the XBSX with 52CUs.



Exactly, i would not like to see that mistake repeated with PS5 PRO. That would be one sure way to throw compute efficiency out of the window. 32 CUs per SE is way too extreme.
 

ChiefDada

Gold Member
On DF Direct (Early Access), they took a question asking whether the PS5 Pro could open the door for path-traced applications like CP and AW2. They all laughed and basically said no. I was actually shocked to see Richard one-up Alex with his ignorant reasoning, saying since 7900xtx has relatively "bad" performance with CP path tracing and has more CUs than PS5 Pro, PS5 Pro will not be able to run it. He takes no consideration for architectural improvements and other important unknowns for both raster and RT between RDNA 3 and RDNA 3.5/4. Then basically says since Sony didn't mention anything about developers being able to do PT, we should assume PT isn't feasible on PS5 Pro.
 

ChiefDada

Gold Member
Richard also labeled outlets referring to PS5 Pro as a "RT monster" as overblown. He said about PS5 "it's not a RT monster, it's just better at RT" Excuse me? The hypocrisy is beyond insane now. No way would leaked docs from Xbox claiming a 2-4x boost in RT get the same downplay and subdued reaction from them, and rightfully so.

Also, 60 CU (PS5 Pro) vs 96 CU (7900xtx) delta isn't far off from 36 vs 52 CU of PS5 and Series X. And the base consoles are of the same core architecture! It's no wonder why he/they are still confused about PS5 and Series X performance differences.
 
Richard also labeled outlets referring to PS5 Pro as a "RT monster" as overblown. He said about PS5 "it's not a RT monster, it's just better at RT" Excuse me? The hypocrisy is beyond insane now. No way would leaked docs from Xbox claiming a 2-4x boost in RT get the same downplay and subdued reaction from them, and rightfully so.

Also, 60 CU (PS5 Pro) vs 96 CU (7900xtx) delta isn't far off from 36 vs 52 CU of PS5 and Series X. And the base consoles are of the same core architecture! It's no wonder why he/they are still confused about PS5 and Series X performance differences.

They should stick to shill for MS to get exclusives from a dead brand. That's what they can do

They know nothing about RDNA 4, let alone PS5 Pro
 
Last edited:

blastprocessor

The Amiga Brotherhood
Man my 4070 can't do decent path tracing FPS @ 1440p without turning on DLSS Q and if you want above 60fps frame gen needs to be turned on.
 
Last edited:

Bojji

Member
Richard also labeled outlets referring to PS5 Pro as a "RT monster" as overblown. He said about PS5 "it's not a RT monster, it's just better at RT" Excuse me? The hypocrisy is beyond insane now. No way would leaked docs from Xbox claiming a 2-4x boost in RT get the same downplay and subdued reaction from them, and rightfully so.

Also, 60 CU (PS5 Pro) vs 96 CU (7900xtx) delta isn't far off from 36 vs 52 CU of PS5 and Series X. And the base consoles are of the same core architecture! It's no wonder why he/they are still confused about PS5 and Series X performance differences.

I don't know what you are smoking here, this is the difference between 7900XTX and 7700XT (closest GPU to Pro in raster power):

gT4j8Eo.jpg


PS5 - 10.29 TFLOPS
XSX - 12.15 TFLOPS

vs.

7900XTX - 61.39 TFLOPS
7700XT - 35.17 TFLOPS (more than Pro)

Isn't far off...
 

damidu

Member
Man my 4070 can't do decent path tracing FPS @ 1440p without turning on DLSS Q and if you want above 60fps frame gen needs to be turned on.
yeah exactly my situation, probably should have waited for 4070ti super or something.
and even when you cut down some stuff to go 4k, vram issues start to happen there.
 
Top Bottom