How much % acceleration is Cell for RSX

[Shifty Geezer]

Thanks Shifty...It was just out of curiosity,not to stir things up because some people tend to think that if you do the effect on one spu and it needs ~9ms,than you may as well do it across 5 and you will get down it to 1.9ms.But the problem is,they interpret it as it was total time,and according to them every spu would take approx 0.4ms which is not true.Similar to that MLAA misunderstand....

I can see it's quite easy to muddle the different types of SPU timings. Typically though, I think figures are given in total time, and developers are clear about 'SPU ms' when they talk about workloads they can distribute in different ways. Maybe. "50 ms across 5 SPUs" could be read both ways!

 

[Shifty Geezer]

"EE" evolution, organic material?

Waaayyyy ahead of its time, man!

 

[patsu]

Thanks Shifty...It was just out of curiosity,not to stir things up because some people tend to think that if you do the effect on one spu and it needs ~9ms,than you may as well do it across 5 and you will get down it to 1.9ms.But the problem is,they interpret it as it was total time,and according to them every spu would take approx 0.4ms which is not true.Similar to that MLAA misunderstand....

It's the same for GPU implementations. They only quote the elapsed time for all shader units instead of quoting the sum of time spent in each shader unit. It makes sense to use elapsed time because rendering needs to meet a near real-time schedule. As long as you meet the timeframe, tapping on unused computing resources is not an issue.

I mentioned the actual time spent in each SPU depends on the algorithm because:

* The % utiliization for the task may not be 100%. The/Some SPUs may be juggling other tasks at the same time (especially if "blocked" by IO).

* The SPUs may play different roles within the allocated time

So the real technical picture is a lot more interesting than one-two numbers.

 

[Arwin]

The only figures that matter here are how quickly you can get the interpolation done as that tell you how much time you have left for the rest of the game.

Well, yes, then we agree, my mistake! Where (you know what follows, just posting it to test my knowledge and for the benefit of others) with 'the rest of the game', we're talking about the time budget we have to render a frame (and specifically the amount of time we have left taking into account the jobs that this job depends on already took beforehand, and the time and other jobs depend on this one will take once this one is finished).

Take more than the budget, and you get an additional frame of lag, so this budget is very important to adhere to. If you have the processing power available on the SPUs (or the rest of the jobs on the SPU are more flexible in terms of timing so can be put on hold when necessary), then being able to scale the work over multiple SPUs to get the total time taken down is a big plus.

I think it is no secret that the SPUs are a great help for adding Motion Blur in the rendering pipeline, but it is always interesting to see detailed figures.