PlayStation 4 (codename Orbis) technical hardware investigation (news and rumours)

[Cjail]

@dagamer

Ah in that sense.
Sorry I clearly misread your post.

 

[Love_In_Rio]

I think that was conventional wisdom, but then his research showed that the legacy bloat has been cut back significantly and is hardly an overhead anymore, to the point where Larrabee could work with Atom cores that were hardly less efficient than anything else on the market.

The actual presentation is out there on Youtube and listening to his exact words is probably better than taking this summary from IGN. I listened through it, and vaguely remember his comments being along those lines (but with extremely little technical detail).

Didn´t Larrabee include Pentium 1 cores?. If so Pentium 1 was a very little bloated x86 chip. It all started after that with the MMX instructions ( Pentium MMX ).

 

[Arwin]

You are right, and actually, my comment does not make sense - Larrabee and related projects all used in-order cores. So it's more likely to be a conclusion that out-of-order performance of x86 cores has become so efficient that combined with the CU like compute resources, they are a valid alternative in both cost (I'm sure AMD helps here as well) and performance.

 

[MrSpiggott]

Looks like first parties didn´t want x86:

Having worked for years as a consultant for Sony Worldwide Studios, Cerny was one of the individuals who engaged with feedback developers provided for Sony's next console. The realisation that he should be more involved with the PlayStation 4 came to him after he spent his time-off researching the 30 year history of the X86 CPU, after feedback from first-party game programmers said it shouldn't be used in the PS4.

http://www.ign.com/articles/2013/07/10/how-mark-cerny-got-the-playstation-4-lead-architect-job

I think this is just a misunderstanding of a previous Cerny statement.
I believe it comes from a video that's discussed in the "Mark Cerny The Road to PS4" thread, Cerny says that historically developers weren't interested in x86 technology, due to some shortcomings, and it was his curiosity, as to why this was so, that made him carry out his research into the history of the technology which ultimately revealed that modern x86 processors are vastly improved and are perfectly suitable for consoles.

 

[Deleted member 11852]

I have confirmation that all 18 CUs are identical and can all be used in exactly the same way.
The 14+4 thing was just a suggested workload split presented to developers.

Wasn't this settled back in April in Mark Cerny's interview with Gamasutra, where he stated:

There are many, many ways to control how the resources within the GPU are allocated between graphics and compute. Of course, what you can do, and what most launch titles will do, is allocate all of the resources to graphics. And that’s perfectly fine, that's great. It's just that the vision is that by the middle of the console lifecycle, that there's a bit more going on with compute.

Looks like first parties didn´t want x86:

Having worked for years as a consultant for Sony Worldwide Studios, Cerny was one of the individuals who engaged with feedback developers provided for Sony's next console. The realisation that he should be more involved with the PlayStation 4 came to him after he spent his time-off researching the 30 year history of the X86 CPU, after feedback from first-party game programmers said it shouldn't be used in the PS4.

No doubt. When you suggest the x86 architecture then your average developer, folks minds flick back to when they last worked with 80x86 and the hell of supporting x87, IA-32, MMX, SSE, SSE2, x86-64, SSE3, SSSE3, SSE4, SSE5 and AVX. Nobody wants to have to do that. But in a console, you have just one architecture.

I still balk at the thought at having to write 80x86 code compared to POWER or even 680x0, but it's completely irrational. Nothing I'd have to support would be less than a x86-64 which reduces the headache significantly.

 

[brunogm]

http://lists.freebsd.org/pipermail/freebsd-amd64/2011-March/013740.html

Well basically Sony patched in AVX support in FreeBSD 9.0. Probably the patch received modifications and was accepted only on FreeBSD 9.1

 

[steveOrino]

I'd like to hear their reasonings. The early days of predicting the next-gen consoles didn't expect x86 IIRC. It comes with legacy bloat and from that perspective, is inefficient for the transistor count, plus I guess Intel tax increases the relative cost. However, regardless of validity of those arguments, that doesn't affect the first parties. Was it just that they were used to PPC and didn't want another ISA to worry about?

Personally I think Cerny is sugar coating. I don't think in an ideal world he would have wanted x86, but this all really boils down to cost. Its the only thing that would push them towards x86. APUs weren't a reality years ago.. so yeah, legacy bloat and ISA inefficiency are there but when you can get what amounts to an SoC from one manufacture + behind the scenes wheeling and dealing on licensing, those deficiencies are more than palatable.

Real issue with another RISC + discrete GPU setup is the GPU landscape and IP ownership. There are really only 2 dogs in the fight and those 2 dogs own a lot of patents and only 1 of them makes CPUs. Discrete processors do not make economic sense for these kinds of devices anymore.

 

[DieH@rd]

Looks like first parties didn´t want x86:

Having worked for years as a consultant for Sony Worldwide Studios, Cerny was one of the individuals who engaged with feedback developers provided for Sony's next console. The realisation that he should be more involved with the PlayStation 4 came to him after he spent his time-off researching the 30 year history of the X86 CPU, after feedback from first-party game programmers said it shouldn't be used in the PS4.

http://www.ign.com/articles/2013/07/10/how-mark-cerny-got-the-playstation-4-lead-architect-job

Cerny talked about this in his Barcelona speech [youtube it], but after years of research, he concluded that advancements in x86 arhitecture could provide good base for nextgen console.

 

[Deleted member 11852]

Personally I think Cerny is sugar coating. I don't think in an ideal world he would have wanted x86, but this all really boils down to cost.

As somebody who writes code for a number of architectures, where the choice of platform is entirely outside my control, I 100% agree with you.

Given the choice, as somebody who writes almost entirely in assembler, I'd pick POWER or 680x0/Coldfire (my personal preference) every time. ARM would be the last on my list. But I do wonder how many game devs, outside of engine or other middleware providers, write in assembler these days, because if you're using a higher level language and compiling to a target architecture you care a little less less about the specifics of the number of registers, how the CPU accesses memory, and I'm guessing game developers (as a team) write less low level code than ever before.

But I know my dislike of x86-64 is irrational. If I looked at it in purely a effort/deliverable performance angle, it's the obvious choice at this juncture.

 

[Arwin]

I also think several low-level developers on this forum have argued that out-of-order x86 cores would be better and easier in the past. I can't remember, maybe nAo was one of them?

 

[anexanhume]

http://lists.freebsd.org/pipermail/freebsd-amd64/2011-March/013740.html

Well basically Sony patched in AVX support in FreeBSD 9.0. Probably the patch received modifications and was accepted only on FreeBSD 9.1

Neat find. It could have been plain as day to sleuths over 2 years ago

 

[Shifty Geezer]

You are right, and actually, my comment does not make sense - Larrabee and related projects all used in-order cores. So it's more likely to be a conclusion that out-of-order performance of x86 cores has become so efficient that combined with the CU like compute resources, they are a valid alternative in both cost (I'm sure AMD helps here as well) and performance.

Sony could have gone with a potent OoO PPC/Power though. And Cerny was investigating x86, not HSA, and concluded it was okay (in 2007). So the complaints of the devs had to be regards x86 as they understood it back then. I expect many of Sony's first parties hadn't had decent experience with low-level x86 coding for long enough to not appreciate the architecture's potential, maybe, but I'm not really seeing the obvious issues with x86 nor what PPC could do better aside from tools and experience (and considering most folk are coding in higher level languages, I'm not sure what value x86 experience really brings anyway!).

 

[Deleted member 11852]

I also think several low-level developers on this forum have argued that out-of-order x86 cores would be better and easier in the past. I can't remember, maybe nAo was one of them?

I've never had to accommodate a x86 out-of-order execution architecture. Are they common? Aside of AMD's recent-ish, offerings like Bobcat?

 

[liolio]

I guess back in time X86 were lacking sane SIMD units, Altivec was a selling point for IBM. I don't know what MIPS was offering, but I think now that the point is moot.

 

[Arwin]

Here's what 3dilettante wrote in 2005:

Engineers working on the DEC Alpha pegged the general performance improvement in going OoO at about 50%.

If code can be statically scheduled well to match the underlying resources of a processor, then it is possible to match or better an OoO processor with an in-order if everything else is equal.

If the software is either too difficult or expensive to warrant the low-level optimization, then the OoO will probably do better.

It's all a trade-off. If the task is highly regular and predictable, an in-order can be given highly optimized code and possibly be clocked higher, since scheduling hardware in OoO is a serious drag on cycle times.

However, tasks that are more difficult to profile well in software due to branches or memory accesses that are hard or impossible to predict at compile time will lose out on an in-order.

It gets worse if unpredictable memory latency is involved. OoO processors tend to be more tolerant of a first-level cache miss that stays on-chip.

Programmers have relied heavily on OoO because its greatest performance improvements come on relatively unoptomized and legacy code. It's a problem for chip designers who have to make the extra hardware run fast.

It's different for every task.

Is it predictable/profilable?
Is it branchy?
Can it fit in cache?
Have compilers/tools advanced enough to optimize it well?
Do you have the time to hand-tune it?
Do you have the money to heavily optimize?

Media tasks like graphics especially can be run very well on optimized statically scheduled code. This is why Cell has so much fp power packed into in-order SPEs.

Gameplay code like AI is difficult to get scheduled right, which is why some programmers are unhappy about the PPE and Xenon cores.

It may not be impossible to get it scheduled in software, but nobody has lengthened development times to match the extra effort.

http://195.242.156.166/showthread.php?t=21610

Arguments about 50% better efficiency per core have since been made by several others here.

 

[ERP]

I guess back in time X86 were lacking sane SIMD units, Altivec was a selling for IBM. I don't know what MIPS was offering, but I think now that the point is moot.

The biggest things missing in older x86 cores was fine grain cache control, you couldn't choose to not write something to a cache or flush an individual cache line. But that was all fixed circa SSE3 or 4 I think.

Most of the x86 dislike now is all about the lack of orthogonality in the instruction set and it's all basically irrational.

 

[jonabbey]

The biggest things missing in older x86 cores was fine grain cache control, you couldn't choose to not write something to a cache or flush an individual cache line. But that was all fixed circa SSE3 or 4 I think.

Most of the x86 dislike now is all about the lack of orthogonality in the instruction set and it's all basically irrational.

Linus Torvalds regularly berates people over at the Real World Tech forums about that. His argument is that CISC instruction density is a good thing, that the transistor penalty for decoding x86 has long since ceased to be of any significance, and that the memory subsystem performance dominates over everything else, and that x86 is really quite good at that.

 

[brunogm]

Neat find. It could have been plain as day to sleuths over 2 years ago

Funny thing is in the FreeBSD thread about the PS4OS created after VGleaks pics, noboby mentioned the AVX patch from Sony. There is only especulation on last year 250k USD anonymous donation "may be" from Sony.

 

[steveOrino]

I guess back in time X86 were lacking sane SIMD units, Altivec was a selling for IBM. I don't know what MIPS was offering, but I think now that the point is moot.

I think it was more to do with memory costs at the time and how the architecture and system bus was designed around lots of cache and ram.

Going back to the PS2, the caches were really small, as well as system memory, so a very wide system architecture where you could continuously stream data in over a fat 128bit bus without breaking a sweat made a lot of sense economically. And to your point 128 bit SIMDs are alot more attractive compared to the Pentium 3.

Fast forward to now, the memory you can fit in a box for $399 is huge in comparison to the past... In fact I think this is the first time in console history (correct me if I am wrong) where the consoles have more memory then most if not all low end PCs and on the PS4 side you have 8 gigs of GDDR5 which you cant get in any PC I know of. So in the end I guess the improvements to x86 + extensions and the rise of APUs have made x86 very attractive.

 

[(((interference)))]

A thread on on NeoGaf details an interview with a company responsible for lighting routines on next gen seems to confirm that 7GB is available for gaming on the PS4...

Here's the article:

http://gamingbolt.com/xbox-one-ddr3...am-both-are-sufficient-for-realistic-lighting

It may just be the article is making an assumption without any confirmation from the Developer in question, but it is the first time anyone has put a figure on RAM availability AFAIK.

I've been told that the RAM reserve is not 1GB.

Don't know any more though.