Official CELL Speculation Thread

Sonic

Senior Member
Veteran
Post your speculation here and argue away. Try to avoid starting a new thread unless it is warranted with relevant information that this thread fails to provide. This thread's use is for CELL discussion and speculation in general. Try not to get too hostile with it. I understand there are opposing sides on CELL, each going to the extreme. One extreme should please try to present their arguments in a clear and concise manner and stop running around in circles and posting redundant arguments that prove nothing but invalidate your point.
 
God damn GOOD MAN SONIC.

I told JVD to unlock the official PS3 topic and sticky it ages ago. This so ONLY PS3 STUFF would go into that topic, and anyone who made another topic about PS3/CELL would have that topic deleted.

Hell I still think this is a viable idea.. Infact you can make a Official Xbox2 one and N5 one, and sticky both also.

But this will do.
 
I say it´s going to be an architecture.

I second that ;)

Oh and I know this has little to do about Cell but more PS3.. But I'll post them anyway ;)

PS3_ACE_DIAGRAM_FINAL.jpg


ps3_GT_diagram.jpg


ps3_tekken_diagram_copy.jpg


Ps3_FF_diagram_copy.jpg


Just take them at face value, I know a picture or two maybe off.
 
Ick, I hope 3rd gen is better than that, I'm usually over picky about image quality, but in some ways, those 3rd gen pictures may be worse than 2nd gen, and even in the ways they are better, it doesn't look significantly so from those pictures. That's more like from ps2 to radeon 9800.
 
C'mon, the 3rd gen shots still look good, though (the improvements are in the fine detail). I certainly wouldn't be disappointed to play in-game scenes like that! I think if 3rd gen shots were distinctive only because they have heavy visual effects way overdone, that would not be the greatest thing.
 
The first gen shots are barely recognizable as anything.(well, the tekken one I could recognize as a person, but the hair makes it lose major points)
The 2nd gen shots of the plane and car are already at what most people could mistake for real, with the fighter being 90's cgi quality.

As for the final fantasy pics, well from one to the other, there are more hair strands, maybe a few thousand more polygons to round out the detail, some nice lighting in the background, and heavy gloss.

The 3rd gen plane seems to have its detail in polygons rather than textures, though I think the engine thrust out the back looks a bit fake, and the whole plane has a very plasticy look. Boring background too.
The car would be impressive if every detail is fully modeled with polygons, but even if it is, I don't expect 3rd gen to go that way, highly detailed bump mapped textured will be the preferred method of graphics. Plus, non living things(especially when they're not too complex) are easier to make real looking, so we'll see real cars before people. Anyhow, maybe with a bigger pic I could tell better, but those are the kind of graphics I'd expect out of a PC right now.
The zombie tekken picture is not a huge improvement over the other one, especially since the other one has a fully detailed background while this one doesn't. Eh, it is better than what we're seeing in doom 3 though, so I suppose it's good, but for a fighter, we could probably see something like this on one of the current gen systems.
Eh, anyhow, I'm expecting the different between the 2nd and 3rd gen to be at least as great between those 3rd gen pictures and what we get as the difference is between the 2nd gen pictures and the 3rd gen picutres. We won't get a psx to ps2 difference, but since psone sort of just missed the 3d standard, the difference wouldn't seem as great between a voodoo 1 game and final fantasy 10, or even a n64 game and final fantasy 10...or a better looking psx game. Bleh, sure the 3rd gen pictures have lots of fine details the others don't, but this aren't needed if they require a minute to look at the picture to see.(yay, I'm following nvidia's example)
Eh, but then again maybe I'm wrong, and the improvements this gen won't be so much textures and polygons as they are animation. It is such a rare but wonderful thing to see a finely animated game, rather than one with just enough animation to be passable.
 
Re: ...

DeadmeatGA. How about you do the bandwith to absolute computation ratios of contemporary GPUs instead of CPUs. Which would be much more realistic seeing as though the Broadband Engine will be targetted at the dynamic media/high preformance 3D market.

Hell, those Ops add up quick in tasks that lend themselves to a high degree of concurrency, don't they? Like take Bilinear Filtering, that's 12 additions & 16 multiples (28 Ops) per pixel. Or the ~50GFlops in Shaders in 2002/2003 lvl 3D GPUs - it sure adds up fast when your not hemmoraging transistors to get around that Von Neumann bottleneck and instead invest them in concurrency.
 
...

One extreme should please try to present their arguments in a clear and concise manner and stop running around in circles and posting redundant arguments that prove nothing but invalidate your point.
How can my arguement not be any more clear and concise than that? Hell, it was nothing but a bunch of FLOPS/memory bandwidth ratios of various CPUs. Put them back on.
 
...

Anyhow, Here is my response to Fox5's question.

Xbox P3 : 3 GFLOPS / 1.06 GBs = 3 FLOPS/byte
Gecko : 0.97 GFLOPS / 1.3 GBs = 0.74 FLOPS/byte

The rule of thumb is that anything over 1 FLOP/byte is a waste of FPU, since FPU will never get enough data to run at full speed.
 
...

Here is a repost of what was deleted.

FLOPS/memory bandwidth ratio(Lower the better)

SH-4 : 1.6 GFLOPS/0.8 GBs = 2 FLOPS/byte
EE : 4.8 GFLOPS/2.4 GBs = 2 FLOPS/byte
PSP : 2.6 GFLOPS/2.6 GBs = 1 FLOPS/byte
Earth Simulator : 8 GFLOPS/32 GBs = 0.25 FLOPS/byte
BGL : 5.6 GFLOPS/22 GBs = 0.25 FLOPS/byte

CELL(DM version) : 32 GFLOPS/25 GBs = 1.3 FLOPS/byte
CELL(Sony fan version) : 1000 GFLOPS /25 GBs = 40 FLOPS/byte
 
Re: ...

Development Agreement
January 6, 2003

CONFIDENTIAL

----------

DEVELOPMENT

AGREEMENT

BY AND AMONG

SONY COMPUTER ENTERTAINMENT, INC.

AND TOSHIBA CORPORATION

AND

RAMBUS INC.

----------

{PAGE}

Development Agreement
January 6, 2003

TABLE OF CONTENTS

PAGE
----

SECTION 1. DEFINITIONS.........................................................2

1.1 Rambus Interface Technology.........................................2

1.2 Redwood Rambus Interface Technology.................................2

1.3 Rambus Interface Specification......................................2

1.4 Redwood Rambus Interface Specification..............................2

1.5 Compatible..........................................................2

1.6 Yellowstone Rambus Interface Technology.............................2

1.7 Yellowstone Rambus Interface Specification..........................3

1.8 Yellowstone Rambus DRAM.............................................3

1.9 Other Agreements....................................................3

1.10
[*] Product.........................................................3

1.11
Broadband Engine....................................................3

1.12 Confidential Information............................................3

1.13 Redwood RAC.........................................................3

1.14 Yellowstone RAC.....................................................3

1.15 RAC Test Chip.......................................................3

1.16 Control.............................................................3

1.17 Subsidiary..........................................................4

1.18 Affiliate...........................................................4

1.19 Effective Date......................................................4


SECTION 2. TECHNOLOGY IMPLEMENTATION AND PROMOTION.............................4

2.1 Technology Implementation Deliverables..............................4

2.2 RACs................................................................4

2.3 Yellowstone RMC.....................................................5

2.4 Connector Designs...................................................5

2.5
Package Designs.....................................................6

2.6
[*] Test Chip.......................................................6

2.7 Consultation Obligations of Rambus..................................6

-i- CONFIDENTIAL

{PAGE}


TABLE OF CONTENTS
(CONTINUED)
PAGE
----

2.8
Use of Yellowstone Technology and Redwood Technology in
Broadband Engine
....................................................6

2.9 Liaison.............................................................7

2.10 Use Restrictions....................................................7

2.11 Disclaimer..........................................................7

2.12 Certain Termination.................................................8

2.13 Escrow..............................................................8


SECTION 3. DEVELOPMENT FEES....................................................9

3.1 Development Fees....................................................9

3.2 Withholding Taxes..................................................13


SECTION 4. CONFIDENTIAL INFORMATION...........................................14

4.1 Confidential Information...........................................14

4.2 Confidentiality....................................................15

4.3 Exceptions.........................................................16

4.4 Residuals..........................................................17

4.5 Additional Responsibilities........................................17

4.6 Subsidiaries.......................................................17


SECTION 5. INTELLECTUAL PROPERTY OWNERSHIP AND INDEMNIFICATION................18

5.1 Ownership..........................................................18

5.2 Rambus Indemnification Disclaimer..................................18

5.3 Toshiba Indemnification Disclaimer.................................19

5.4 SCE Indemnification Disclaimer.....................................19


SECTION 6. LIMITATION OF LIABILITY............................................19


SECTION 7. TERM AND TERMINATION...............................................20

7.1 Term...............................................................20

7.2 Termination........................................................20

-ii- CONFIDENTIAL

{PAGE}

TABLE OF CONTENTS
(CONTINUED)
PAGE
----

7.3 Survival...........................................................21


SECTION 8. GOVERNING LAW, DISPUTE RESOLUTION..................................22

8.1 Governing Law......................................................22

8.2 Dispute Resolution.................................................22


SECTION 9. MISCELLANEOUS......................................................23

9.1 Confidentiality of Agreement............................. .........23

9.2 Assignment.........................................................24

9.3 No Conflicts.......................................................24

9.4 Authority..........................................................24

9.5 Notices............................................................24

9.6 Electronic Transfers...............................................25

9.7 Export Controls....................................................25

9.8 Partial Invalidity.................................................26

9.9 No Third Party Beneficiaries.......................................26

9.10 Counterparts.......................................................27

9.11 Relationship of Parties............................................27

9.12 Modification.......................................................27

9.13 Waiver.............................................................27

9.14 Government Approvals...............................................27

9.15 Section Headings and Language......................................28

9.16 Ambiguities........................................................28

9.17 Force Majeure......................................................28

9.18 Currency...........................................................28

9.19 Entire Agreement...................................................28

-iii- CONFIDENTIAL

{PAGE}

-iii- CONFIDENTIAL

{PAGE}

Development Agreement
January 6, 2003

DEVELOPMENT
AGREEMENT

This Development Agreement (the "Agreement") is entered into as of the Effective Date, by and among Rambus Inc., a Delaware corporation with principal offices at 4440 El Camino Real, Los Altos, California 94022, U.S.A. ("Rambus"); and Toshiba Corporation, a Japanese corporation with principal offices at 1-1 Shibaura 1-chome, Minato-ku, Tokyo 105-8001 Japan ("Toshiba") and Sony Computer Entertainment Inc., a Japanese corporation with principal offices at 1-1 Akasaka 7-chome, Minato-ku, Tokyo 107-0052 Japan ("SCE").

WHEREAS,
SCE and Toshiba have entered into a joint development agreement (the "[*] Agreement") with [*] to develop a broadband microprocessor (designated as the "Broadband Engine") for a [*] product;

WHEREAS, Rambus has developed and is developing certain logic-to-logic interface technology currently designated by Rambus as "Redwood Rambus Interface Technology," and certain logic-to-memory interface technology currently designated by Rambus as "Yellowstone Rambus Interface Technology ";

WHEREAS, together with this Agreement, Toshiba and Rambus are entering into a Redwood and Yellowstone Semiconductor Technology License Agreement of even date hereof (the "Toshiba License Agreement");

WHEREAS, together with this Agreement, SCE (together with its parent company, SONY Corporation) and Rambus are entering into a Redwood and Yellowstone Semiconductor Technology License Agreement of even date hereof (the "SONY License Agreement"); and

WHEREAS, the parties desire to cooperate with each other to enable SCE and Toshiba (and [*] as SCE's sublicensee) to implement Rambus'
Redwood Rambus Interface Technology and Yellowstone Rambus Interface Technology as the bus interfaces in and with the Broadband Engine (and related [*] designed to [*] to the [*] on the terms and conditions set forth herein;
 
...

And your point is??? 25 GB/s is the peak bandwidth of Yellowstone. The ideal FLOP/bandwidth ratio is 1:1 or lower. Think why NEC and IBM are sticking with 0.25 FLOPS/byte ratio. Hell, an 8 GFLOPS SX-6 CPU has far more memory bandwidth than your imaginary 1000 GFLOPS processor.
 
Re: ...

DeadmeatGA said:
The rule of thumb is that anything over 1 FLOP/byte is a waste of FPU, since FPU will never get enough data to run at full speed.

You do realize this arbitrary definition is entirely incorrect in tomorrow's 3D visualization world of long shaders/microprograms?

Already you can see cases (in the NV3x and R3x0) where the GPU is FP bounded when executing shader programs, not bandwith bounded as your argument would have us believe.

I believe this trend toward computational limitations, not bandwith, will only increase with the current direction of the industry towards more, longer shaders and more on-die logic constructs such as a PPP which works on topology. The demand for the same increase in external bandwith to support a given preformance level has died in the 3D world.

Tomorrow's 3D world will see the bulk of the processing happening at a low level on-die, where register size and absolute amount is a key metric of preformance (look no further than NV3x) as well as the ability to rapidly move data around (look at Keith Diefendorff's writing) - both of which the Broadband Engine excels in with it's busses and ondie RAM hierarchy... the same one you mysteriously neglect to talk about.
 
...

You do realize this arbitrary definition is entirely incorrect in tomorrow's 3D visualization world of long shaders/microprograms?
CELL is not a GPU. It does not/should not run shader programs. If the design goal of CELL was to run a vertically integrated rendering processes from geometry generation all the way down to pixel rendering, then this is definitely a flawed approach, somethings are better done in hardware than software.

The demand for the same increase in bandwith to support a given preformance level has died in the 3D world.
But Yellowstone can deliver only 25 GB/s. In other word, the capacity and bandwidth of Yellowstone memory subsystem will determine the true capability of CELL. Remember why the real supercomputer manufacturers provide lots of bandwidth for their designs.
 
Re: ...

DeadmeatGA said:
CELL is not a GPU. It does not/should not run shader programs. If the design goal of CELL was to run a vertically integrated rendering processes from geometry generation all the way down to pixel rendering, then this is definitely a flawed approach, somethings are better done in hardware than software.

What?!? I distress... this is futile with you this close minded. You have no vision, no concept... Even a [highly sexy - heh] ATI engineer agreed that an APU could run a shader program damn well.

Unless you can explain how an APU differs from, say, a R3x0 Vertex Shader. And is superior in flexibility of what it can or can't run (as you seem to think an APU can't which is so very obtuse).

But Yellowstone can deliver only 25 GB/s. In other word, the capacity and bandwidth of Yellowstone memory subsystem will determine the true capability of CELL. Remember why the real supercomputer manufacturers provide lots of bandwidth for their designs.

Did you actually read what I wrote? You're so very wrong.
 
Back
Top