Infamous (E3 2007)

[archangelmorph]

I'm not sure about genji, but yeah, and I believe it is the only one. Anyways of course there will be flaws with what I said, but for the most part, yeah. None of these game designers are like, yeah, well, we're using the spu's but this time were only gong to use 30% and blatantly disable 4 spu's. That's all I'm saying.

Like, bizarre said they didn't use the full power of the 360, but everything was still utilized, just not utilized efficiently, ex. no tiling.

Utilising the whole of a system like the 360 at run-time and utilising all the SPUs of the Cell are two completely different things..

SPUs are very intricate and very complicated beasts to the unfamiliar and i'm sure there have been quite a few games which haven't utilised anymore than one or 2 of them (or even to any significant degree) to date..

It's not as easy as saying "well ok, lets just switch this function and that function over and get the speed up".. Care needs to be taken on how you use them, how you setup your data and send it to them for processing, what processing your going to do on them etc..

With most games released so far either being rushed (genji) or multiplatform titles (aka even more rushed) it's pretty reasonable to expect that most developers didn't have the time, resources, tools or support needed to fully get to grips with efficient SPU usage (see GI.biz and you'll notice that even Epic has been having problems adapting their engine to maximise the SPUs).. So it's a safe bet to assume that most ported their games to the PPE and RSX, dealt with stability issues and optimised for framing before considering how much time they had left to actually sit down with Sony and the hardware and learn how to start moving code onto them effectively without breaking the entire codebase (at leat buy that point in the development schedule, tools and support would have improved a little to reduce the learning curve and hopefully get even a few sub-systems up and running on an SPU or 2..)

Coding directly with the intent of using ALL the SPUs would require either excellent fore-knowledge of all your sub-systems and exactly how you intent to separate them into 7 hardware threads of execution, or a powerful, stable scheduling system setup to enable your entire engine load to scale easily between as many number of cores and software threads required.. Both solutions have extensive R&D, design and implementation implications of which make it obvious to see that many developers so far haven't opted to follow..

It's only now that we have guys like Ninja Theory & Media Molecule (working close with Sony), Naughty Dog, Guerilla Games and Insomniac that have both the experience, tools, support and expertise (not to mention time and money available) to put togther powerful game engines which really begin to exploit the hardware strengths of the PS3 and increase the utilisation of SPUs to perform heavy lifting tasks at a capacity that has never previously been possible on the console..

To try to infer that ALL games utilise ALL the SPUs to some degree is both ignorant of the underlying nature of the technology (and the principles and commonalities of practical & commercial games development) and misguided to be honest..

EDIT:

There's already a thread in the Console Tech forum on SPU Usage (by commercial developers to date) if anyone is interested in learning a bit more on exactly what PS3 developers are getting out of the platform and what they hope to achieve with it in the future..

 

[tha_con]

Utilising the whole of a system like the 360 at run-time and utilising all the SPUs of the Cell are two completely different things..

SPUs are very intricate and very complicated beasts to the unfamiliar and i'm sure there have been quite a few games which haven't utilised anymore than one or 2 of them (or even to any significant degree) to date..

It's not as easy as saying "well ok, lets just switch this function and that function over and get the speed up".. Care needs to be taken on how you use them, how you setup your data and send it to them for processing, what processing your going to do on them etc..

With most games released so far either being rushed (genji) or multiplatform titles (aka even more rushed) it's pretty reasonable to expect that most developers didn't have the time, resources, tools or support needed to fully get to grips with efficient SPU usage (see GI.biz and you'll notice that even Epic has been having problems adapting their engine to maximise the SPUs).. So it's a safe bet to assume that most ported their games to the PPE and RSX, dealt with stability issues and optimised for framing before considering how much time they had left to actually sit down with Sony and the hardware and learn how to start moving code onto them effectively without breaking the entire codebase (at leat buy that point in the development schedule, tools and support would have improved a little to reduce the learning curve and hopefully get even a few sub-systems up and running on an SPU or 2..)

Coding directly with the intent of using ALL the SPUs would require either excellent fore-knowledge of all your sub-systems and exactly how you intent to separate them into 7 hardware threads of execution, or a powerful, stable scheduling system setup to enable your entire engine load to scale easily between as many number of cores and software threads required.. Both solutions have extensive R&D, design and implementation implications of which make it obvious to see that many developers so far haven't opted to follow..

It's only now that we have guys like Ninja Theory & Media Molecule (working close with Sony), Naughty Dog, Guerilla Games and Insomniac that have both the experience, tools, support and expertise (not to mention time and money available) to put togther powerful game engines which really begin to exploit the hardware strengths of the PS3 and increase the utilisation of SPUs to perform heavy lifting tasks at a capacity that has never previously been possible on the console..

To try to infer that ALL games utilise ALL the SPUs to some degree is both ignorant of the underlying nature of the technology (and the principles and commonalities of practical & commercial games development) and misguided to be honest..

EDIT:

There's already a thread in the Console Tech forum on SPU Usage (by commercial developers to date) if anyone is interested in learning a bit more on exactly what PS3 developers are getting out of the platform and what they hope to achieve with it in the future..

It's a shame that there isn't a +rep feature on B3D, because this post definitely deserves it.

 

["Nerve-Damage"]

Archangelmorph nice post as always.

 

[Cheezdoodles]

SPUs are very intricate and very complicated beasts to the unfamiliar and i'm sure there have been quite a few games which haven't utilised anymore than one or 2 of them (or even to any significant degree) to date..

I wouldn't say SPU's are comlicated beasts. They aren't, there is still some uncertainty about how much they can handle of different tasks, but the main problem (this also goes for the X360) is that no developer had any real experience with programming for multiple cores prior to this gen.

This is more of an issue of learning how to properly delegate and manage each core rather than understanding the SPU's. Understanding how a SPU works is rather simple.

 

[phat]

I wouldn't say SPU's are comlicated beasts. They aren't, there is still some uncertainty about how much they can handle of different tasks, but the main problem (this also goes for the X360) is that no developer had any real experience with programming for multiple cores prior to this gen.

This is more of an issue of learning how to properly delegate and manage each core rather than understanding the SPU's. Understanding how a SPU works is rather simple.

Programming the SPUs definitely is quite a bit more than just learning (symmetric) multi-core/multi-threaded programming. Programming even a single SPU is more complicated than programming a single-core desktop CPU. The programmer needs to manually manage a very small local store, overlap computation with DMA transfers as much as possible, and organize his data in non-obvious ways to effectively harness the SPUs, because tossing naive C code at the SPUs will result in much worse performance than tossing naive C code at an Intel or PPC core.

 

[archangelmorph]

Programming the SPUs definitely is quite a bit more than just learning (symmetric) multi-core/multi-threaded programming. Programming even a single SPU is more complicated than programming a single-core desktop CPU. The programmer needs to manually manage a very small local store, overlap computation with DMA transfers as much as possible, and organize his data in non-obvious ways to effectively harness the SPUs, because tossing naive C code at the SPUs will result in much worse performance than tossing naive C code at an Intel or PPC core.

Thanks,

Ostepop - The problem isn't really an issue of understanding multi-threaded programming since its a field that been very active in other areas of software engineering for generations (not to mention it's a topic that most, if not all programmers learn at undergraduate level, well.. provided you've had a formal education that is..)

The biggest area is like phat mentioned, understanding how to implement your game systems around such and intricate and non-conventional platform which requires much more knowledge than simply throwing your renderer onto a second thread and buffering the data to be sent to it, which one could setup on the 360 (rather painlessly) for example and achieve pretty good performance out of it..

 

[Shifty Geezer]

Yes to the above two posts. Ostepop - you've underestimated the complexity of SPU. In essence they're simple processors simple to developer for, but the complexity comes from having to chuck all your old C libraries out the window because they don't run well, and re-engingeering whole new solutions to algorithms that are SIMDized and managed in LS. Kinda like a bicycle is a simple machine to ride, especially compared to a Formula 1 car, but you can't go from winning Formula 1 championships to getting on a bicycle and expecting to win races. You'll spend a lot of time just trying to start with the thing. Then you've got to learn to get rid of the stabilizers and ride for real, before you eventually learn a whole different skill set to win races.

 

[DeanoC]

Programming the SPUs definitely is quite a bit more than just learning (symmetric) multi-core/multi-threaded programming. Programming even a single SPU is more complicated than programming a single-core desktop CPU. The programmer needs to manually manage a very small local store, overlap computation with DMA transfers as much as possible, and organize his data in non-obvious ways to effectively harness the SPUs, because tossing naive C code at the SPUs will result in much worse performance than tossing naive C code at an Intel or PPC core.

Nope tossing standard C code at an SPU tends to run faster than standard C code on 'normal' in order processors.

Main difficulty is RAM size and DMA, but thats only a difficulty if you working set is >256KB. So if you want a simple life with SPU, keep your working set small

 

[phat]

Nope tossing standard C code at an SPU tends to run faster than standard C code on 'normal' in order processors.

Main difficulty is RAM size and DMA, but thats only a difficulty if you working set is >256KB. So if you want a simple life with SPU, keep your working set small

True. By "naive" C code, I was thinking of code that does arbitrary references to main memory, hoping that a software-controlled reactive caching scheme would make it all work transparently. Essentially, programming in C while being completely agnostic about the physical hardware. General-purpose CPUs are much better at (i.e. have much more HW support for) approximating this programming model than SPUs. Furthermore, the abilities that SPUs are strong at, namely, vectorized SIMD, are not at all captured by the C programming model.

 

[Carl B]

EDIT:

Ok, here is the lesson of this thread: private messaging does not make you immune from following the basic forum rule guidelines.

 

[Todd33]

At one point in the trailer you can see four of the same short haired chick with a white tank-top in the one scene running towards the camera at the bridge scene. Copy and paste FTW! :smile: