PS4 Pro Official Specifications (Codename NEO)

[turkey]

. I think that's another reason to use checkerboard instead of dynamic resolution. .

why have dynamic or checkerboard, can you not have dynamic checkerboard?

 

[iroboto]

Nice. They said they can't tell the difference at 3 or 4 feet from a 60" TV. Much less noticeable than the difference between 900p and 1080p.

Not surprising, since it appears only during panning, and the motion resolution is horrible in 4K anyway. Resolving the full 4K visually requires the image to be practically still at 30fps. I think that's another reason to use checkerboard instead of dynamic resolution. It should provide a much better image when it counts, and artifacts happen at such a small scale they would be masked by motion blur, since they only appear during significant motion.

Unless there is dynamic checkerboard resolution I don't think they are quite the same.

Dynamic resolution looks to lock frame rate at the cost of resolution.

Checkerboard looks to be a very effective form of generating high resolution with less resources, but it doesn't save you from poor frame rates.


Sent from my iPhone using Tapatalk

 

[Scott_Arm]

...

Checkerboard looks to be a very effective form of generating high resolution with less resources, but it doesn't save you from poor frame rates.


Sent from my iPhone using Tapatalk

That's a difficult argument. Dynamic resolution and reconstruction are both used to avoid bottleneck and reduce time per frame.

 

[Shifty Geezer]

Checkboard is a fixed saving per frame to use however you want. Dynamic res adapts based on short-term workload to avoid excessive framerate drops. Kinda like the difference between a grant and a loan. Sort of. Maybe.

 

[BRiT]

Also, if there is any temporal aspects to checkerboard rendering then dynamically changing resolutions introduces additional issues.

 

[bgroovy]

Also agree, shouldn't be too bad, but integration of checkerboard rendering and HDR would require more effort. Well the checkerboard will obviously be a larger effort I think.


Sent from my iPhone using Tapatalk

Days Gone uses both on Unreal 4. At the least that code can probably work it's way over to the main ps4 branch.

 

[MrFox]

I was thinking they might skip more/less quads for scaling. As per their VR presentation where they have patterns of four quads to created a fixed foveation, meaning they could scale from 1:4 to 1:1 dynamically and even within different areas of the frame.

This can't work well if they change the frame buffer resolution between frames, and scaling a checkerboard pattern might cause more artifacts.

 

[goonergaz]

Cheers, that Mantis Burn racing looks right up my street - I loved the Motorstorm RC gameplay and this looks similar

 

[Globalisateur]

From the latest DF article and how they were able to quadruple the resolution from the PS4 1080p 60fps game to native 4K 60fps on Pro

http://www.eurogamer.net/articles/digitalfoundry-2016-hands-on-with-mantis-burn-racing-on-ps4-pro

As we understand it, with the new enhancements, it's possible to complete two 16-bit floating point operations in the time taken to complete one on the base PS4 hardware.

So basically 8.4 tflops using 16-bit compute? It's a AMD Vega feature, right?

EDIT: Ok apparently FP16 is already available on RX 480

 

[scf]

Secret sauce?

 

[Rurouni]

Are we really talking about fp16 double rate or something else? I know that Polaris support fp16 but at what rate I don't know.

 

[MrFox]

We already expected the doubled fp16. I mean they said it's based on polaris, that's one really important new feature!

So far developers are talking about new stuff compared to PS4, but it's not always clear which ones are from the original ps4, or polaris, or vega, or sony's own improvements for the Pro.

The cerny seminar should be this week...

 

[Ryan Smith]

EDIT: Ok apparently FP16 is already available on RX 480

On GCN 3 & 4 the only FP16 support in the shader cores is for storing FP16 data as FP16, rather than having to promote it to FP32 (i.e. it halves register pressure). GCN 3/4 don't have any fast FP16 math modes; FP16 operations are processed at the same speed as FP32 math.

 

[Rurouni]

That is why I ask about it. Even though Pascal architecture support double rate fp16 I believe their consumer chip doesn't have it (disabled?). I don't ever remember Polaris support double rate fp16, I do remember AMD support 16bit since Tonga. But if Pro support double rate fp16 like I assume double rate fp16 is, then it should be something new, unless I missed something when Polaris was being announced.
Edit: I'm still not convinced that Pro support double rate fp16 until I hear it from Cerny's mouth with his relaxing voice...

 

[loekf]

I always hate this kind of journalism. Either you dig deeper or don't make statements like "Of course, we already knew that the Pro graphics core implements a range of new instructions - it was part of the initial leak - but we didn't really know exactly what they could actually do. "

When I see this:

The Polaris GPUs are also capable of native FP16 and Int16 support. This allows FP (Floating Point) performance at half the rate of single precision which is better tuned for graphics, computer vision and data learning markets. The use of FP16 results in lower power compared to FP32 compute and also reduced memory/register usage.

(http://wccftech.com/amd-rx-480-polaris-10-full-slide-deck-leak/)

It sounds like the Pro uses GCN 4.0 CUs and has FP16 (and Int16 ?) support giving you 2x performance at 1/2 the precision.

But I'm not an expert.

 

[Globalisateur]

On GCN 3 & 4 the only FP16 support in the shader cores is for storing FP16 data as FP16, rather than having to promote it to FP32 (i.e. it halves register pressure). GCN 3/4 don't have any fast FP16 math modes; FP16 operations are processed at the same speed as FP32 math.

Thanks.

I always hate this kind of journalism. Either you dig deeper or don't make statements like "Of course, we already knew that the Pro graphics core implements a range of new instructions - it was part of the initial leak - but we didn't really know exactly what they could actually do. "

When I see this:

The Polaris GPUs are also capable of native FP16 and Int16 support. This allows FP (Floating Point) performance at half the rate of single precision which is better tuned for graphics, computer vision and data learning markets. The use of FP16 results in lower power compared to FP32 compute and also reduced memory/register usage.

(http://wccftech.com/amd-rx-480-polaris-10-full-slide-deck-leak/)

It sounds like the Pro uses GCN 4.0 CUs and has FP16 (and Int16 ?) support giving you 2x performance at 1/2 the precision.

But I'm not an expert.

They talk about lower power and reduced memory usage for GCN 4.0, not double speed. See @Ryan Smith's post. Seems like FP16 at 2x speed (compared to FP32 or even GCN 4.0 16FP) could be specific to Pro.

 

[loekf]

Thanks.


They talk about lower power and reduced memory usage for GCN 4.0, not double speed. See @Ryan Smith's post. Seems like FP16 at 2x speed (compared to FP32 or even GCN 4.0 16FP) could be specific to Pro.

Is that THE Ryan Smith OMG

So in that respect, it has the same benefits as e.g. Thumb mode on ARM ?

Maybe stupid question, but if you use FP16 will you notice ? In end you've to map to HDR10 (when enabled) with 10-bits per component and REC2020 color space.

 

[jlippo]

Maybe stupid question, but if you use FP16 will you notice ? In end you've to map to HDR10 (when enabled) with 10-bits per component and REC2020 color space.

FP16 is good for storing values for most lighting values, but it certainly isn't good enough to calculate lighting with.

I would expect FP/INT16 to be used for things like SSAO passes, vertex tricks/culling and such, anywhere low value range and some rounding errors are acceptable.

 

[Love_In_Rio]

FP16 is good for storing values for most lighting values, but it certainly isn't good enough to calculate lighting with.

I would expect FP/INT16 to be used for things like SSAO passes, vertex tricks/culling and such, anywhere low value range and some rounding errors are acceptable.

An interesting Sebbi post related to FP16 shaders:

https://forum.beyond3d.com/posts/1805847/

Sometimes it requires more work to get lower precision calculations to work (with zero image quality degradation), but so far I haven't encountered big problems in fitting my pixel shader code to FP16 (including lighting code). Console developers have a lot of FP16 pixel shader experience because of PS3. Basically all PS3 pixel shader code was running on FP16.

It is still is very important to pack the data in memory as tightly as possible as there is never enough bandwidth to lose. For example 16 bit (model space) vertex coordinates are still commonly used, the material textures are still dxt compressed (barely 8 bit quality) and the new HDR texture formats (BC6H) commonly used in cube maps have significantly less precision than a 16 bit float. All of these can be processed by 16 bit ALUs in pixel shader with no major issues. The end result will still be eventually stored to 8 bit per channel back buffer and displayed.

So in theory this bodes well for PS3 remasters in native 4K. I foresee base PS4 games changing many shader code lines from FP32 to FP16 where possible to take advantage of double the FP16 rate in PS4 Pro (if true of course).

 

[mpg1]

What would be the theoretical performance difference of PS4 Pro vs PS4 if you consider the new features. Perhaps it would "behave" closer to a 5TFlop gpu when comparing it to PS4?