Deferred Rendering on PS3 (Was KZ2 Tech Discussion)

Status
Not open for further replies.

patsu

Legend
Betanumerical said:
Do you or anyone else have any numbers for the SPE performance at graphical tasks?.

I have some time tonight after meeting some milestone. Found this on SCEA's R&D site:
http://research.scea.com/ps3_deferred_shading.pdf

I can't remember if it's old but there are some numbers.

EDIT:
Guerilla Games's presentation in Develop Conference 2007 talked about their implementation: http://www.develop-conference.com/d.../vwsection/Deferred Rendering in Killzone.pdf

Insomiac also has very interesting slides on their R&D page: http://www.insomniacgames.com/tech/techpage.php
You should be able to find things like memory budget (for different subsystems), schedule for physics calculations, etc. in some of the papers.

I wish I have time to assimilate them.
 
I don't want to be too anal but first two papers were "discussed" to death already. My question is: what is the topic of this thread? What do you want people to discuss that hasn't been covered before?
 
I don't know if it was discussed in that thread as I wasn't reading it. :) It was discussed before though, multiple times. I recall one heated argument about the right way to calculate the amount of memory KZ2 uses for its deferred renderer. It would be a good thing to summarize all those discussions with an article (as it would be with multiple other reoccuring topics). :/
 
But the SCEA paper is different from the GG paper (It's not KZ2 specific). Might be a different implementation. What is discussed "to death" ? Most technical work are built on top of one another, or using different parameters, measurements and approaches to solve the same problem.

EDIT: The KZ2 tech thread is locked. I trust that the mods will organize the threads accordingly.
 
I have some time tonight after meeting some milestone. Found this on SCEA's R&D site:
http://research.scea.com/ps3_deferred_shading.pdf

I can't remember if it's old but there are some numbers.

EDIT:
Guerilla Games's presentation in Develop Conference 2007 talked about their implementation: http://www.develop-conference.com/d.../vwsection/Deferred Rendering in Killzone.pdf

Insomiac also has very interesting slides on their R&D page: http://www.insomniacgames.com/tech/techpage.php
You should be able to find things like memory budget (for different subsystems), schedule for physics calculations, etc. in some of the papers.

I wish I have time to assimilate them.

Thanks!.

Does anyone have the GDC slides from a few years ago (2007?) that mentions numbers for culling among other things on the SPE's.
 
So what exactly enables a Deferred Rendering engine to allow so many light sources? I mean I know it has to do with the method of rendering pass right?

Also, Timothy Farr and Joker were having a bit of a fight regarding Memory limitations on the PS3 platform- I thought the PS3 OS was in the realm of 35-32MB for the baseline- and that the feature sets were reduced\no longer necessary? (modules)

Like the "Friends list" (That cost at the time, 24MB) is bogus now because it's incorporated into the In-Game XMB, etc etc.

So I don't understand why he said the 360 has "Piles more memory" by comparison- aside from memory saved thanks to proper Edram usage..

I'm kind of a n00b so forgive this question but:

KZ2 isn't pulling off real HDR right? RSX has issues with AA and HDR if I remember.. Is it using nAO32?
 
To state the 360 has piles of memory would only be accurate if you accept that the PS3 has as well. They have hardware-wise the same amount of memory if you don't count the EDRAM, for which however, the RSX can have a bigger framebuffer than just the size of the EDRAM. Not to mention that the PS3's main memory is blazingly fast and used for textures as extended VRAM to help combat the 256MB issue. It all boils down to roughly equal. The only real abstraction from PS3 memory use to 360 being the intensive XMB OS, which, as you said correctly, has been slimmed down since launch, which is easily explicable by games requiring firmware updates to allow play.

KZ2 does not use HDR; it uses bloom and achieves something I would call Fake-HDR. No toning/tone mapping. I can see how users are easily tricked though, since KZ2 has imho the best Fake-HDR I have ever seen. With lighting that good I sometimes don't see the benefit anymore.

KZ2 also uses 2xQAA (Quincunx). I remember that their ambition was 4xMSAA but they apparently couldn't pull it off yet. If you aren't aware of the benefits and difficulties with QAA, take a look at the pinned thread for resolution.

What I personally find the most impressive about KZ2, which I have not yet seen properly explained or paid attention to, is the fact that it has 3-Dimensional (layer stacked on layer, as seen in RAGE demos) textures on walls and ground. This allows them to look realistically uneven, have different amounts of rock and gravel, etc.
 
To state the 360 has piles of memory would only be accurate if you accept that the PS3 has as well. They have hardware-wise the same amount of memory if you don't count the EDRAM, for which however, the RSX can have a bigger framebuffer than just the size of the EDRAM. Not to mention that the PS3's main memory is blazingly fast and used for textures as extended VRAM to help combat the 256MB issue. It all boils down to roughly equal. The only real abstraction from PS3 memory use to 360 being the intensive XMB OS, which, as you said correctly, has been slimmed down since launch, which is easily explicable by games requiring firmware updates to allow play.

KZ2 does not use HDR; it uses bloom and achieves something I would call Fake-HDR. No toning/tone mapping. I can see how users are easily tricked though, since KZ2 has imho the best Fake-HDR I have ever seen. With lighting that good I sometimes don't see the benefit anymore.

KZ2 also uses 2xQAA (Quincunx). I remember that their ambition was 4xMSAA but they apparently couldn't pull it off yet. If you aren't aware of the benefits and difficulties with QAA, take a look at the pinned thread for resolution.

What I personally find the most impressive about KZ2, which I have not yet seen properly explained or paid attention to, is the fact that it has 3-Dimensional (layer stacked on layer, as seen in RAGE demos) textures on walls and ground. This allows them to look realistically uneven, have different amounts of rock and gravel, etc.


Thanks. The community here is very insightful and helpful for (young) people like myself trying to make headway into this area.
 
To state the 360 has piles of memory would only be accurate if you accept that the PS3 has as well.

He was stating that the 360 has piles of memory compared to the PS3, which is true. What you've said isn't exactly wrong, but it is a lot of smoke and mirrors. Very simply, games on the 360 have access to more memory than games on the PS3, and every little bit counts. This amount isn't insignificant between the much smaller RAM usage of the OS on the 360 as a baseline, it's even more significant when PS3 games start adding more features, and it's even more significant given the eDRAM that stores at least part of the framebuffer.

Artists these days, on consoles, can do a lot with even 10MB of RAM. Remember that the PS2 only had 32MB total...

And a small correction: Both the 360 and PS3 can have framebuffers larger than 10MB (the size of the 360 EDRAM). The 360 can use tiling to achieve this, and many games use this for that reason.
 
The PS3 baseline OS statistics are almost in line with the 360's though. They're within 6MB apart of each other at max.

I fail to see how this is "Piles more"?
 
The PS3 baseline OS statistics are almost in line with the 360's though. They're within 6MB apart of each other at max.

I fail to see how this is "Piles more"?
Where do you get your numbers?

The the piles comes from the combined effects. Compare the baseline features of the 360's OS vs the PS3's, and you'd need to add additional features and additional memory to match the 360 -- and they're already in the red in terms of memory. Add on to that the 10MB eDRAM buffer and you have a pretty significant memory advantage. I think you're underestimating what can be done with even 6MB of memory in a console these days.
 
Even if you try to factor in the "Added features" (which not many use, let's be real. And\or many of them are not accessible "In-Game").

And yea, I know the exact numbers (as I'm sure people here do, but are worried of NDAs) involved here for the root OS memory requirements.
 
What features would you add to use? I mean sure you could say "In-Game music streaming from the HDD" but 99% of games don't even use that.

Friends list? That's free thanks to In-Game XMB, and even when that wasn't available- games like Rainbow Six Vegas 2 would render the friends list in the main menu for friend invites (same for RFOM1). So that "24MB of RAM" wasn't being sucked up in-game.

Voice chat is free now too isn't it?

I know more than a few devs lol. Last I heard the PS3 OS was slightly under 35MB and no VRAM is being sucked up. It's all in the Main System Memory.
 
Even if you try to factor in the "Added features" (which not many use, let's be real. And\or many of them are not accessible "In-Game").

And yea, I know the exact numbers (as I'm sure people here do, but are worried of NDAs) involved here for the root OS memory requirements.
No offense intended, but I sincerely doubt you know the real numbers if you think they are 6MB apart from eachother.

Not that I know them right now either, but I do strongly suspect they're not that close. ;) You're saying in the period of a bit over a year they went from over 80MB of RAM usage to 38MB? While adding features?
 
Eh. If memory serves the OS was 54MB in size last year (launch of Uncharted approx) with 1.80.

It was reduced greatly, again, at 2.20. Which was a few months ago at this point.
 
Eh. If memory serves the OS was 54MB in size last year (launch of Uncharted approx) with 1.80.

It was reduced greatly, again, at 2.20. Which was a few months ago at this point.
It was 54MB of main memory, plus 32MB of GDDR3 memory...IIRC.
 
...I'd be seriously surprised if a footprint from 84MB vs 32MB could be reduced so rapidly.

MB for MB, there is indeed a substantial difference, enough that it has to be taken into great consideration during development (not that a single megabyte would be ignored anyway).
 
No offense intended, but I sincerely doubt you know the real numbers if you think they are 6MB apart from eachother.

Not that I know them right now either, but I do strongly suspect they're not that close. ;) You're saying in the period of a bit over a year they went from over 80MB of RAM usage to 38MB? While adding features?


I thought everybody had accepted this by now, that there was <8 megs difference at max.

the way I remember it was after a year they'd gotten down from around 96 to the low 50s and then down to around 40 or less second half of '08.
 
Status
Not open for further replies.
Back
Top