Hironobu Sakaguchi's opinion of cell and PS3

http://en.wikipedia.org/wiki/Hironobu_Sakaguchi

 

DSP stands for Digital Signal Processing. Calling the SPU/SPE of the Cell processor a DSP isn't a very accurate definition.

 

He's a producer in a company that outsources all of its programming.

 

Did Kutaragi sleep with his wife? Run over his cat? Someone seems to have a personal axe to grind.

 

That does make his opinion somewhat suspect, but still understandable. There are some issues with cell that are frustrating. First was the complete lack of tools and help, although Sony has been coming on strong in that department recently. Second, if you depend on a long standing codebase, code that you've been using for 20+ years, you can basically toss it to the trash as both the code and how your data is arranged needs to be totally changed to accomodate cell.

Those first two points are more inconveniences though that anything else. I think the real problem here, and why you won't see the PS3 leapfrog the 360 in cpu power is because they only put one cell in there. It was designed to work together with other cells so it seems like an odd choice to only include one, although it could be because the cost of including bluray blew the budget so they had to make do with one. The spu's may be faster than the three tweaked vmx units included in the 360's ppu, but you still only get ~5.9 or so spu's at most available, mostly likely somewhat less because you need them to help the rsx. Plus, there are some odd ommisions here and there. For example, the vmx units on the 360 can do a hardware quad word dot product which as far as I can see is not available on the PS3's ppu or spu's (why?!?).

I'm speculating here, but I think the real payoff for Sony and cell will come with the PS4. Right now a new cpu architechture, new tools, new media format, etc, is hurting them big time. When the time comes for the PS4 to come out I think their short term pain will yield great dividens. Bluray will be dirt cheap by then, so that cost issue is gone. Cell will be well established and understood, and people will have new cell specific codebases established so that learning curve will be gone or greatly diminished. Plus, costs will let them almost certainly including multiple cell's in there and yields will be much better, so its possible there won't be a 'dead' spu in each cell. At that point, with established code, good helper tools and libraries like spurs, and 20+ spu's to hurl code at, I think cell will finally shine.

 

lol that might explain it

 

You should go to the other thread about the Cell processor: http://forum.beyond3d.com/showthread.php?t=39552

 

I don't feel that such specific case examples are as relevant to game performance as people would think. It's like someone building a test app on PS3 or 360, and using it to extrapolate real world game performance to compare both machines. It just doesn't work that way, there is so much more going on. In a real world example, all chunks of code are fighting for the same cycles, memory, dma, cache, etc. The only way is to find out real world game performance is to code, optimize and run a real game on the actual hardware, then compare.

Just to make one clarification, I do think in it's lifetime that the PS3 will eclipse the 360 in cpu power. What I meant by the 'leapfrog' comment is that I don't think people will see the 10x-20x leap in performance that it seems people are expecting.

 

But it's not just SIMD vs VMX though. The SPUs have Local Store, async DMA (and of course more cores instead of fake threads), so are you taking advantage of them ? What about the 2 PPU threads and the VMX on PS3 ? You didn't mention them at all

 

You have to use local store on the spu's if you want to take full advantage of them, I assumed that was a given. Yes, you can also mostly absorb the dma gets/puts as well. The vmx units on the 360/PS3 ppu's are not quite the same, the ones one the 360 have some extra instructions. Also, you get 3 vmx units on the 360, only one on the PS3. The 'fake threads' as you say are not as useful as has having actual cores, but they are still effective. Plus, you can leverage the gpu on the 360 to do tasks that have to be done on the spu's on the PS3 as we have found out in our game.

 

Maybe it's not such a bad thing to put aside code which is over 20+ years old and start from the ground up?

You know, how the marketers are always claiming about next-gen games?

 

Yeah... but the moment you can hide the latencies, prevent stalls on SPU, the local store's small latency should be a performance booster right (even without using the SIMD instructions) ? You even have 5.95 of them . On top of that, you have 5 to 6 SIMD engines at your disposal.

I know Xbox 360's 3 VMXs are extended, but Cell's VMX and 2 PPU threads are not useless too . So they should come in handy sometimes.

Overall you should have more than enough computing power on hand to do some magic.

One question I have is the reserved SPU... if you can talk about it... is it used to service any calls at all (e.g., some OS utilities) ? Or it's totally partitioned away from the game run-time (e.g., running some sort of secure kernel).

 

Essentially, you guys are accusing him of being a corporate shill because you don't like what he's saying.

While ignoring that he bashes MS marketing pretty hard, and praises the Wii quite a bit.

 

Didnt see any bashing (I actually saw possitive remarks regarding MS in general) but thats irrelevant

There is no denial Cell is complex. There have been many detailed articles on that. But saying Cell is low-powered without anything to back it up is more suspicious than anything. Low powered compared to what and why? Especially when taking into consideration benchmarks and other developer comments regarding its performance that contradict that statement.

 

I think DSP is a very appropriate description of the SPUs. They share many important common strengths (like fast local pools of memory, fast vector MACs) and weaknesses (poor control code performance, huge penalties/complications when the local memory isn't large enough). The differences are in the details: DSPs often contain accelerators for communications applications (e.g., viterbi engines) whereas the SPUs are tailored for graphics (e.g., wider vector operations).

Phat

 

Yeah, and I can remember back when our paychecks (actually more like envelopes of cash) were signed by the same guy; he had pretty much the same opinion about the PS2 didn't really mean much in the end... Granted while he liked CD-ROM, he wasn't particular fond of the Playstation either (mainly because of the transition to 3D and the effect of artistic style (i.e. going w/Nomura and Yuuki vs. Amano (who he's friends with) and Toriyama who he's a fan of)))...

That's not entirely accurate. Ken's not a big software guy and usually defers a lot of that to others (which is one of the reason's guys like Tim Schaff were hired).

If you've got significant amounts of 20+ year-old code you're still using, then you've got other issues; at least as far as console space goes (PC, YMMV). In console space however, if you've got code that can make it through 10 years, you deserve a serious comendation... Seriously, I thought it was bad enough that we hacked 4 year-old animaton code from the Playstation to the PS2. Even more important, platforms are going to change (sometimes in a rather drastic matter). It's a fact of life as long as consoles have been around, and it's something you have to learn to adapt to.

I would have to disagree. You don't need a second Cell to see siginificant just vs. the 360 with regards to CPU power. Yes it'll take some time, but it'll eventually get there.

Other Cells are merely an option, ergo it was designed to interoperate with a variety of external devices that a vendor may wish it use (e.g. CPM modules along the lines of QUICC). If there had been such a strong emphasis on designing Cells to work strictly with each other, then there wouldn't have been a need to build so much support for non-coherent I/O. Nor do you do something like cutting a significant component (like a theoretical second Cell) just because another component is costlier than anticipated.

Because Microsoft wanted to spend the transistor budget on it (not to mention Cell predates Waternoose)? Since Cell isn't just strictly for the PS3, I can understand IBM (for example) not wanting to stuff a performance bottlenecking instruction that would prematurely brickwall the scalability of the processor. So I'd hardly call it an "odd" ommission; rather more of a concious design choice.

 

I see, so we can't do dot products on SPUs, right? and ask you this question: how many cycles does a VMX unit need to perform a dot product?
And also..how many cycles that VMX units need to perform a 3 components or 2 components dot product?

 

IIRC that was not an ommision per se, it was an addition to Xenos.

And there was a discussion on here before that the hardware support for dot products is only an advantage when your data is in AoS format. If you use the SoA format for your data (as is encouraged on the PS3 platform anyway) then it's not really a win.

 

I don't know why there would be any need to discuss this opinion of Sakaguchi's at all. He's a game designer, producer and director.
I mean, in the same interview he says that he has a hard time differentiating X360 and Wii graphics on his SDTV...