Does DD2 signify a problem with Cell?

Sorry I wasn't being clear. In the other thread (Cell programming for game server) :)
the IBM guys ported a traditional code to run on Cell using PPE to manage all the SPEs. I was thinking to push this approach further... how would the numbers change if they'd just move some/most/all of that work to one of the SPEs.

Wrong thread. But yeah am waiting eagerly for DD4.5. ;)
 
patsu said:
Sorry I wasn't being clear. In the other thread (Cell programming for game server) :)
the IBM guys ported a traditional code to run on Cell using PPE to manage all the SPEs. I was thinking to push this approach further... how would the numbers change if they'd just move some/most/all of that work to one of the SPEs.

Wrong thread. But yeah am waiting eagerly for DD4.5. ;)


No way to tell and the reason they didn't move it to the SPE's is because it was not as simple as just recompiling.

The SPE's have limited local memory and this is the single biggest limitation on moving algorythms to them. If the code and data do not fit and cannot be easilly streamed then it can be a lot of work to move something to an SPE.
 
patsu said:
Sorry I wasn't being clear. In the other thread (Cell programming for game server) :)
the IBM guys ported a traditional code to run on Cell using PPE to manage all the SPEs. I was thinking to push this approach further... how would the numbers change if they'd just move some/most/all of that work to one of the SPEs.

Hopefully we'll find out, it sounds like they're continuing to work with it.

One of the key areas for change that they identified seemed to be to reduce the SPEs' dependency on the PPE for feeding it data. There is no need for such a dependency, but it was precipitated by their particular approach.
 
Right. I hope they will open source the code for others to play around because it is very frustrating after reading the paper, raising tons to questions, dreaming up approaches, knowing the various challenges and then you can do nothing about it.

Some of these approaches are deadends for sure (even before implementation)... but to me it's also interesting/valuable to quantify "What not to do", especially when these approaches are evolutionary from traditional practices. This is of course in the light of Cell's "newness".
 
aaronspink said:
BLAH - 1 BLAH
BLAH BLAH - 2 BLAH
BLAH BLAH BLAH - 3 BLAH
I think the last line should be "BLAH BLAH BLAH - 4 BLAH", but overall, I agree with you aaron (and thats the first time in one year since I'm reading in this forum ;) )
 
Originally Posted by ADEX
Any truth in that? 4 instructions per cycle implies the PPE either got replaced again or at least underwent major changes.

Please read versions posting history before taking anything he posts seriously.....

That's why I put a question first!

That said IBM do have a new 4 issue core in the works which is designed for high frequencies and has already taped out.
 
aaronspink said:
BLAH - 1 BLAH
BLAH BLAH - 2 BLAH
BLAH BLAH BLAH - 3 BLAH

Oddly, that's exactly what I see when I read any of your posts.

(apologies to the mods for this unnecessary post... I couldn't resist.)
 
Megadrive1988 said:
any chance that the PS3 Cell is one of the DD3.x revisions ?
Aren't they already in PS3 devkits? Since that version is for better yields, it's certain that they use a version more suitable for mass production just like many revisions of Emotion Engine.

Over at the IBM Cell forum they say they'll release CBE Handbook which has detailed info of PPE, maybe available at the PS3 release.
 
Megadrive1988 said:
any chance that the PS3 Cell is one of the DD3.x revisions ?

If we are to believe DD3.x revisions are to improve yields, then I imagine the fact that PS3 will be consuming a lot of Cells had a heavy hand in its creation. I think it would be a safe assumption that it'll be there.
 
Hmm, We know transmeta was working on a low power version of Cell.
I wonder will that be ready in time, if so they could up-clock the Cell...

Each die revision will cost $ millions so you can assume it wont be done unless there is a very good reason for it, be that yield improvement, performance, bug removal or whatever.
 
I'm still not sure I'm buying that DD2-->DD3 revision is *just* for yields... that seems more a DD3-->DD3.1 type thing, but hey whatever. ;)

We'll know more when that handbook's released I imagine.
 
ADEX said:
Hmm, We know transmeta was working on a low power version of Cell.
I wonder will that be ready in time, if so they could up-clock the Cell...

The Transmeta technology is pretty much just a reverse bias technology. The primary benefit of it is lowering idle and non-peak power. For peak power, which is the critical issue inside a console as far as peak frequency, it does very little.

Aaron Spink
 
xbdestroya said:
I'm still not sure I'm buying that DD2-->DD3 revision is *just* for yields... that seems more a DD3-->DD3.1 type thing, but hey whatever. ;)

We'll know more when that handbook's released I imagine.
What exactly can be donw to improve yields without (presumably) changing the underlying structures, such as adding redundancy? I don't understand how a redesign can improve yields. :???:
 
Shifty Geezer said:
What exactly can be donw to improve yields without (presumably) changing the underlying structures, such as adding redundancy? I don't understand how a redesign can improve yields. :???:

Spread/separate the PPE's redundant logical units amongst or adjacent with the SPEs?

If a PPE is concentrated in one area (ala DD1/2) and is the area of the chip that got the defect, then that's 1 dead Cell chip.
 
Jov said:
Spread/separate the PPE's redundant logical units amongst or adjacent with the SPEs?

If a PPE is concentrated in one area (ala DD1/2) and is the area of the chip that got the defect, then that's 1 dead Cell chip.

That would lead to high tracelengths.
 
Back
Top