How powerful are you expecting Cell to be

One thing I don't get about the workstation is how it will apply to the PS3's hardware when better movie CGI is created.I'm guessing the workstation will be upgraded alone with a newer console every generation.That way the console is able to handle what ever CGI the workstation is able to duplicate/copy from studio hardware to its hardware in the very same way the GScube works.
 
nAo said:
ERP said:
True to a point, but the issue with Cell as I see it for parlellising these tasks is the realtively small memory window for each of the PE's. Your not going to be able to run something that requires random access to a large (multimegabyte datastructure) efficiently on a PE.
You really don't want to access a large data structure on any console.
As long as a PU has a L2 cache and an APU can transfer data from there there is not much to worry about.

I think that larger continuous worlds and significant improvements in AI are going to require accessing large datastructures. I believe this is where the real gameplay potential is in the next gen consoles .

This is one of the reasons I keep saying flops are only one part of the performance picture.
 
ERP said:
I think that larger continuous worlds and significant improvements in AI are going to require accessing large datastructures. I believe this is where the real gameplay potential is in the next gen consoles .

This is one of the reasons I keep saying flops are only one part of the performance picture.
I understand your concerns, but we have spatial data structures to keep the random accesses cost on 'enormous' data structures low. Maybe you're worried about the cost to update such hiereachical structures, but like Mfa pointed out, there's is room to 'hide' those costs on a large number of concurrent query/updates.

ciao,
Marco
 
My current application is somewhat extreme in terms of the way it utilises memory and the CPU.

IMO The size of the supposed PE EDRam is small enough to seriously limit their application. Maybe I'm missing the big picture, and the solution will be obvious when we get boxes, but for now it concerns me.
 
Well, I suppose that there are probably quite a lot of applications which justify the amounts of cache rumored to be on die with many upcoming multi-core CPUs. It seems that as far as these approaches go within a fixed transistor budget, there are

CPUs : smallest number of cores, the most cache.
Cell : average number of cores, average amount of local storage
GPU : many "cores", least amount of cache, least flexible.
 
psurge said:
CPUs : smallest number of cores, the most cache.
Cell : average number of cores, average amount of local storage
GPU : many "cores", least amount of cache, least flexible.

Makes sense.

CPU with most cache (within budget) to support as much universal apps and/or approaches. (serial)

Cell is sort of mid-ground, from a specialised foundation heading towards more programmable/generic approach. (hieratical parallel approach)

GPU => Specialised H/W for one purpose, graphics. (more *extreme* flat parallel approach).
 
Back
Top