Resistance FOM GDC Presentation

[inefficient]

Some very good information in here about Insomniac's experience with the PS3. I'm assuming this is the presentation they are going to give at the upcomming GDC.

http://www.insomniacgames.com/tech/articles/0108/files/RFOM_Debriefing_public.pdf

For me the thing that stood out to me the most was the hard confirmation about just how many SPU's Sony are allowing the devs to use.

I know it's been rumored before that devs only have full access to 5 and partial access to a 6th with the 7th SPU totally off limits. But I've never actually seen a dev officially confirm this.

According to this documention the SPU usage is as follows:

2 Raw mode SPUs

• One SPU running broad collision
• One SPU running narrow collision

3 [Job Manager] SPUs

• In a thread group running SPURS

1 Unused !

• This one is for the OS to steal for the AC3 Encoder etc.

Then they go on to say that the 6th should (could?) be used with its own job manager instance in the future. For jobs that don't mind getting interrupted by the OS.

I actually find this kind of disturbing. Sony is already appropriating a whole dedicated 7th SPU for OS tasks. And on top of that they occasionally need a fraction of the 6th. Hopefully they eventually optimise their OS to the point where they will be able to fully return this 6th SPU to developers.

It seems like the AC3 Encoder is the main task Sony is appropriating time on the 6th SPU for. And they were not able to make use of the 6th SPU in the SPU pool for SPURS jobs because it was actually damaging overall to keep that SPU in the pool.


Another interesting bit was discussion of a 1280x704, 32bit, 2xMSAA alternet render buffer. It would not have been stretched/scaled to 720, just centered directly on the screen with 8 pixels top and bottom like letter boxing. They say they could have gotten a 2% perf increase and saved 1MB vram due to no wasted memory due to alignment.

They've got some detailed breakdowns on memory usage by their game. And many other interesting tidbits. It's a good read.

 

[Arwin]

This is a retrospective on their launch title. It's a good start to compare their newer titles with, to see how they have developed. I'm hoping that at GDC we'll get more recent information though?

 

[Rangers]

I'm surpised they dedicate such a big section to the 1280X704 rendering thing. They say it saves "over 1 MB" and renders 2% faster..is it really that big a deal?

Say they have 400 some MB available overall, 1MB means they are saving less than 1/4 of 1% of memory.

 

[deepbrown]

I'm surpised they dedicate such a big section to the 1280X704 rendering thing. They say it saves "over 1 MB" and renders 2% faster..is it really that big a deal?

Say they have 400 some MB available overall, 1MB means they are saving less than 1/4 of 1% of memory.

Hm tis odd. They used this method on Ratchet didnt they. I suppose we should be expecting the same resolution for Resistance 2.

 

[betan]

Good find, inefficient, thanks.

That 6th SPU reservation indeed sucks.
I wonder if it's used by hypervisor too, when running linux.

It would be funny to have SPU heavy Linux applications running faster than GameOS counterparts.

We should stop treating 720p resolution as sth sacred. I don't know any TV with native resolution of 1280x720p so why bother. TVs still have to upscale to at lease 768p.

I have a CRT and pretty sure it doesn't upscale to any "p".
;p

 

[Shifty Geezer]

What do they mean by 10-20% SPU utilization on slide 34? Is that an estimate of usage versus total available processing power, or is that value somehow relative to their [Job Manager] system, such as 10-20" of SPU runtime used in on managed jobs or something? If the former, that missing SPU isn't much of a problem at this point in time!

 

[dskneo]

The 6th spu is reserved for sound..... or so I understood from that. We already knew sound is processed by cell ages ago.

ac3 encondig = sound

 

[betan]

What do they mean by 10-20% SPU utilization on slide 34? Is that an estimate of usage versus total available processing power, or is that value somehow relative to their [Job Manager] system, such as 10-20" of SPU runtime used in on managed jobs or something? If the former, that missing SPU isn't much of a problem at this point in time!

Former (10-20% of available), since it's under SPUs title.
Missing SPU might have been a problem still, since they seem to be dedicating individual tasks to each SPU.

I suspect next GDC slides will surface sooner than later, showing how much they've come.

 

[one]

The 6th spu is reserved for sound..... or so I understood from that. We already knew sound is processed by cell ages ago.

ac3 encondig = sound

It's not always reserved, it's sometimes interrupted by the OS for game-related tasks such as AC3 encoding, hence unpredictable communication overhead from the viewpoint of user-space processes such as SPURS.

 

[Mike Acton]

Some clarifications

Some very good information in here about Insomniac's experience with the PS3. I'm assuming this is the presentation they are going to give at the upcomming GDC.

This is from a presentation Mark Lee gave last year at a Sony internal conference. This won't be presented at GDC.

I'm surpised they dedicate such a big section to the 1280X704 rendering thing. They say it saves "over 1 MB" and renders 2% faster..is it really that big a deal?

Say they have 400 some MB available overall, 1MB means they are saving less than 1/4 of 1% of memory.

Yes, 1MB is a BIG deal! Everything counts on a console. You need to weigh all your choices and decide what's the best use of the resources you have. If that 1MB could be spent on something that gives the user an even better experience than those few lines would have given them, it's a worthwhile trade. Which we believe it is.

That 6th SPU reservation indeed sucks.
I wonder if it's used by hypervisor too, when running linux.

It would be funny to have SPU heavy Linux applications running faster than GameOS counterparts.

I believe that the PS3 Linux kernel gives all 6 SPUs available full-time. (As there's no reason to run the game SDK when you're running an OtherOS).

Also, just to stomp this discussion - remember this is a description of what RFOM did for launch. Much has changed since then. Specifically, we are making use of all the available SPUs now.

What do they mean by 10-20% SPU utilization on slide 34?

Don't read too much into it. It was just a very rough guess on how much SPU horsepower we could still get after RFOM (So, looking at it that way - The thought was that we could still get 8-10x as much useful processing going on to the SPUs) It's just a rough number based on utilization times- it doesn't have any accurate meaning.

Mike.

 

[JardeL]

Yes, 1MB is a BIG deal! Everything counts on a console. You need to weigh all your choices and decide what's the best use of the resources you have. If that 1MB could be spent on something that gives the user an even better experience than those few lines would have given them, it's a worthwhile trade. Which we believe it is.

Also, just to stomp this discussion - remember this is a description of what RFOM did for launch. Much has changed since then. Specifically, we are making use of all the available SPUs now.

Don't read too much into it. It was just a very rough guess on how much SPU horsepower we could still get after RFOM (So, looking at it that way - The thought was that we could still get 8-10x as much useful processing going on to the SPUs) It's just a rough number based on utilization times- it doesn't have any accurate meaning.

Any " rough guesses " about OS memory usage for PS3 and SPU usage [ efficiency or whatever you call it ] in RFOM2 ?..

 

[babcat]

Any " rough guesses " about OS memory usage for PS3 and SPU usage [ efficiency or whatever you call it ] in RFOM2 ?..

That is a fantastic question! I would like to know the answer for that.

 

[Mike Acton]

Any " rough guesses " about OS memory usage for PS3 and SPU usage [ efficiency or whatever you call it ] in RFOM2 ?..

Ha! Nope - We're not going to comment on those details quite yet. You'll have to wait and see.

Mike.