• Hey Guest. Check out your NeoGAF Wrapped 2025 results here!

Mark Cerny on The Verge (GPU, elite controller, etc)

Didn't want to throw even more technical terms into the discussion. But I'm talking about the opaque buffer the buffer where rastorized geometry is written to. The folks at digital foundry use to pixel count. The opaque buffer should match screen pixels 1 on 1. Thought it was implicitly known that when people talk about native resolution people mean the opaque buffer and not the other buffer like shadow maps.
I'm just gonna chuck this up to simple misunderstanding.

This is how digital foundry does pixel counting if you're interested.

http://www.eurogamer.net/articles/digitalfoundry-2016-teach-yourself-pixel-counting
 
I dunno, games like Uncharted 4 and upcoming titles like Horizon, GOW and Days Gone all look pretty damn impressive considering how unimpressive many people think pS4 hardware is. And lets not forget the very respectable VR you can get from OGPS4, developers are squeezing those results from somewhere. Not saying it's performing miracles but those guys sure are managing to get some wine from the ol water jug

It is decently capable hardware and first-party developers have the advantage of only coding for one platform. The key point is that the hardware is performing as expected based on the announced specs. Before release the expectations for PS4 games were 1080p/30 fps for most games and that is exactly what we got. For PS4 Pro the expectations based on announced specs are 4K-ish/30fps and that's what we'll get. Don't believe in secret sauces and marketing.
 
Chequerboard rendering is not as good as 4K native.
FP16 will provide some performance gains, absolutely nowhere near '8.4 TFlops'.
Scorpio is 6 TFlops FP32.
In a year or so I will quote myself and prove that I am a tech wizard.

Sarcasm aside, I have no issue with the information onQ is presenting. My issue is with the way he is interpreting it. He is interpreting it through the filter of a company fanboy, he is reaching wrong conclusions and misleading others in the process. This is why the jeff rigby comparisons are apt. Jeff was also researching his topics thoroughly but he was interpreting data in a specific way to reach the conclusion that he wanted.

There's an article on Gamasutra where Mark Cerny presents the technology behind the Playstation 4 and the custom modifications he did to the hardware.

http://www.gamasutra.com/view/feature/191007/inside_the_playstation_4_with_mark_.php?print=1

There are a lot of impressive-sounding technologies there. Reading this before the console's release one would be justified in thinking that the PS4 is a revolutionary piece of tech with all sorts of performance-enhancing modifications. Three years in, what kind of real-world result did all those technologies have?

Cerny is a smart man and he did an incredible job designing the PS4 keeping the price and form factor limitations in mind. The PS4 Pro will be another well-designed and affordable console. It won't perform miracles and believing so will inevitably lead to disappointment, just like the PS4's initial hype led many to believe that current gen consoles are 'trash', as can be seen in many DF threads.


No where am I saying that Checkerboard rendering is the same as native 4K .


The FP16 not being 8.4TF comment don't make sense because it is 8.4TF the problem is people having a set idea of what a TF is without taking into account that FP32 is not the only thing it's used for. It doesn't matter how angry people get because of their lack of understanding PS4 Pro is 8.4TF FP16 that's not up for debate it's a fact.
2761999-ciwqsbg14oivl2g2s.jpg


That's who you remind me of.

Checkerboard rendering is a great way to construct a 4k image, but it's not native and will always be inferior to native 4k.


Your comment tells me that you didn't even understand what you just read because it has nothing to do with my comment that you quoted
 
I'm just gonna chuck this up to simple misunderstanding.

This is how digital foundry does pixel counting if you're interested.

http://www.eurogamer.net/articles/digitalfoundry-2016-teach-yourself-pixel-counting

I'm not sure if you're implying that dragonelite or you misunderstand how pixel counting is done but that article describes exactly what dragonelite said in more laymen terms. Dragonelite is correct how pixel counting is currently done.

No where am I saying that Checkerboard rendering is the same as native 4K .


The FP16 not being 8.4TF comment don't make sense because it is 8.4TF the problem is people having a set idea of what a TF is without taking into account that FP32 is not the only thing it's used for. It doesn't matter how angry people get because of their lack of understanding PS4 Pro is 8.4TF FP16 that's not up for debate it's a fact.

Do you see a game being developed entirely with FP16 calculations?

The problem is not what we do or do not take into account. The problem is that you refuse to acknowledge the industry standard of how performance is measured.

No one is denying that the Pro is capable of FP16 calculations, that is indeed a fact. It's just not the most important performance metric.
 
They will still calculate TF using 32bit floats man. It's the standard... Single Precision. If they are referring to anything different they will specify "Double Precision" or "Half Precision" or "Mixed Precision".

They don't calculate Flops by how many is being done they just give you the theoretical peak number of floating point operations that can be done in a second.

The answer to that in FP16 is 8.4TF,
 
I'm not sure if you're implying that dragonelite or you misunderstand how pixel counting is done but that article describes exactly what dragonelite said in more laymen terms. Dragonelite is correct how pixel counting is currently done.

Do you see a game being developed entirely with FP16 calculations?

The problem is not what we do or do not take into account. The problem is that you refuse to acknowledge the industry standard of how performance is measured.

No one is denying that the Pro is capable of FP16 calculations, that is indeed a fact. It's just not the most important performance metric.

Again TF isn't calculated by how many flops is being done but by how many could be achieved in theory. that number in FP16 is 8.4TF

Me saying that is not me telling you that 8.4TF FP16 is the same as 8.4TF FP32.
 
http://www.gamasutra.com/view/news/283611/Inside_the_PlayStation_4_Pro_with_Mark_Cerny.php

Interesting that taking Jaguar cores to 2,1 Ghz is what made them increase the cooling solution size. It must be a little beyond the efficiency sweet spot at that clock. By the way we still don´t know if the PRO´s APU is 14nm GF or 16nm TSMC...


Yup, the same architecture features that let it outdo even AMDs larger Piledriver cores per-clock also mean it was bound to relatively low clocks. 2.1GHz is right up against where the highest clocked desktop Jaguar part is, and that's where the CPU isn't sharing a thermal load with a PS4 Pro sized GPU.

https://en.wikipedia.org/wiki/Jaguar_(microarchitecture)#Desktop


Sony must have been in a pickle between wanting the Pro to be another PS4 and ensure full compatibility, and as best address the CPU being the weak spot already as best they could without breaking compatibility. So a 30% upclock was what they could manage, even if it went past Jaguars sweet spot for efficiency.

“What we do for the legacy games, if you want to play a game from 2-3 years ago that hasn't been patched or tested, is we just run that at 1.6 gigahertz,” said Cerny. “We run the GPU at 800 megahertz, and we shut down half of the GPU.”

Still find that odd. Who is doing clock dependant programming anymore?
And if someone ties physics to framerate, it would usually be a locked framerate anyways. Wish the CPU at least was kept at the higher clock for regular PS4 games, maybe it could smooth a number of them out (like Bloodborne)
 
Again TF isn't calculated by how many flops is being done but by how many could be achieved in theory. that number in FP16 is 8.4TF

Me saying that is not me telling you that 8.4TF FP16 is the same as 8.4TF FP32.

I never said that's how TF is calculated.

You're just being obtuse on purpose, ignoring my point and question because you know it doesn't support your narrative.

It's impossible to have a conversation with you when you pivot and spin like a politician.
 
I never said that's how TF is calculated.

You're just being obtuse on purpose, ignoring my point and question because you know it doesn't support your narrative.

It's impossible to have a conversation with you when you pivot and spin like a politician.


You said I refuse to acknowledge the industry standard of how performance is measured & I'm telling you that me saying that PS4 Pro is 8.4TF FP16 is not me refusing to acknowledge the industry standard. A game being made using mixed precision or not using FP16 at all does not change how many TF the console has.
 
You would think making the claim that a 2017 console being half the specifically mentioned teraflops while also somehow being less powerful than a 2016 console would require some kind of well thought-out explanation.

To me, extraordinary claims require extraordinary proof, and it seems like conclusions were jumped to and doggedly defended without adequate explanation as to why MS would need to do all this in the first place.

Much like Jeff, I think he reached a very juicy conclusion first, felt the need to be the first one on GAF to post about it for that "GAF cred", but then never bothered to work backwards as to any really legitimate reason for a company to do this past the vague technicality that they could.
 
You said I refuse to acknowledge the industry standard of how performance is measured & I'm telling you that me saying that PS4 Pro is 8.4TF FP16 is not me refusing to acknowledge the industry standard. A game being made using mixed precision or not using FP16 at all does not change how many TF the console has.

Just because you say it doesn't make it true. Everyone here knows that FP32 is the industry standard. Again you're being obtuse to push your narrative.

Unless a game uses only FP16 calculations, it is a misleading measurement to be throwing around.

You are only spinning things in a way that you can say you were right. On a real tech forum you'd be laughed out of every thread for pushing this silly agenda.
 
So what's happening when they take these 1080P PS4 games & resolve them to a 4K frame using these different techniques?

Checkerboard rendering as presented by the Rainbow 6 Team seems a lot more advanced than a fixed rule like bilinear filtering.
To interpolate between a blank checkerboard pixels and it's neighbours it looks at the the direction camera moves, the color values and the depth difference to its neighbours. It also looks at the previous frame's values for all three measures.
It then weights these inputs and determines the final color.

For reference bilinear filtering (=regular scaling) looks only at the neighbouring pixel colors.
So checkerboard rendering has a lot more information to predict the color a pixel will have and it seems at least plausible that it is does a lot better.
 
Didn't want to throw even more technical terms into the discussion. But I'm talking about the opaque buffer the buffer where rastorized geometry is written to. The folks at digital foundry use to pixel count. The opaque buffer should match screen pixels 1 on 1. Thought it was implicitly known that when people talk about native resolution people mean the opaque buffer and not the other buffer like shadow maps.

I doubt DF uses the opaque buffer - or any internal graphics pipeline buffer, really - to pixel count. They use what they have access to, i.e. the screen captures and count the stairs on hard geometry lines (obviously not shadows, particles, SSR-s, etc. because those can be of lower resolution to save on bandwidth).
 
Just because you say it doesn't make it true. Everyone here knows that FP32 is the industry standard. Again you're being obtuse to push your narrative.

Unless a game uses only FP16 calculations, it is a misleading measurement to be throwing around.

You are only spinning things in a way that you can say you were right. On a real tech forum you'd be laughed out of every thread for pushing this silly agenda.


This is silly. 8.4TF FP16 is a spec & that spec doesn't change depending on how it's used it's always going to be the same.

What do you want me to tell you that it's not 8.4TF FP16?
 
Checkerboard rendering as presented by the Rainbow 6 Team seems a lot more advanced than a fixed rule like bilinear filtering.
To interpolate between a blank checkerboard pixels and it's neighbours it looks at the the direction camera moves, the color values and the depth difference to its neighbours. It also looks at the previous frame's values for all three measures.
It then weights these inputs and determines the final color.

For reference bilinear filtering (=regular scaling) looks only at the neighbouring pixel colors.
So checkerboard rendering has a lot more information to predict the color a pixel will have and it seems at least plausible that it is does a lot better.

That was actually a rhetorical question.
 
I doubt DF uses the opaque buffer - or any internal graphics pipeline buffer, really - to pixel count. They use what they have access to, i.e. the screen captures and count the stairs on hard geometry lines (obviously not shadows, particles, SSR-s, etc. because those can be of lower resolution to save on bandwidth).

They use opaque geometry, which would be the hard geometry you mention here. I believe that is what dragonelite meant.

This is silly. 8.4TF FP16 is a spec & that spec doesn't change depending on how it's used it's always going to be the same.

What do you want me to tell you that it's not 8.4TF FP16?

It's a useless spec without actual context to how it'll be used. It's about as relevant as saying the 360 is a 1TF machine like MS originally claimed. You can spin the numbers so that it's technically correct but it's still misleading in the end.
 
They use opaque geometry, which would be the hard geometry you mention here. I believe that is what dragonelite meant.



It's a useless spec without actual context to how it'll be used. It's about as relevant as saying the 360 is a 1TF machine like MS originally claimed. You can spin the numbers so that it's technically correct but it's still misleading in the end.


There is context I have never said it was 8.4TF without showing that I'm talking about FP16.

So what's your real beef?
 
Still find that odd. Who is doing clock dependant programming anymore?

Your quote from Cerny didn't say software had to be redesigned. He specifically cited testing as important to ensure that running on a platform with different performance characteristics doesn't expose bugs. So to rephrase your question "who is writing software with bugs anymore?" Answer: everyone who writes non-trivial software, especially anything multi-threaded.

It will certainly be interesting to see if Sony decides that it's worth testing and whitelisting specific games. For now, their approach seems to amount to letting developers decide for themselves whether to put the time and energy into ensuring that their existing titles work well in Pro mode, and while they're at it perhaps putting minimal effort into at least bumping the title's resolution.
 
Your quote from Cerny didn't say software had to be redesigned. He specifically cited testing as important to ensure that running on a platform with different performance characteristics doesn't expose bugs. So to rephrase your question "who is writing software with bugs anymore?" Answer: everyone who writes non-trivial software, especially anything multi-threaded.

It will certainly be interesting to see if Sony decides that it's worth testing and whitelisting specific games. For now, their approach seems to amount to letting developers decide for themselves whether to put the time and energy into ensuring that their existing titles work well in Pro mode, and while they're at it perhaps putting minimal effort into at least bumping the title's resolution.
The way I see it, it could potentially break low-level coded (libGNM) games.

Games written in the DX11-esque API (libGNMX) may be able to handle increased clocks.

Can a PS4 dev chime in on this issue?
 
No one has ever said a Flops number then explained that it only count if you use it.


Why is this different today? what are you looking for?

I'm done, trying to have an actual discussion with you is impossible. Like anyone here who's smarter than me, I'm not going to engage in this nonsense any longer. Have fun living in your bubble of irrelevant statistics.
 
I'm done, trying to have an actual discussion with you is impossible. Like anyone here who's smarter than me, I'm not going to engage in this nonsense any longer. Have fun living in your bubble of irrelevant statistics.

Ok & have a nice day I'm still not sure of any point that you was trying to make but ok bye.
 
They use opaque geometry, which would be the hard geometry you mention here. I believe that is what dragonelite meant.



It's a useless spec without actual context to how it'll be used. It's about as relevant as saying the 360 is a 1TF machine like MS originally claimed. You can spin the numbers so that it's technically correct but it's still misleading in the end.

Correct i thought rasterized geometry would have been explicit enough.
 
Correct i thought rasterized geometry would have been explicit enough.
I wanted to let this issue go by just chucking it up to a simple misunderstanding but your just insistent on something you are totally wrong about.

You said

If uprendering is Native then upscaling is also. Native means Native and that means every pixel on screen goes through the rendering pipeline. And not be generated later like with upscaling, reconstructive or checkerboard rendering.

If it saves performances with rendering and allow better lighting with minimal impact on iq I'm all for it.
So there is literally no room for misinterpretation on my part. You were trying to equate reprojection and checkered rendering to simple upscaling which can be done at the end of the rendering pipeline. And Native means something that isn't scaled, it is independent of screen resolution. Checkered rendering or reprojection is not generated later or done at the end like you insinuated. They are part of the rendering pipeline and not outside of it.

Secondly you said

Didn't want to throw even more technical terms into the discussion. But I'm talking about the opaque buffer the buffer where rastorized geometry is written to. The folks at digital foundry use to pixel count. The opaque buffer should match screen pixels 1 on 1. Thought it was implicitly known that when people talk about native resolution people mean the opaque buffer and not the other buffer like shadow maps.

I pointed you to digital foundry article and video on how they do it. They don't have access to the opaque buffer, all they have access to is the final render buffer that is sent out to the TV. If you said opaque geometry that would make sense. You said opaque buffer.

I doubt DF uses the opaque buffer - or any internal graphics pipeline buffer, really - to pixel count. They use what they have access to, i.e. the screen captures and count the stairs on hard geometry lines (obviously not shadows, particles, SSR-s, etc. because those can be of lower resolution to save on bandwidth).

Edit: I reached out to Digital Foundry to clarify and if i'm wrong, I will post it in a second update.
 
Will Sony promote the Pro as being an 8.4TF FP16 machine?
Did Sony promote the PS4 activly as a 1,8TF machine?
Does it even matter?

With that reasoning, it's a 16.8TF FP8 machine. Or 33.6TF FP4 machine.
But it's not because the ALUs can't process four FP8 operations or eight FP4 operations at once.
It's either one FP32 operation or two FP16 operations, depending on the native format everything below it will still operate with the same processing rate.
 
But it's not because the ALUs can't process four FP8 operations or eight FP4 operations at once.
It's either one FP32 operation or two FP16 operations, depending on the native format everything below it will still operate with the same rate.

I know. But hey, who knows what the future brings.
Still, it's not that you can move everything to FP16. It will have its uses, sure (just as researching and implementing GPGPU to offload a CPU), but it will not be a mechanism that will suddenly make your game go from 30 to 60FPS or something like that.

if it would be a car engine, FP16 operations would be something like an 'extra booster' that you can use with a very specific type of fuel in a specific type of car, with a speciic type of driver, to get to a higher top speed. If you design your car around that principle, it might be a bigger benefit (first party games); if you don't, it's just a nice extra (most third party games).
 
So pretty much a developer could use certain pieces utilizing FP16 and some pieces utilizing FP32 if understanding this correctly. It seems like people are making this an either/or when it seems like devs could offload certain processes to be less precise and use FP32 for certain things so in a sense they could reach certain goals vs being stuck with just using one or the other.

or am i off in this case?
 
I wonder if something like object culling, shaders or shadow precision can sort of 'switch' to FP16 based methods (as long as they dont result into crazy artefacts) if they are in a certain range away from the camera.
 
So pretty much a developer could use certain pieces utilizing FP16 and some pieces utilizing FP32 if understanding this correctly. It seems like people are making this an either/or when it seems like devs could offload certain processes to be less precise and use FP32 for certain things so in a sense they could reach certain goals vs being stuck with just using one or the other.

or am i off in this case?

Some important processes can be sped up GPU side when optimized for FP16 code, yes, and its definitely a benefit for the GPU when trying to squeeze juice out of it, but it can't be utilized on everything.

Generally, its a side benefit that generally speaking won't even be used all that much IMO, because devs won't be optimizing for pro in a vacuum. The basic utilization of FP32 will be far more than enough to get results on screen and that's generally all devs will aim for, since 99% of the development effort will be on the base PS4.
 
I know. But hey, who knows what the future brings.
Still, it's not that you can move everything to FP16. It will have its uses, sure (just as researching and implementing GPGPU to offload a CPU), but it will not be a mechanism that will suddenly make your game go from 30 to 60FPS or something like that.

if it would be a car engine, FP16 operations would be something like an 'extra booster' that you can use with a very specific type of fuel in a specific type of car, with a speciic type of driver, to get to a higher top speed. If you design your car around that principle, it might be a bigger benefit (first party games); if you don't, it's just a nice extra (most third party games).
If you look at the practise you may also claim that it's not a 4,2 TF machine because the practical performance is not matching the theoretical output since the game code is hitting various bottlenecks.

It's in theory a 4,2 TF FP32 machine and a 8,4 TF FP16 machine.
Nobody should try to sell explicit performance simply because of that, it's a "stupid" number which only shows one part of the whole picture.
I don't get the arguments for or against the notion of the hardware specs.
 
If you look at the practise you may also claim that it's not a 4,2 TF machine because the practical performance is not matching the theoretical output since the game code is hitting various bottlenecks.

It's in theory a 4,2 TF FP32 machine and a 8,4 TF FP16 machine.
Nobody should try to sell explicit performance simply because of that, it's a "stupid" number which only shows one part of the whole picture.
I don't get the arguments for or against the notion of the hardware specs.

I totally agree :)
 
So pretty much a developer could use certain pieces utilizing FP16 and some pieces utilizing FP32 if understanding this correctly. It seems like people are making this an either/or when it seems like devs could offload certain processes to be less precise and use FP32 for certain things so in a sense they could reach certain goals vs being stuck with just using one or the other.

or am i off in this case?
That's right.

This could boost the FP32-only target of 4.2TF to 5-6TF by using mixed precision. Not bad at all.
 
Some important processes can be sped up GPU side when optimized for FP16 code, yes, and its definitely a benefit for the GPU when trying to squeeze juice out of it, but it can't be utilized on everything.

Generally, its a side benefit that generally speaking won't even be used all that much IMO, because devs won't be optimizing for pro in a vacuum. The basic utilization of FP32 will be far more than enough to get results on screen and that's generally all devs will aim for, since 99% of the development effort will be on the base PS4.

yeah i figured it may be useful for things that dont need the extra precision like static elements etc if i understand correctly. Also understand now probally would just go for FP32 as much as possible if anything since the ps4 is the base. But very interesting they would allow for that and maybe its to help proof the system for a longer period of time.

That's right.

This could boost the FP32-only target of 4.2TF to 5-6TF by using mixed precision. Not bad at all.

yeah its a pretty smart design there based on that premise.
 
I know. But hey, who knows what the future brings.
Still, it's not that you can move everything to FP16. It will have its uses, sure (just as researching and implementing GPGPU to offload a CPU), but it will not be a mechanism that will suddenly make your game go from 30 to 60FPS or something like that.

if it would be a car engine, FP16 operations would be something like an 'extra booster' that you can use with a very specific type of fuel in a specific type of car, with a speciic type of driver, to get to a higher top speed. If you design your car around that principle, it might be a bigger benefit (first party games); if you don't, it's just a nice extra (most third party games).
That was such a ridiculous comparison, made absolutely no sense. And literally nobody is making the argument that it would make a 30fps game to 60fps.

The bolded is false. FP16 has been used in graphics rendering for a long long time. Heck even games on PS3 used it. Seriously, its not a new thing at all, all that is new is PS4 Pro and future AMD GPUs support 2 FP16 operations per clock cycle. Mobile GPUs support it.
 
If you look at the practise you may also claim that it's not a 4,2 TF machine because the practical performance is not matching the theoretical output since the game code is hitting various bottlenecks.

It's in theory a 4,2 TF FP32 machine and a 8,4 TF FP16 machine.
Nobody should try to sell explicit performance simply because of that, it's a "stupid" number which only shows one part of the whole picture.
I don't get the arguments for or against the notion of the hardware specs.

The information came from me so they have to somehow make it wrong.
 
Top Bottom