Slashdot Mirror
Sony Ditching Cell Architecture For Next PlayStation?
RogueyWon writes "According to reports in Kotaku and Forbes, Sony is planning to ditch the Cell processor that powered the PlayStation 3 and may be planning to power the console's successor using a more conventional PC-like architecture provided by AMD. In the PS3's early years, Sony was keen to promote the benefits of its Cell processor, but the console's complicated architecture led to many studios complaining that it was difficult to develop for."
Won't buy it. They screwed us with Linux on the PS3. Their consoles are done in this house.
We all know Sony will just remove the cell processor functionality in a few updates time.
You know, there is a difference between trolling and pointing out the flaws in your reasoning. Just saying.
Probably. But they'll probably use a POWER7 based CPU instead of an AMD x86 CPU. Given how much Cell influenced POWER7, I'd actually say that's a huge likelyhood they'd go POWER instead of x86.
Non impediti ratione cogitationus.
If game programmers dislike the Cell, why can't they just convince their bosses to target their next project at PC and Xbox 360 instead of PS3 and Xbox 360?
$.
TOKYO, Japan -- Sony released their heavily anticipated and much hyped Playstation 4 Entertainment System today, but the games are nowhere to be found. Developers agree the hardware specs are extremely impressive, but nobody knows how to actually make games for it. Thankfully, the latest member of this venerable line of consoles is backwards compatible with the games of all previous generations.
"I think we got it perfect this time," says Sony chairman Kaz Hirai, "we expect our internal studios won't figure out how to make games for at least another few months. Third party developers should take even longer. We figure the PS4 should be hitting its stride right when the PS5 hits the market several years down the road."
How difficult will it be to develop games for that one? When asked the question, Hirai rubs his hands together, a gleeful smile spreading across his face.
"Impossible."
I programmed a Cell processor (for HPC, not gaming) a few years ago, and it was definitely a pain in the butt compared to just targeting a multi-core x86.
The problem, at least back then, was that you had to write explicit code to have the various cores communicate with each other (DMA transfers, etc.)
I imagine compilers/libraries/SDK's have improved the situation since then, but really the modest performance premium offered by the chip just wasn't worth the hassle.
$$$ more like. Contracts -- Sony locks in games as Sony exclusives for much moola (so do Nintendo and Microsoft).
-GiH
You mean like how you could run all those Xbox games on your PC?
"I use a Mac because I'm just better than you are."
I've shipped PS2 games and worked with numerous developers that have shipped PS3 games.
Sony's problem is the Not-Invented-Here syndrome. They have yet to learn the lesson that Apple mastered years ago in the 80's -- use off the shelf commodity parts!! Why? They will become DIRT cheap in a few years. Why waste millions of dollars investing into R&D of new hardware when in 5 years somebody else will have a no-name version of it at a fraction of the price??
e.g.
Sony is _slowly_ learning this lesson. After how many man-years of a buggy PS2 GS (Graphics Synthesizer) that couldn't even properly do z-tesing (!?!/!) the PS3 RSX is (mostly) a GTX 7800+
http://en.wikipedia.org/wiki/RSX_'Reality_Synthesizer'
When the PS2 first came out everyone bitched how difficulty it was, yet it was a beautiful thing to see all of its 7 CPUs working full speed load-balancing the system. It laid the foundation that multi-core programming was the future. When the PS3 came out everyone bitched how even more difficult it would be. Developers just sucked it up and now we are even seeing A.I. running on the SPE/SPUs on second-gen and 3rd-gen PS3 games! That's pretty cool to see a modern game engine utilizing every core it can.
Using stock parts: CPU + GPU is a great way to minimize costs. You don't get the same performance benefits of true dedicated design but the commodity parts are cheap enough that the pricing curve naturally takes care of that. Kind of a no-brainer if Sony decides to use an AMD or Intel CPU for the PS4.
References:
See: PS3 games list & SPE usages
http://www.neogaf.com/forum/showthread.php?t=184843
i.e.
and
Game developers too stupid to deal with complex systems.
Sorry, but 'it's complex hardware' excuse pissed me off.
Right. Because parallel programming on a processor with completely manual cache management is just so easy. The supercomputer people find it tricky too.
I guess you're just so much smarter then everyone else.
SJW n. One who posts facts.
As a game developer who has made a game for the 360 and PS3, I can tell you that my biggest complaints about the ps3 were the memory limitations (cpu and gpu memory is separated), the horrible software for the devkits, and the devkits themselves, which suck so much power that they require you to run air conditioning even in the winter.
The main difference that you hit when making a cross-platform title is DirectX (d3d) versus OpenGL ES. Those libraries need to understand the lowlying architecture, but they pretty much take care of everything for the developer.
Free unix account: freeshell.org
Remember the launch? IBM, Sony and Toshiba were going to put Cell processors in everything from cheap consumer electronics to number crunching supercomputers. In reality, IBM sold a few Cell blades, Sony put one in each PS3 and that's about it.
I am TheRaven on Soylent News
Good parody. When I think about the PS3's processor, I always remember them bragging at launch that devs will still be trying to optimize for the PS3 when it's lifetime is over. I'm still astounded that they thought that was something to brag about.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
> Not being a game developer I wonder what game devs would prefer,
You are asking two questions:
What do game devs prefer for software?
What do game devs prefer for hardware?
When I used to work with PS3 developers -- they almost _always_ lead their development on the XBox 360. It was _very_ rare was it to see a studio lead on the PS3 -- but those that did -- tended to have a better engine for load-balancing at the end of the day (it is easier to scale down, then scale up.)
Easier: Multi-Core --> Few-Core (PS3 --> Xbox360)
Harder: Few-Core --> Multi-Core (XBox 360 --> PS3)
Microsoft is a software company,
Sony is a hardware company.
The tools MS provided were _perceived_ as being easier and better. (I can and will not comment on the reality.)
WRT hardware, game devs appreciated the power the PS3 + SPUs even if it involved the crap load of work to get it running 100% load-balancing. Having to worry about LHS (Load-Hit-Stores) was a total PITA for PS3 developers -- memory access was pretty much ignored on the XBox 360. The bigger problem was Sony using a 64-bit OS (all pointers were 64-bits !!) when the dam console only has 512 MB address space?!?! This kind of "Sony ignorance/arrogance" being out of touch with developers was not uncommon.
PC + Xbox Developers tend to want a AMD/Intel approach to hardware for _ease of _use. Sony / Nintendo developers tend to prefer multi-core / dedicated CPUs for everything for _performance_.
One or the other isn't wrong -- just a different focus.
The trouble with the Cell processor is that there's not enough memory per processor. Each of the little processors (the "SPE" units) in the PS3 only has 256KB of RAM. That's not enough to store a frame. It's not enough to store a game level, or a significant amount of geometry. It's more like having a number of DSPs available.
This forces redesigning the program to work in batch mode. A batch job is one frame, but it's still a batch job. Data for one frame cycle is sequentially pumped through one or more SPEs. There's not much random access, because access to main memory from an SPE is in big blocks, transferred in the background.
This is both limiting and a huge pain. Especially when the competition is selling shared-memory multiprocessors. I used to do game physics engines, and when the PS3 came out, my reaction was "I'm glad I sold off that technology and got out of the business." I knew some people at Sony's SCEA R&D center, and they basically threw all their smart people at trying to figure out how to use the Cell effectively. Many of the early games really ran in the main CPU, with the SPEs managing things that didn't affect gameplay, like particles for fire, explosions, smoke, and such.
If each SPE came with a few megabytes of RAM, instead of only 256K, it wouldn't be so bad. Then you could probably have the physics engine in one CPU, the AI in another, the background object management in a third, and so on. But each of those things needs more state than whatever fraction of 256K is left over after the code is loaded.
There's a long history of Cell-like architectures in the supercomputer field. The BBN Butterfly, the NCube Hypercube, and the Connection Machine also consisted of a large number of processors, each with a small memory. None were successful. One of the lessons of multiprocessing computer architecture to date is that the two extremes - shared memory multiprocessors and networked clusters of separate computers - are useful. None of the partially-shared machines have been successful. The Cell is the only one ever to be mass-produced.
Great for audio, though. The audio guys like having their own processor, and audio processing really is a streaming process of tight loops without much state.
I'll join you on the Sony SDKs being horrible. I still think the SN debugger is the best debugger I've used for multithreaded debugging. I'd also venture that you weren't a particularly serious PS3 dev house if you were using Sony's GL implementation, we ditched that shit the second GCM became available.
The Cell architecture itself isn't difficult to program for, Sony just screwed themselves by coming out a year later then the 360. The big issue is that developing parallel software on the 360 is in a homogeneous environment. Game devs (myself included) started building engines around those constraints. After we had 360 devkits for a year or so, Sony comes by with PS3s and they are different at a fundamental level. We already have over a year of engine design and development into the 360 and we have commitments on both consoles. Now what? You can't afford the time to throw it all out and re-design from the ground up. It also didn't help that Sony's SDK was completely in flux before the launch - and for some time after. The end result is any game that wasn't first party was a horrible compromise on the PS3 at first. As time went on we changed large parts of our engine to be more PS3 friendly and it helped quite a bit. It also didn't help that the PS3's GPU is about 15%-25% slower on average and that the OS takes up a bunch more memory then the 360's does.
All in all, the PS3 was a clusterfuck for the first few years and still hasn't recovered.
While fitting the game into the local and main memory is a pain it can usually be mitigated by proper planning. Developing your memory footprint for PS3 can immediately be translated to the 360's unified memory but going the other way is a special hell. While it's true that some engines are main memory intensive that you have to resort to crazy tricks (like streaming your audio from local memory to main) in general it's not too bad as there aren't two different implementations.
But going from 3 ppu cores to 2 ppu cores and 6 spus does cause a problem if you're anywhere near utilizing the CPUs. Generally it's easier to optimize the game until as much as possible runs on 2 ppu cores and specific tasks run on the spus (as the 360 gains the benefit from the optimizations too).
It sounds like you haven't worked on the PS3 in a while. Sony has actually stepped up the game and the ps3 sdk actually surpasses the xdk in some regards. Most of the complaints I hear about the ps3 sdk are more related to windows oriented people not understanding the unix mindset. And the ps3 dev kits are now tiny and sleek and not the 2U heater units of old.
The PS3 has probably provided the biggest software leap in game architecture in the last 3 years. This is in comparison to typical XBox or PC platform. I argue this only because the forced paradigm shift to fully utilize the Cell architecture should be directly transferable to multi threaded programming on an 8 core AMD/Intel processor.
Programming SPUs is really very unlike programming on a 'normal' multi-core processor. Experience with the six hardware threads available on the Xbox360 is going to be more useful on multicore PC CPUs than experience with the Cell.
I used to program SPUs for a living for a game studio. (Worked on SOCOM Confrontation and some unannounced titles).
I disagree with all this bitching from devs: the CELL SPU is a thing of beauty.
If an engineer is worth his salt, and knows his trade well, what he can do with it is amazing.
I was blown away with how incredibly fast this SPU is, once properly used.
But only if you know how to do branchless code, and you know the difference between structures-of-arrays and arrays-of-structures.
Once the data is lined up properly, and you eliminated those nasty branches, carefully crafted code (intrinsics, not vanilla C++) will make that thing fly like nothing else. Insanely fast, think GPU-fast, but with a more generic programming model.
I regret the death of the Cell architecture.
Bram Stolk http://stolk.org/tlctc/
I agree with you. Sony made good products.
FTFY
It's a Sony used to be a sign of quality. Nowadays it's a stigma and a representation of our disposable electronics society.
What are 'all the low level details' you refer to?
The main difference is the separate address space of the small local memory of the SPU.
I believe linux on Cell has made some nice abstractions. ./a.out | ./b.out | ./c.out > output.txt
It's been ages since I ran ps3linux, but from what I heard you can execute filter like objects on the SPU from the OS level.
Thus:
$ cat intput.txt |
This would put 3 SPUs to work, and do the DMAing for you.
You would need to lookup the status of OS-level support for SPU on linux to get more info on this.
Personally, I did the DMA stuff manually.
What you cannot abstract away, is the data-oriented programming that you should be doing.
As Noel Llopis puts it so eloquently: You need to program your entire game as if it was a particle system.
http://gamesfromwithin.com/data-oriented-design
e.g. for 1024 particles, you do:
float x[ 1024 ];
float y[ 1024 ];
float z[ 1024 ];
and NOT:
struct
{
float x,y,z
} particles[ 1024 ];
Bram Stolk http://stolk.org/tlctc/