1. x86 has been broken down longer than the CELL has existed, there are thousands opon thousands of developers that have experiance with the architecture. And x86 is designed to be developer freindly lessening learning curve. The CELL is still a pain to work on even if developers now have a good understanding of it's flaws and strengths and how to work around them, unless a lot of work was done to the base architecture that won't change.

2. Next gen engines are all built on PC, so are designed on x86. Frostbyte 2, UE4, Cryengine 3, Luminous etc are all already running on x86 CPUs.

3. Global Foundries already has a fab designed to produce 60,000 of 300mm wafers/month at 28nm and below in the future for AMD, Sony could piggy back off that with an AMD CPU allowing them to take advantage of their volume production and planned die shrinks that AMD are already bankrolling.

4. R&D work has already been done by AMD, Sony having to pay $500m+ to scale up the CELL is a bad thing.

... do you even know what you're talking about?

1. Cell uses RISC architecture, which was developed back in 1960, waaaay before your 'x86' instruction set. RISC is more efficient which is why its used for mobile devices and super computer. Flaws? You mean the inconvenience of having to write efficient code and have knowledge of memory management? Yeah, I know.. all the new grads come out knowing only Java, and have absolutely no idea what are pointers, stack or heap but news flash: Its not a flaw to design system that trade convenience for efficiency; hence all firmwares and hardware level code are written in C and not in Java or Python.

2. So what you're saying is that because someone built something for the next gen Civic, you should dump your Porsche for a Civic? Yes, I am comparing 'x86' to a civic because its 'common' and 'easy to use' whereas Cell is more like a Porsche, faster, more expensive and harder to use.

3. And why can't they 'piggy back off' that with new generation cell chips? The fact, they are already manufacturing Cell chips at 45nm and made commitment to reduce it to 32 nm back in 06. According to http://en.wikipedia.org/wiki/Cell_microprocessor_implementations:

"IBM could elect to partially redesign the chip to take advantage of additional silicon area in future revisions to make the size small. The Cell architecture already makes explicit provisions for the size of the local store to vary across implementations. A chip-level interface is available to the programmer to determine local store capacity, which is always an exact binary power. It would be feasible to double the local store to 512 KiB per SPU leaving the total die area devoted to the SPU processors roughly unchanged. In this scenario, the SPU area devoted to the local store would increase to 60% while other areas shrink by half. Going this route would reduce heat, and increase performance on memory intensive workloads, but without yielding IBM much if any reduction in cost of manufacture."

4. Where did this $500m come from? I didn't see it in their Q4 report that they spent that much on R&D on the new AMD chip. Again, they designed the Cell to be scalable in the first place. Jumping ship to R&D a conventional CPU, just waste the money and time used on Cell. They should maximize and push their technology to the limit before following the bandwagon of the new popular kid in town.

Do I know what I'm talking about? Probably about as much as you.

1. The problem with CELL is not RISC architecture it's SPEs with no hardware schedulers, in order execution etc. Dev time costs money writing code for the CELL takes longer than a traditional CPU, you can hand optomise every peice of code on an x86 CPU if you wanted too that is not an advantage of the CELL and the fact that you have too to get even decent performance is a flaw. Unless you have an unlimited budget easier is better than slightly faster execution, that is why game engines are written in high level languages like C++ instead of assembly even tho performance is worse. And most games have most of their high level logic written in a scripting language like Lua.

2. Your arguement was that engines are designed for CELL already, I pointed out that next gen engines are all designed on x86.

3. Because there is no next generation of CELL chips IBM stopped development... Next gen will likely start at 28nm not 32nm so that doesn't really help. PS3 is the only device still using the CELL.

4. AMD spend ~$1.5b on R&D every year, and they only release a new architecture every 4-5 years, even incremental upgrades like Piledriver cost a lot, that isn't counting the R&D that the Fab does for each new node. Tho I pulled $500m out of my ass. And all modern architectures are designed to be scalable but it still costs money to spin a new CPU even using the same architecture. Spinning a new CELL bassed CPU on a new manufacturing proccess would not be cheap to do. 

The CELL was a dead end, GPGPU replaced the need for the kind of high parallelism with lots of floating point performance on a CPU. And for everything else a x86 CPU runs circles around it. 

1.  All computer architectures are RISC.  All these "CISC" machines are just an emulated instruction set on top of a RISC set.  This made CISC machines slower as they had to emulate enhanced instructions.  You can put those extra instructions in hardware but it's very costly.  The big thing that Cell brought to the table was parallel programming, which is where the issues lied.  Though when you really look into the matter the PS2 is actually a far more difficult machine to program for than the PS3 ever was and those "Hard to develop for" excuses were just that, excuses (Poor ports actually came due to the different memory and shader architectures between Xenos and the RSX).

2. Next gen engines are designed on APIs, doesn't matter what you write them on you can always recompile them to other machines.  Makes even less difference now that everything has become GPU dependant.

3.  This is very unfortunate though.  Cell is a very well designed chip, and is still one of the more powerfull single processors out there.

4.  Cell is still powerfull and the second update that IBM made before scrapping the chip would still be more than sufficient for a CPU upgrade.  But you're right, no one is manufacturing them.

5.  Cell wasn't a dead end.  All those render farms you see in fancy movies are done with software solutions, it just gives companies like PIxar very flexible output.  But it comes at the cost of render time (An hour a frame I think they managed to get it down too).  It's just that performance vs flexibility won out and GPUs are starting to make their way down to CPUs instead of CPUs up to GPUs.  Going the GPU way down causes flexibility problems though.

Developer excuses or not, it doesn't take away from the fact that developers hated the architecture and that it was too dificult to develop for many devs or too time consuming to optimise properly. As Zarx pointed out, time taken for coding means a higher budget which makes it less favourable in a business sense too. It would be ridiculous for Sony to continually pump more R&D money into an effectively dead CPU that will simply result in numerous games that run poorly and disgruntle software developers, effectively damaging Sony-developer relations.

The alternative is a more traditional multi-core/multi-threaded CPU that developers understand, are comfortable working with and will keep costs down for all parties. Furthermore, with companies like NVidia and AMD already pumping R&D money into GPGPU, from a business sense there are only a few logical choices at this point but Cell isn't one of them.

Do I know what I'm talking about? Probably about as much as you.

1. The problem with CELL is not RISC architecture it's SPEs with no hardware schedulers, in order execution etc. Dev time costs money writing code for the CELL takes longer than a traditional CPU, you can hand optomise every peice of code on an x86 CPU if you wanted too that is not an advantage of the CELL and the fact that you have too to get even decent performance is a flaw. Unless you have an unlimited budget easier is better than slightly faster execution, that is why game engines are written in high level languages like C++ instead of assembly even tho performance is worse. And most games have most of their high level logic written in a scripting language like Lua.

2. Your arguement was that engines are designed for CELL already, I pointed out that next gen engines are all designed on x86.

3. Because there is no next generation of CELL chips IBM stopped development... Next gen will likely start at 28nm not 32nm so that doesn't really help. PS3 is the only device still using the CELL.

4. AMD spend ~$1.5b on R&D every year, and they only release a new architecture every 4-5 years, even incremental upgrades like Piledriver cost a lot, that isn't counting the R&D that the Fab does for each new node. Tho I pulled $500m out of my ass. And all modern architectures are designed to be scalable but it still costs money to spin a new CPU even using the same architecture. Spinning a new CELL bassed CPU on a new manufacturing proccess would not be cheap to do. 

The CELL was a dead end, GPGPU replaced the need for the kind of high parallelism with lots of floating point performance on a CPU. And for everything else a x86 CPU runs circles around it. 

1.  All computer architectures are RISC.  All these "CISC" machines are just an emulated instruction set on top of a RISC set.  This made CISC machines slower as they had to emulate enhanced instructions.  You can put those extra instructions in hardware but it's very costly.  The big thing that Cell brought to the table was parallel programming, which is where the issues lied.  Though when you really look into the matter the PS2 is actually a far more difficult machine to program for than the PS3 ever was and those "Hard to develop for" excuses were just that, excuses (Poor ports actually came due to the different memory and shader architectures between Xenos and the RSX).

2. Next gen engines are designed on APIs, doesn't matter what you write them on you can always recompile them to other machines.  Makes even less difference now that everything has become GPU dependant.

3.  This is very unfortunate though.  Cell is a very well designed chip, and is still one of the more powerfull single processors out there.

4.  Cell is still powerfull and the second update that IBM made before scrapping the chip would still be more than sufficient for a CPU upgrade.  But you're right, no one is manufacturing them.

5.  Cell wasn't a dead end.  All those render farms you see in fancy movies are done with software solutions, it just gives companies like PIxar very flexible output.  But it comes at the cost of render time (An hour a frame I think they managed to get it down too).  It's just that performance vs flexibility won out and GPUs are starting to make their way down to CPUs instead of CPUs up to GPUs.  Going the GPU way down causes flexibility problems though.

1. Like I said RISC was not the CELL's problem in facti it has nothing to do with the CELL's issues. What does CISC being emulated have too do with the problems of the CELL? Did I say CISC was faster? My arguement was that a traditional x86 was more developer freindly than the CELL.

2. True but the CELL is very much not freindly to that. Unless you write code specificly for it performance is terrible, which is one of the reasons many early games sucked on PS3. 

3. It's not really that powerful these days Xenon Phi runs circles around it. 

4. More powerful at a few things all of which a GPU does 10x better. 

5.I have said before in this thread the future is likely heterogeneous computing but the CELL won't be the template for that. For high end CGI flexibility will trump performance just like real time performance trumps flexibility. As soon as hardware acceleration was a thing games moved away from software renderers and they aren't going to go back any time soon, especialy now that GPGPU and programable shaders (and more recently compute and geometry shaders) have increased flexibility of rendering in a GPU such a huge amount.

1. Again, you are mistaking flaw for performance/Convience trade off. IBM didn't 'forget' to add in branch prediction or OOE, they designed the SPE to have a sepcific purpose which is to do FP calculation fast. Their design choice made it possible for SPEs to complement the GPU's performance which allowed developers to push the graphics beyond the GPU's specs. Thanks to Cell's 8 years of production, most if not all developers have dedicated compilers and game engines designed to make optimization for them.  If a developer 5 years down the road have to start 'hand optimizing' their code to get their desired performance, then you just effectively created a cpu with useless/bloated features.

2. Your point is going off on a tangent. Most developers like to use their own engine to avoid paying licence fee and they have free control on what the engine does. That is why, even tho Unreal 3 Engine was avialible, only a select games used it. Developers already have engines built from last 8 years of PS3 development, continue using Cell will mean a much lower cost for the 'next gen'. 

3. Wrong, first, IBM already developed a scaled up version of Cell called PowerXCell 8i back in 08 that does 102 GFlops, Highest end of Core i7 Extreme edition is only at 90 Gflop and it consumes twice as much power. Second, the next gen is 22nm and how many chips are in 22nm? Unless they started devloping in parallel with Ivy bridge and Power8 chips, most likely start at 32nm for the next gen and go down to 22nm as they age.

4. Did you pull that $1.5b from your ass too? It takes 8-10years to create a new architecture from scratch, but its cheap to create scaled ones.. just look at corei7, it came out first then they scaled it down to make it affordable and that didn't take long.

 As someone who did CUDA programming, I can tell you that you know nothing about GPGPU. Cell IS a hybrid of GPU and a conventional CPU. In fact, the way you copy memory from the GPU cache for your 'task' is almost the exact way you would do it in Cell.