• 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.

Next-Gen PS5 & XSX |OT| Console tEch threaD

Status
Not open for further replies.

HeisenbergFX4

Gold Member
Just havent seen this gif in awhile and wanted to bring it back ;)




jurassic park dinosaur GIF
 

NXGamer

Member
So if AVX2 shouldn't exist on a CPU, why does Cerny call out their native support for it in Road to PS5, and even uses it as a justification for why they did the variable frequency tech?

He even coyly suggests that AVX2 usage shouldn't be or won't be minimal; again, pointing out that the variable frequency would maximize the potential of developers using AVX2.
Again, I have not said NO AVX2 or even other Instructions such as FMA which have all been around for donkeys. What Mark said is correct of course, it can and will support AVX2 and he also stated that the extent of that COULD cause the CPU to throttle back.

From the block it is clear changes here have been made and that may be with less Ints, reduced width or something else. The point is that within the system and the SDK they can "focus" developers to use the functions to the best method of the system and some of the previously bound CPU workloads may no longer be limited to it.
 

IntentionalPun

Ask me about my wife's perfect butthole
Again, I have not said NO AVX2

Oh give me a break.. you clearly seemed to think PS5 wasn't supporting AVX2 extensions.. You strongly suggested they shouldn't exist on the CPU, and then when someone pointed out they are confirmed for PS5, you backed off that.. and said:

NXGamer said:
Not sure he did
 
Last edited:

kyliethicc

Member
Again, I have not said NO AVX2 or even other Instructions such as FMA which have all been around for donkeys. What Mark said is correct of course, it can and will support AVX2 and he also stated that the extent of that COULD cause the CPU to throttle back.

From the block it is clear changes here have been made and that may be with less Ints, reduced width or something else. The point is that within the system and the SDK they can "focus" developers to use the functions to the best method of the system and some of the previously bound CPU workloads may no longer be limited to it.
You have to kinda take IntentionalPun IntentionalPun in small doses.

He does get like this when he's not had his Weetabix.
 

NXGamer

Member
Oh give me a break.. you clearly seemed to think PS5 wasn't supporting AVX2 extensions.. You strongly suggested they shouldn't exist on the CPU, and then when someone pointed out they are confirmed for PS5, you backed off that.. and said:
OK, you want an argument, lets have a conversation and to help lets bring Mark in on it.

After I had that chat I went back and re-watched the video again to see what MC was saying and I quote.



You can see what he is saying and eluding to here, the fact the problem on PS5 is to support this they needed the VF to enable that power from CPU to GPU shift.

As such ALL he is saying is that the process now is deterministic and even though an engine MAY need 256-bit instructions (not just AVX) it may be low to medium use. Nothing has changed here from that statement, other than the Die shot shows that some sacrifices here seem based on that being a lower level than other areas, which is exactly what he said.

Supporting 256-bit instructions IS NOT the same thing as supporting ALL 256-bit instructions.
 
Last edited:

Lysandros

Member
OK, you want an argument, lets have a conversation and to help lets bring Mark in on it.

After I had that chat I went back and re-watched the video again to see what MC was saying and I quote.



You can see what he is saying and eluding to here, the fact the problem on PS5 is to support this they needed the VF to enable that power from CPU to GPU shift.

As such ALL he is saying is that the process now is deterministic and even though an engine MAY need 256-bit instructions (not just AVX) it may be low to medium use. Nothing has changed here from that statement, other than the Die shot shows that some sacrifices here seem based on that being a lower level than other areas, which is exactly what he said.

Supporting 256-bit instructions IS NOT the same thing as supporting ALL 256-bit instructions.
So the term native 256-bit instructions isn't related to FPU width?
 
Last edited:

Lysandros

Member
It is.

He is basically saying one of the reasons to variable frequency is the native support for 256bits in FPU.
So to maintain the same power envelope when running 256bits instructions it drops the clock of the CPU if needed.
In that case a 256-bit FPU is needed in order to support 256-bit instructions natively (1x256-bit/single cycle), correct?
 

Elog

Member
Maybe I am the only one but I can read Cerny's speech as if he is saying that 'zen2 supports 256-bit natively', 'it consumes a lot of power', 'problem' and 'we decided to go in a very different direction'.

Could one not interpret that as if they stripped out the native 256-but code, i.e. that it is not supported natively but instead made into 2 clks of 128-bit code? Or maybe Sony has confirmed somewhere else that 256-bit code is supported natively?
 

ethomaz

Banned
Maybe I am the only one but I can read Cerny's speech as if he is saying that 'zen2 supports 256-bit natively', 'it consumes a lot of power', 'problem' and 'we decided to go in a very different direction'.

Could one not interpret that as if they stripped out the native 256-but code, i.e. that it is not supported natively but instead made into 2 clks of 128-bit code? Or maybe Sony has confirmed somewhere else that 256-bit code is supported natively?
If it was the case he should not say the "different direction" was the variable frequency.
 
Very nice. Thanks to share his complement.
OK, you want an argument, lets have a conversation and to help lets bring Mark in on it.

After I had that chat I went back and re-watched the video again to see what MC was saying and I quote.



You can see what he is saying and eluding to here, the fact the problem on PS5 is to support this they needed the VF to enable that power from CPU to GPU shift.

As such ALL he is saying is that the process now is deterministic and even though an engine MAY need 256-bit instructions (not just AVX) it may be low to medium use. Nothing has changed here from that statement, other than the Die shot shows that some sacrifices here seem based on that being a lower level than other areas, which is exactly what he said.

Supporting 256-bit instructions IS NOT the same thing as supporting ALL 256-bit instructions.
 
Last edited:

kyliethicc

Member
You can see what he is saying and eluding to here, the fact the problem on PS5 is to support this they needed the VF to enable that power from CPU to GPU shift.

As such ALL he is saying is that the process now is deterministic and even though an engine MAY need 256-bit instructions (not just AVX) it may be low to medium use. Nothing has changed here from that statement, other than the Die shot shows that some sacrifices here seem based on that being a lower level than other areas, which is exactly what he said.

Supporting 256-bit instructions IS NOT the same thing as supporting ALL 256-bit instructions.
Maybe I am the only one but I can read Cerny's speech as if he is saying that 'zen2 supports 256-bit natively', 'it consumes a lot of power', 'problem' and 'we decided to go in a very different direction'.

Could one not interpret that as if they stripped out the native 256-but code, i.e. that it is not supported natively but instead made into 2 clks of 128-bit code? Or maybe Sony has confirmed somewhere else that 256-bit code is supported natively?

Seems their thinking was -

If we did 256 bit instructions like on desktop PCs, we'd have to do XYZ, so instead we did things differently. Our box, our way.

I think its safe to say the PS5 is customized and handles things in its own way that fits the console's needs. Let the games talk.
 
Maybe I am the only one but I can read Cerny's speech as if he is saying that 'zen2 supports 256-bit natively', 'it consumes a lot of power', 'problem' and 'we decided to go in a very different direction'.

Could one not interpret that as if they stripped out the native 256-but code, i.e. that it is not supported natively but instead made into 2 clks of 128-bit code? Or maybe Sony has confirmed somewhere else that 256-bit code is supported natively?

That's how I read it, tbh.

His statement, 'we decided to go in a very different direction', is the key point to focus on. Adding in VF isn't a "very different direction", it's a band aid to the problem of AVX2 usage being so power hungry.

Seems like double-pumping 128-bit AVX to support AVX2 is the most likely case for the PS5. At the end of the day we're talking about a 3+ billion cycles per second processor. So using two cycles to complete an AVX2 instruction isn't nearly the end of the world and probably isn't meaningful.

Given how Intel basically FUBAR'd AVX usage on PC by their fragmented support across the range of CPUs, most multiplatform devs haven't and aren't likely to make too much use of the wider CPU vector extensions.
 

Elog

Member
Seems like double-pumping 128-bit AVX to support AVX2 is the most likely case for the PS5. At the end of the day we're talking about a 3+ billion cycles per second processor. So using two cycles to complete an AVX2 instruction isn't nearly the end of the world and probably isn't meaningful.
Looking at the data that I have seen power consumption increases exponentially for 256-bit instructions compared to 128-bit. If that is true there is no real advantage at all to use it in an environment that is limited by power and thermal such as a console.
 
Status
Not open for further replies.
Top Bottom