PlayStation 4K - Codename Neo - Technical analysis
- Thread starter Recall
- Start date
No we have less chance to see 30 fps games be 60 fps on NEO mode.
Michellstar
Regular
Even AMD stated that most of the improvements from Polaris come from the process shrink (from 28nm planar to 16/14 nm finfet), they keep repeating 2.5 performance/watt up.
It´will be around 2x gpu flops (a little bit more if the cloks are upped to 900mhz)
But those flops, are a theoretical upper limit of the ALUs (adds + muls)
Lol not The Witness, it's not a small game at all; only one map, but it's a big map. 900p60fps to 4K60fps doesn't seem likely.
Frame rate is a combination of both CPU and GPU as frame time.
In Neo's case the GPU is getting a hefty uptick, but the CPU is getting a small bump. To move from 30 to 60 were talking doubling the game requirements on both GPU and CPU side of things. Some games might be able to go to 60 from 30 but don't expect all games to be able to do it.
How the CUs are utilised in current games? I mean if a game doesn't use CUs directly (feeding them with compute tasks), but uses straight PS4 api rendering pipeline, will it benefit from the CUs amount increase? If yes, is it able to get ~2x performance with 2xCUs without changing the code?
The CU's are a fundamental part of the graphics pipeline so all graphics workloads will be utilising them to a (usually) heavy degree. Therefore making that part of the pipeline wider will benefit all games where it is the limiting factor.
You do raise a good point though that not all parts of the GPU are necessarily being widened to the same degree, so depending on the workload, the speed increase is only going to be as great as the part of the GPU that the bottleneck sits on. That's exactly why a 4 TFLOP PC GPU like the 380x (similar to, but a bit slower than PS4K) is usually nowhere near 2x as fast as a 2 TFLOP PC GPU like the 370 (similar to but a bit faster PS4). And that's without any real CPU constraints, which will not be the case for PS4K.
http://www.techpowerup.com/reviews/Gigabyte/GTX_980_Ti_XtremeGaming/23.html
DuckThor Evil
Legend
Ironically the 4k results for the 380X are so good in the link, that it has to be some error
Ironically the 4k results for the 380X are so good in the link, that it has to be some error
Yeah I've been assuming that's an error. It outperforms is theoretical limits in the 4K test so almost certainly not correct.
DuckThor Evil
Legend
They messed up some where. This review from January still has it correct.
http://www.techpowerup.com/reviews/Sapphire/R9_390_Nitro/23.html
But their next GPU review has the error already. I think instead of redoing all the tests, they just copy paste some of them.
It's not the change in process node that makes me believe there's a change in graphics IP. The memory bandwidth to CU ratio in the leaked specs seems to indicate Delta Color Compression being present in the new APU.
To the degree that you could double the CU count and clock higher while only increasing the memory bandwidth by 24% and not have it become a bottleneck? That's not rhetorical, I'm genuinely curious.
Sebbbi posted recently on this. 16 ROPS is as much as the consoles can use save some fringe cases, requiring far more BW than any GPU has (500+ GB/s?). Of course, drawing pixels is only part of bandwidth consumption.
I don't think we have those engines yet. But with consoles, whatever resources you make available will be used (well, typically. Maybe not so in a .5 upgrade!). If Sony made PS4N 18 CUs and 500 GB/s BW, devs would favour BW heavy solutions. If they make it 36 CUs and 220 GB/s, devs will favour compute based solutions..
OVerall though, I think the colour compression is the main reason they can get away with a marginal BW increase. The GPU may be more balanced than it first seemed, leaving us with just a pokey little CPU to drive the thing.
Last edited:
D
Deleted member 11852
Guest
Yeah, it is true, you can't saturate even 16-ROPs with the current bandwidth all the time. But more is better to get work done quicker.
Just an example (numberes must not be correct). If the rops have work for ~4ms frametime, and with double hardware you only need them ~2ms, you can do the steps that come next sooner. so the ROPs aren't used for the whole second and so they don't need the whole bandwidth ...
also sebbi mentioned something to write into the caches so you have a lot more bandwidth available than just main-memory bandwidth.
What I just wanne say, yes more ROPs are better than less ROPs even if they don't work the whole time.
'Fringe' is perhaps a little too strong a word on my account. More 'specific, limited cases'.Sebbbi mentioned shadow maps as a case where 16 ROPS was not desirable. Shadow maps.. nom nom nom
