Nooo...the devs are now just starting to get the hang of the ps3 hardware....

You can also read it int the opposite direction.

My sensation is that you go 60fps only if you are pretty confident that you're not going to degrade to way lower framerates: falling from 60fps to 45-50fps for example is very noticeable to the eye.

Thus I suppose they can consistently pull off all their elaboration within a 60th of a second frame time. Which in turn I suppose means that they found a pretty reliable way to offload to the SPUs.

The other way to look at it is that action games are very sensitive to input latency, more so than many other titles as the games require timed button responses. (This is especially true for GH, RB music games)

In this instance, the sensation of poor input response may be more critical to avoid than the variable flow of fluxuating frame-rates.

 Squilliam, you are over all us peons heads with your mighty intelligence. Please induge us with a Video of Crysis that doesn't look laggy or choppy running on any PC. Then you will learn those PS3 fanboys good.

Remember a video not a bullshot.

I would go out on a limb and say that no the PS3 has not shown us everything it can do. The developers are just now getting the hang of developing for it and every game that comes out for it is a little better than the last. I think that maybe the graphics will top out in the next year or two, but then other features can be enhanced and made better in the game. There are many different aspects than just graphics for games.

Nude pictures of you or no deal.

Slide 4 shows the traditional way of doing things since GPUs have been used (2 simultaneous frames with CPU->GPU pipeline).

Slide 5 shows the same thing with an additional CPU in the pipeline (3 frames, CPU0->CPU1->GPU).

Slide 13 shows GOW3's way before they used SPUs (3 frames, PPU->PPU->GPU)

Slide 14 shows GOW3's way after offloading certain parts to the SPUs (3 frames, PPU->SPUs->GPU).

Interesting. Where can I read about that? Where are each of the frames located at each moment?

2 years into its life is that the limit, lol op lol hard.

Ok, I see what you're saying. But the shifting in 3 frames is only because you have the 3 serial operations in parallel on different frames (simulation->scene->render).

If you have 58 CPUs but each of these steps can be parallelized internally, the frames required will still be 3.

Not if you pipeline the operations (which you can do by dividing these 3 serial operations into further serial operations, the same way they passed from 2 to 3). Massive pipelining is the easy and scalable way of doing multi-core programs, but of course not good enough when response time is important.

Your last sentence is very true, but parallelizing the steps is the hard part as you know. That's probably where future optimization efforts will be focused, along with low-level code optimizations.