Does Cell Have Any Other Advantages Over XCPU Other Than FLOPS?

expletive said:
Sorry i wasnt clear, the reason i brought up physics, AI was to point out examples of things that would NOT be bound by the GPU and instances where the 'more always=better' for CPU power might be valid. For me though, i odnt really believe we'll see large enough differences in those things from system to system (in the upcomign console gen) for a mjaority of the people to notice or care.


Exactly, my argument is necessarily about theoritcal capabuilities but more like real world scenarios.
 
It's not difficult to gobble up CPU power. If for a given game with the GPU running flat out and only 10% of the CPU in use, all that remaining CPU time could probably be quite quickly used in some procedural content creation like adding perlin noise to dirty of scenes, beef up the AI interactions, increase the fidelity of the fluid dynamics and add more detailed properties in the rigid body simulation, be used adding cloth dynamics with wind effects instead of pre-animated flags. It's very easy to add more and more physics without needing more GPU power and without adding anything to development costs. Heck, just up the sampling rate! I don't think for too long devs will be looking at next gen CPUs and saying to themselves 'hell, we've got too much power. What on earth are we going to spend it on?'
 
Titanio said:
I don't know what Renderware does. But then EA uses it, and not many others anymore. Obviously there must be hardware-specific implementations, however, otherwise the code just won't work. I'm sure you can within the confines of Renderware also get down and talk to the hardware more one-on-one too, and I'm sure it's done.
It all depends on the compilers. Those are the only hardware specific parts of the SDK package but the high-level functions remain the same.
They're not exactly exemplars of next-generation development. They're basically the same games as on the other systems, but with better graphics/animations, minus some features in some cases. Next year's versions will get a lot more attention - wonder why?
Don't get your hopes up. If you expect EA to overhaul their next gen engine again just for the PS3, then you're a bit naive. EA will always be EA.
 
Alpha_Spartan said:
Don't get your hopes up. If you expect EA to overhaul their next gen engine again just for the PS3, then you're a bit naive. EA will always be EA.


Maybe EA have always built the engine around the PS3. That's a logical assumption to make. I can't prove it though.
 
avaya said:
Maybe EA have always built the engine around the PS3. That's a logical assumption to make. I can't prove it though.
Yes it is. That would help to prove my point that EA will have no incentive to overhaul it.
 
Shifty Geezer said:
It's not difficult to gobble up CPU power. If for a given game with the GPU running flat out and only 10% of the CPU in use, all that remaining CPU time could probably be quite quickly used in some procedural content creation like adding perlin noise to dirty of scenes, beef up the AI interactions, increase the fidelity of the fluid dynamics and add more detailed properties in the rigid body simulation, be used adding cloth dynamics with wind effects instead of pre-animated flags. It's very easy to add more and more physics without needing more GPU power and without adding anything to development costs. Heck, just up the sampling rate! I don't think for too long devs will be looking at next gen CPUs and saying to themselves 'hell, we've got too much power. What on earth are we going to spend it on?'

You think its going to be much different from the PC space now where a majority of the games are GPU limited?
 
expletive said:
You think its going to be much different from the PC space now where a majority of the games are GPU limited?

Do you know what this means?

If anything, when a game is GPU limited, assuming your performance is OK, it allows you to bump up your CPU tasks (to a point - beyond that point then your game becomes CPU limited).

It has nothing to do with the GPU placing a limit on how much the CPU can do. If just means your CPU isn't the bottleneck with framerate - so you can get your CPU to do more without affecting that framerate (up to that point mentioned above).

It's when you are CPU limited that you think about cutting back on what you're doing on the CPU - if your performance isn't acceptable.
 
Last edited by a moderator:
version said:
Barry_Minor :

IBM's SPE XLC compiler is adding the function to compile to register ranges which would enable the threading model I talked about. We have coded examples of this in SPE asm to validate the concept.

The multi-threading example you sited is another way to cover up DMA latency (the most common being multi-buffering). This can be implemented in software on the SPEs by segmenting the large register file into smaller ranges, compiling different threads for each register range, and switching (branching) to a different thread after each thread issues a DMA read. The threads stay resident in local store (no context switching), thread switching is light weight (1 cycle branch), and with some clever programming you can even defer the switch based on the DMA tag being ready (BISLED). If you're memory bound and can't predict your memory references ahead of time this is a good solution as you could write your code for size instead of speed and pack 4-8 threads in each SPE local store.

This is THE MOST interesting post I have yet seen about Cell. Thanks for sharing that.

Just to make sure I understand correctly.

These threads are like library threads in a single task on an SPE right?

If so then the OS's scheduler would have no knowledge of them and thus the programmer would need to craft their own scheduling scheme but of course that is the point in such a scheme? (XLC will allow for partitioning of an SPE's register file and then how threading is handled falls on the programmer...right?)

Threading on a finer scale such as this could go a long way in aiding Cell's overall effeciency...err...keeping Cell busy.

This is the most interesting thing I've seen in a long time. Not SW threads but that it was plausible or even practical to do this on Cell's SPEs. That large register file certain seems a good thing now. In contrasting the plausibility of such schemes being employed with Xenon I assume it's because Xenon's cores smaller register file preclude such from being practical to implement. However, Xenon still is efficient in how it's cores interleave thread execution to avoid DMA stalls and can issue 2 instructions from one thread instead 1 instruction from 2 threads in such cases.

How this relates to efficiency and programmability makes this the most interesting thing I've seen to date...to bad I'm not learned enough to explore my this interesting topic on my own :(
 
Last edited by a moderator:
expletive said:
You think its going to be much different from the PC space now where a majority of the games are GPU limited?
In addition to Titanio's explanation, you can basically divide a game into working stuff out and drawing stuff. Sometimes the CPU helps with the drawing stuff. When it's not it can work out stuff like physics and AI. If a lot of CPU time is given over to graphics, that gives you less time for other things, and vice versa.

In the case you raise, where the software is GPU limited, meaning it's hit the limits of that the GPU can do and there's CPU cycles going spare, that means more stuff you can get the CPU to do. If you write your game with 100 enemies on a battlefield and 42 flags waving in the wind using fixed animations, and the GPU is giving it everything it's got and the CPU is hardly breaking a sweat, you can rejig your program to animate the flags as cloth dynamics, and so use all that power. In the case software is CPU limited, and the GPU is sitting there not being used to the max, you can either up the graphics a bit, or live with it. It's not like you can set the GPU to adding fluid dynamics on flags (or can you...*mysterious oo-ah noises* :oops: )

So really I can't see that there's excess of CPU power. If the CPU's not being used fully it's not because the GPU is limiting the chances it has to be used. IUt's not as though the moment you hit the limit of your vertex setup hardware you can't use the CPU for anything more.
 
Titanio said:
Do you know what this means?

If anything, when a game is GPU limited, assuming your performance is OK, it allows you to bump up your CPU tasks (to a point - beyond that point then your game becomes CPU limited).

It has nothing to do with the GPU placing a limit on how much the CPU can do. If just means your CPU isn't the bottleneck with framerate - so you can get your CPU to do more without affecting that framerate (up to that point mentioned above).

It's when you are CPU limited that you think about cutting back on what you're doing on the CPU - if your performance isn't acceptable.

Shifty Geezer said:
In addition to Titanio's explanation, you can basically divide a game into working stuff out and drawing stuff. Sometimes the CPU helps with the drawing stuff. When it's not it can work out stuff like physics and AI. If a lot of CPU time is given over to graphics, that gives you less time for other things, and vice versa.

In the case you raise, where the software is GPU limited, meaning it's hit the limits of that the GPU can do and there's CPU cycles going spare, that means more stuff you can get the CPU to do. If you write your game with 100 enemies on a battlefield and 42 flags waving in the wind using fixed animations, and the GPU is giving it everything it's got and the CPU is hardly breaking a sweat, you can rejig your program to animate the flags as cloth dynamics, and so use all that power. In the case software is CPU limited, and the GPU is sitting there not being used to the max, you can either up the graphics a bit, or live with it. It's not like you can set the GPU to adding fluid dynamics on flags (or can you...*mysterious oo-ah noises* )

So really I can't see that there's excess of CPU power. If the CPU's not being used fully it's not because the GPU is limiting the chances it has to be used. IUt's not as though the moment you hit the limit of your vertex setup hardware you can't use the CPU for anything more.

Yes i understand it to be exactly as you describe. Yet a majority of the 'showcase' games in the PC world are GPU limited. Doesnt that mean that developers have limited inclination to do the types of things you both discuss CAN be done with spare CPU power? Why do you think this is the case?
 
expletive said:
Yes i understand it to be exactly as you describe. Yet a majority of the 'showcase' games in the PC world are GPU limited. Doesnt that mean that developers have limited inclination to do the types of things you both discuss CAN be done with spare CPU power? Why do you think this is the case?

Because most games are targetting a wide range of machines, and have to be able to accomodate lower end CPUs. But I should note that it is not rare that you'll hear people complain about certain games being CPU-limited and so forth, when it comes to benching graphics cards.
 
Herb Sutter (big cheese in the C++ world, works for MS) has posted a presentation outlining some ideas for the future of C++.
http://216.55.183.63/pdc2005/slides/TLN309_Sutter.ppt?ticket=&id=

The interesting bits for me is the stuff about concurrancy, extending C++ to handle multi-threading is a great idea and if they do it right, just might make programming in future possible.
From a console point of view, the interesting bit is how they can leverage this on X360 and its follow up. Sony don’t have these kind of software researchers, whereas MS spend a fortune figuring out how to make software, it may well pay off big time for next (and next-next) gen consoles.

Fundementally its bloody hard to program for next gen consoles, on PS3 you have lots of tasks because of the hardware design with all the headaches of concurrent programing (synchronisation, seperate memory pools, etc). X360 is a little easier, partly because its got fewer hardware threads and that they are symetrical, but also because its got MS Visual Studio compilers for it, OpenMP makes it easier to create worker tasks to distrubute across hardware threads. Now for this generation, Cell isn’t too complex, so doing all the thread in a manner similar to Herb’s WindowAPI example (near the end of that presentation) is okay (obviously PS3 doesn’t use Windows API, it uses CellOS API calls that do a similar thing) but what happens when we get hardware threads in double figures?
If a future console was to have 30+ hardware threads, the winner of that generation won’t be who has the most flops but who can write a compiler that helps you out. I’m don’t believe it will ever be ‘automatic’ (at least for the foreseeable future) but being able to add ‘active’ to a class etc. would be a god send.

MS have a real ace up there sleave with Visual C++, GCC just isn’t upto the same level at the moment. I bet the size of MS Visual C++ team is bigger than all the paid GCC contributors put together…

If I were Apple or Sony, I’d start spending serious cash on compiler research very very soon, else MS might just win the future of IT by being the only people able to supply the tools capable of using future processors…

You guys should really read Deano's Blog
 
HL2 is a good of a developer making physics a priortiy in a game just as an example.

However I think there are good reasons why physics, and AI haven't taken off to date on PCs.

Mainly because the power wasn't there to do it. If developers had the inclination to do fluid dynamics in a game or 100 enemies on screen with complex heuristics for both group and individual 'AI' they would probably be met with a lacking for power in the HW to tap into.

Desktop CPUs to date are not designed with these kinds of tasks as their primary focus. AI is an exception in that it's needs fit in nice with what allot of other common PC code demands. Word doesn't need uber flop power. Games do. However gamers are the vocal minority so when a CPU is designed we get secondary units in CPU to quell our outcries for power...we do not CPUs designed with out demands as the central focus. SSE/VMX/3DNow are all great additions and they do make it easier for developers to meet gamer's needs but as far as over arching design goes the needs of the business world and even the typical user...a gamer not...are what modern desktop CPUs are designed for.

The other half of the picture is the reality of the making PC games. PCs are not fixed spec machines and so developers must try to seek a balance with what users can run and what they try to implement in games. The major factor being that the 'experience' the game provides should as best possible not be affected by the HW a user has. For instance, one user with uber HW being able to to blow up a water tower and watch as water washes his enemies away due to fluid dynamics and another user not being able to do this because their HW can't handle fluid dynamics is something to be avoided. (I understand many things can be faked...other things cannot) The point is even if PC HW was available that allowed for uber physics it would also have to be so common in gamer's rigs as so developers could expect it to be there and thus it would be safe for them to craft their games around it. This is still a long way off though I think these next gen consoles will be catalytic in moving things forward more rapidly.

This is stark contrast to Xenon and Cell. These are the FIRST CPUs to my knowledge to be designed completely from the ground up with the needs of the gamer in mind or for that matter users that need serious computational power. The second thing to consider is that Cell and Xenon CAN be targeted for uber physics, graphics aid or what have you because it is guaranteed to developers that they will be in every system. With this knowledge I suspect the inclination to use them will be very high for a developer given others will if said does not, and if anything history shows console developers do code to the HW and attempt to take advantage of it as best they can.

Sorry for my long post, but I just wanted to chime in on why I thought that only recently physics etc has been a focus in games and also why I think they will be a focus especially on consoles.
 
Last edited by a moderator:
scificube said:
Mainly because the power wasn't there to do it. If developers had the inclination to do fluid dynamics in a game or 100 enemies on screen with both group and individual complex heuristics they would probably be met with a lacking for power in the HW to tap into.

Desktop CPUs to date are not designed with these kinds of tasks as their primary focus. AI is an exception in that it's needs fit in nice with what allot of other common PC code demands. Word doesn't need uber flop power. Games do. However gamers are the vocal minority so when a CPU is designed we get secondary units in CPU to quell or outcries for power...we do not CPUs designed with out demands as the central focus. SSE/VMX/3DNow are great additions and they do make it easier for developers to meet gamers needs but as far as over arching design goes the needs of the business world and even the typical user...a gamer not...are what modern desktop CPUs are designed for.

...

This is stark contrast to Xenon and Cell. These are the FIRST CPUs to my knowledge to be designed completely from the ground up with the needs of the gamer in mind or for that matter users that serious computational power. The second thing to consider is that Cell and Xenon CAN be targeted for uber physics, graphics aid or what have you because it is guaranteed to developers that they will be in every system. With this knowledge I suspect the inclination to use them will be very high for a developer given other will if said does not and if anything history shows console developers do code to the HW and attempt to take advantage of it as best they can.

Sorry for my long post, but I just wanted to chime in on why I thought that only recently physics etc has been a focus in games and also why I think they will be a focus especially on consoles.

Kind of related to this, an MS guy on AVS was saying that his dual-core PC can only decode one HD stream while maxxing out CPU utilization. I think he said he also has hardware assist for decoding too. They were playing around with PIP features.

Now contrast that to the demo of how many dozens of MPEG2 streams with the Cell?

So we are going to get a lot of FLOPS to spare compared to PCs but lets see how much developers use them.
 
Well his encoding/decoding software may be what limits him to only playing with one HD stream at a time, but as far a what could be called raw power it is not unexpected that Cell would have an advantage over a dual core chip at this present moment. Cell simply has more execution units and thus has more to toss at such a task. I would expect Xenon to also perform better at this particular task for the same reason.

I seen a rumor that suggest Intel is developing a chip along the same philosophies as the Cell chip and perhaps in time we the vocal minority can finally be appeazed. A Cell like design with OoOe and better branching should be enough to put a smile on anyone's face...let's see if Intel is really doing this and if they make it happen without me needing to buy a peltier cooling solution. It just a rumor I say in passing though and of course it's one should take with a barrrel full of salt.
 
Just thought I'd post this quote that I seen of GAF. It shows that Sony's first party must be doing something right.

I was just watching G4TV and Geoff Keighley was interviewing Gabe (not sure if this is a new episode, so sorry if old, but they're talking about the X360 launch lineup so I imagine it must be recent). Nothing really new or interesting on Valve's own end, but Gabe's comment on next gen was interesting to me; he restated his distaste with multi-threaded game developement, and how almost nobody in the industry knows what advantages it will bring, but I was surprised when he commented on Naughty Dog, saying that of all the developers he's talked to, they're the dev that is the furthest along in the developement of multi-threaded games.

To nAo and the other devs working on PS3 games, have you guys been hearing the samething? If so why are they so much further along in multi-threaded games than the rest of the dev community?
 
mckmas8808 said:
To nAo and the other devs working on PS3 games, have you guys been hearing the samething? If so why are they so much further along in multi-threaded games than the rest of the dev community?

I ain't a PS3 dev, but many would consider their PS2 engine to be amongst the best out there, if not the best. They're very very talented, technically. Their deep PS2 experience and knowledge undoubtedly gives them a leg-up here too. I can't wait to see their stuff.
 
scificube said:
HL2 is a good of a developer making physics a priortiy in a game just as an example.

However I think there are good reasons why physics, and AI haven't taken off to date on PCs.
.....

.....
Sorry for my long post, but I just wanted to chime in on why I thought that only recently physics etc has been a focus in games and also why I think they will be a focus especially on consoles.

I agree with most of this and its partly my fault for bringing PCs up in the first place but i think the initial discussion was around whether or not the differences between Xenon and Cell are significant - i.e. 'what are we going to do with all these extra flops'. My point was that if there is in fact such a disparity (after you figure in actual peak performance, development complexity, etc.), the features that would come from that probably wouldnt be things that 95% of the general public would notice or care about.

I brought up the PC space as an example of a gaming market where the hardware maxes out the GPU and in a lot of cases leaves CPU cycles idle rather than fill then with neato effects. One reason is becuase of the disparity of computing power available, so is it worth it to cater to a smaller portion of the amrket (i.e. the scneario above where cell is definitely more powerful as a gaming cpu than xenon). Another reason is becuase these are things that end up costing development time, and therefore money, and are things which are perceived to not drive game sales.
 
Last edited by a moderator:
Back
Top