Killzone 2 technology discussion thread (renamed)
- Thread starter Terarrim
- Start date
- Status
zoekimball
Banned
It's probably a Killzone 2 developer royally pulling your leg, just to give you something to talk about...
Betanumerical
Veteran
I don't think it is, I think this guy is generally this stupid.
TimothyFarrar
Regular
How about lets end the crack smoking of that xbox post,
As per the 360 vs PS3 KillZone2 tech and EDRAM vs PS3+SPU, implementing the post processing combination of motion blur, depth of field, bloom, and tone mapping (contrast, desaturate, etc), will take a good chunk of processing time. Could be upwards of 15% to 30% of the rendering frame.
Seems that KZ2 is doing this image processing work on the SPUs which means an extra 15% to 30% more GPU time for geometry and lighting. Seems like a rather nice benefit to me.
Had KZ2 been on a 360, those processing passes would not benefit from EDRAM performance. Any type of image space or post processing work would be texture fetch bound anyway. EDRAM (or any type of separated framebuffer memory) has a disadvantage in post processing work where you are feeding back the previous computations for the next processing step, because that EDRAM has to be resolved back to memory which can be texture fetched from for the next step. So even if you take EDRAM to be free bandwidth wise, you end up taking the same bandwidth to main memory as you would without EDRAM because of the resolve. Also the resolve is going to be bound 100% on the bandwidth of your other memory (NOT going to be doing any other GPU work during the resolve).
Likely KZ2 also takes advantage from a PS3 tech perspective of not being crippled by an EDRAM in how it does shadows. From what I've read from the older KZ2 rendering presentation, KZ2 has one large shadow buffer which it reuses for each shadow pass. The advantage of this reuse is high quality shadows with low memory usage. Effectively you render the shadow then use it to light in the G-Buffer, then render the next shadow, then light the G-Buffer, and so on.
Being a deferred renderrer, KZ2 has a huge G-Buffer which would in no way fit in EDRAM on the 360 without tiling. So KZ2 on 360 would have needed a large number of tiles. Tiling and shared shadow mapping simply doesn't work. The problem is that each tile needs access to the entire shadow map, not just a tile of the shadow map. So you either render all the shadows into separate buffers as a pre-pass (and loose the memory advantage of a shared shadow buffer), or re-render each shadow map for each tile in EDRAM (which places even more memory pressure on the EDRAM, so more tiling, and 4x or more times drawing the shadow maps, and lots of resolves).
As per KZ2's post processing, with only 8-bit precision and 2x LDR range, the bloom/DR effects are very impressive. Many other titles which have proper linear space lighting still have horrid and ugly bloom. IMO I'd toss the correct math for something which looks better in practice, which is exactly what KZ2 did.
If there is any conclusion to this, KZ2 is taking advantage of being a PS3 only title, and it shows in the choices made in the rendering tech...
As per the 360 vs PS3 KillZone2 tech and EDRAM vs PS3+SPU, implementing the post processing combination of motion blur, depth of field, bloom, and tone mapping (contrast, desaturate, etc), will take a good chunk of processing time. Could be upwards of 15% to 30% of the rendering frame.
Seems that KZ2 is doing this image processing work on the SPUs which means an extra 15% to 30% more GPU time for geometry and lighting. Seems like a rather nice benefit to me.
Had KZ2 been on a 360, those processing passes would not benefit from EDRAM performance. Any type of image space or post processing work would be texture fetch bound anyway. EDRAM (or any type of separated framebuffer memory) has a disadvantage in post processing work where you are feeding back the previous computations for the next processing step, because that EDRAM has to be resolved back to memory which can be texture fetched from for the next step. So even if you take EDRAM to be free bandwidth wise, you end up taking the same bandwidth to main memory as you would without EDRAM because of the resolve. Also the resolve is going to be bound 100% on the bandwidth of your other memory (NOT going to be doing any other GPU work during the resolve).
Likely KZ2 also takes advantage from a PS3 tech perspective of not being crippled by an EDRAM in how it does shadows. From what I've read from the older KZ2 rendering presentation, KZ2 has one large shadow buffer which it reuses for each shadow pass. The advantage of this reuse is high quality shadows with low memory usage. Effectively you render the shadow then use it to light in the G-Buffer, then render the next shadow, then light the G-Buffer, and so on.
Being a deferred renderrer, KZ2 has a huge G-Buffer which would in no way fit in EDRAM on the 360 without tiling. So KZ2 on 360 would have needed a large number of tiles. Tiling and shared shadow mapping simply doesn't work. The problem is that each tile needs access to the entire shadow map, not just a tile of the shadow map. So you either render all the shadows into separate buffers as a pre-pass (and loose the memory advantage of a shared shadow buffer), or re-render each shadow map for each tile in EDRAM (which places even more memory pressure on the EDRAM, so more tiling, and 4x or more times drawing the shadow maps, and lots of resolves).
As per KZ2's post processing, with only 8-bit precision and 2x LDR range, the bloom/DR effects are very impressive. Many other titles which have proper linear space lighting still have horrid and ugly bloom. IMO I'd toss the correct math for something which looks better in practice, which is exactly what KZ2 did.
If there is any conclusion to this, KZ2 is taking advantage of being a PS3 only title, and it shows in the choices made in the rendering tech...
No they are not, that's the beauty if not understanding how it works, especially in the context of downplaying what KZ2 does.Yep, in some bizarro world he's correct: the lights in deferred rendering are "2D", that's the beauty of it
I see, 'evil' is the new 'I don't know what I am talking about'
They still pay a huge/insane cost for it, totally not worth it when there definitely other methods around that works as good as theirs if not better.
Tone mapping in the shader ala HL2 + deferred exposure computations (see post on my blog)
NAO32 (that ppl now use on 360&XNA..)
And the old FP16 + proper tone mapping.
Do you understand that lighting is a function of MANY variables? It's not just the about the method you use to store your images.
Last edited:
30% seems really high, unless you meant how much cpu use it would take. I don't think a gpu would take that long post processing the items you mention. I agree that it's not a bad choice to do it that way on the PS3, but I don't think anyone can make direct comparisons to other machines because it doesn't make sense to do it that way on a unified gpu.
On unified gpus, the gpu will shift to being entirely a pixel processor during post processing so it will always outrun what that cpu can do. Hence it becomes an apples to oranges comparison, just because it makes sense on PS3 doesn't mean it's ideal on other platforms. It's true that texture fetch is a bottleneck during post processing, but you can also use this to your advantage because you can go nuts with alu instructions on a unified gpu during post process with no performance hit. That lets you try all manner of stuff! For example, you can combine what are normally separate post processing steps together. If you have two steps that can use the same 16 taps then glop them together and go alu crazy, it won't matter because all that alu time will get absorbed by the unified gpu running at full tilt. Net result is you can get entire post process passes free.
This is true. However, from what I recall KZ2 still has a forward render pass for particles. It would have massively benefited from EDRAM there. Resolves are irritating but they are very fast, faster than the performance loss you will encounter doing a forward render transparency pass on a non edram setup.
I think you are overstating this one. What you are saying is true, reusing shadow buffers on 360 would be a pain. But it's moot because you wouldn't do that anyways. You have to do that on PS3 to get around the heavy memory handicap that machine has, on 360 there's piles of extra ram so just keep 4 separate shadow buffers around, no big deal at all. Plus, there are potential advantages to keeping the shadow buffers around.
Alpha is easy to factor in with alternative methods as long as they don't contribute significantly to the exposure computations (which is the case in the vast majority of games). You can adopt a different solution for alpha blended stuff and then you 'just' composite with the rest of the image, hardly rocket science.
Calling Halo 3's lighting the most spectacular ever implemented in a game, or even spectacular, is a stretch, considering it consists of a combination of simple per-character drop shadows and old-school precomputed lightmaps. In other words, the lighting and shadowing system isn't a unified/universal model (a la GTA IV, Far Cry 2, COD4, etc.) wherein world structures (e.g., railings, trees, buildings) cast dynamic shadows.
This is based on what I've seen of the game based on some video footage. I haven't played the game.
Edit: The game does use some dynamic lighting+shadowing in spots, but primarily during cutscenes.
Last edited by a moderator:
Funny... Spherical Harmonics is old school in games?
That's also funny... he didn't even mention the shadowing.
- Status