Killzone 2 technology discussion thread (renamed)
- Thread starter Terarrim
- Start date
- Status
And I always thought he was from Utah.Phong was a scientist from Vietnam who invented this shader, by the way
And I always thought he was from Utah.
Phong is a very common Vietnamese name, it literally mean "wind".
It's difficult to give a number for this cause it can change a lot depending on what you have on screen.
For example when artists forget to add a lod for that 30.000 vertices mesh that now is so distant that barely fills any pixel on screen, in that case efficiency is pretty bad..close to 25%, for that draw call. As a general rule of thumb I'd say that betwee 15% and 25% of your ALUs power go wasted but it really can change a lot according that you're displaying.
Too bad he died too early in his life in 1975 with an age of 28.
Mintmaster
Veteran
I was talking about that. If we just had a if...endif block accumulating results for each light, why would there be register issues? There aren't even any texture accesses inside the branches.
Ahh, but you're forgetting that with forward rendering you don't get that kind of load since you're not lighting pixels in screenspace. The door and the wall around it are simply a couple of occluders. All the hidden pixels are eliminated by early Z (which has the same granularity as a stencil mask), and the remaining pixels will pretty much all take the same branch.
The responsibility of DB in a forward renderer is only to eliminate lights that are too far away. You only get incoherence where the object intersects the light's bounding volume. That's why I said that even for RSX you might be able to use DB this way somewhat effectively.
Mintmaster
Veteran
Okay, so one of the points I was making was that with 4x AA you probably won't save much of this lost shading time, relative to FR, in a DR that used the compressed sample flag idea. On polygon edges the samples wouldn't be equal, so you'd have to do 4x supersampling there anyway, bringing your efficiency down to 25%. When lighting, rejection from the stencil mask also has 2x2 granularity. Moreover, the G-buffer pass already has the same inefficiencies of a FR.
Taking all these factors into account, I don't think these losses from small polygon inefficiencies are any better with DR if you're using MSAA. There may be a way to detect edges without using the compressed sample flag or strict equality tests, and if so there will far fewer pixels to supersample and I'll admit that DR can definately reduce wasted shader power. It's hard to say, though, what kind of artifacts you'll see from using that kind of inexact heuristic.
Well if you can afford a bit extra space in your attributes, a Polygon ID would give exact answer. I think 8 loworder bits from Z crosschecked against sample depth on some treshold would be enough.nAo said:
On that note it begs a question if mask computation might not be better suited to do on SPU.
And while I'm not sure if it'd be worth it - 4xAA could use 8bit mask to give exact samples to shade. There may be enough edges to want to get more then 25% efficiency there.
Can anyone here give a rough estimate (percentage wise) of how many more shader instructions and polygons a deferred rendering method can allow you to push? I realize that there is a firm limit on the max polygons and max number of shader instructions. However, if you don't have to draw polygons that are not seen and shade the same pixels over and over again it seems obvious that deferred rendering would at least increase efficiency. Do any developers here have a rough guess of the kind of improvement deferred rendering can provide?
It can provide with 10 times more performance or 10 times less.
Is this guess rough enough?
It all depends on the design decisions, some designs can gain a lot from deferred, other ones will be much slower. It's also true for any other rendering technique.
jon, are you referring to Mint's post on page 10 (and the subsequent discussion)?
babcat, seems most of the relevant posts, if any, would be Fran's starter and much of pages 10-12. But your question is missing much of the context that would make it meaningful, as psorcerer notes (and as specified in the posts I referred). There're always trade-offs, depending on the scene you're rendering and the limits you're willing to place on your artists (insert tiny violin for Fran's artists).
babcat, seems most of the relevant posts, if any, would be Fran's starter and much of pages 10-12. But your question is missing much of the context that would make it meaningful, as psorcerer notes (and as specified in the posts I referred). There're always trade-offs, depending on the scene you're rendering and the limits you're willing to place on your artists (insert tiny violin for Fran's artists
).No, there's not. A game is a complex system, you can't just write down a simple formula to describe its performance
Not really, no. The level designers and artists are going to take advantage of the renderer that allows them to implement their vision. With a game's chosen rendering method you're likely to see them try to avoid those situations that would increase the work that would have been suited to another method!
For example, a clear win with deferred shading is that you can feasibly have a ton of unique lights interacting in a scene compared to forward rendering. But if forward rendering is the best at achieving the vision they want, the level designers/artists clearly aren't going to put those zillion lights in the scene. So a straight up switch from forward rendering to deferred shading wouldn't give you any benefit and may even end up being detrimental.
edit:
I don't know how much work it would be, but it would be 'cool' to have different rendering modes according to the level. Say... have deferred shading within a small-enclosed level but then use forward rendering for the next level that's mostly outdoors or does something that mitigates the advantages of the former method.
That sounds complicated to me.
AlStrong,
That is exactly what I was thinking. I think it would be interesting if they could change rendering method from level to level.
However, in addition to lighting I've read that deferred rendering also helps increase the number of shaders and polygons you can push. I don't know if using a forward renderer in an outdoor sunny scene would be a good thing.
That is exactly what I was thinking. I think it would be interesting if they could change rendering method from level to level.
However, in addition to lighting I've read that deferred rendering also helps increase the number of shaders and polygons you can push. I don't know if using a forward renderer in an outdoor sunny scene would be a good thing.
"They" can, but that's so pointless.
Outdoor sunny scene has one light source - sun (you can drop all other lights because the sun intensity wins them all). Tell me now, how would you like to benefit from deferred here?
Yes, sorry.
You would win by being able to push more polygons and shaders. Being able to use many lights is NOT the only benefit of deferred rendering.
- Status