Deferred shading - will it become commonplace?

[PhatoseAlpha]

So, I've been playing stalker. On my now long in the tooth 6800gt, I'm pretty much stuck on static lighting, but I've heard quite clearly that the game uses deferred shading, meaning that the typical MSAA available on graphics card just plain doesn't work.

I seem to remember hearing R6:Vegas uses this technique too, though I'm not sure of it.

I ask because at some point fairly soon I'm going to need to upgrade, and Ati has always seemed to have a pretty big advantage in performance once AA gets cranked. However, if games are going to be using deferred shading much in the future, it would change the way I'd have to compare performance.

So, is the future gonna be a lot of games using this? Do the graphics card manufacturers have a silver bullet that will allow good old MSAA in games using this technique?

 

[schneiderguy]

deferred lighting needs to DIAF unless nvidia/ati make a magic solution that will let us run AA on those games :| (imo)

 

[TanisHalfElven]

does SSAA work on it.

 

[PhatoseAlpha]

From what I've heard, yes. Though, given the rather catastrophic performance hit of SSAA, I'd end up thinking it irrelevant.

 

[BFG10K]

does SSAA work on it.

Driver SSAA doesn't work but the game tries to mimic SSAA with the in-game AA setting.

The setting only appears to work with static lighting however.

 

[CaiNaM]

GRAW and R6:Vegas also uses it... R6: Vegas uses U3 Tech.

IIRC dx10 has methods for aa concurrently with deferred lighting/deferred rendering, which is not possible using DX9.

 

[jim1976]

I think the main problem is that MSAA was designed for forward rendering. Now what deferred shading does is to distinguish the geometry rendering from the lighting/shading computations.And this is were the problem occurs. The scene cannot be properly multi sampled as you cannot have access to previous stored info about color/depth buffer. I'm very anxious to see if D3D10 API can bring something to the table for this issue..

Originally posted by: CaiNaM
GRAW and R6:Vegas also uses it... R6: Vegas uses U3 Tech.

IIRC dx10 has methods for aa concurrently with deferred lighting/deferred rendering, which is not possible using DX9.

Only from accessing the previous color values through the buffer but I don't think the depth issue is resolved even at d3d10.. I might be mistaken though, and quite frankly I hope I am..

 

[CaiNaM]

Originally posted by: jim1976
I think the main problem is that MSAA was designed for forward rendering.

you're absolutely correct. the problem isn't with deferred lighting/shadows/render, it's with MSAA.

Now what deferred shading does is to distinguish the geometry rendering from the lighting/shading computations.And this is were the problem occurs. The scene cannot be properly multi sampled as you cannot have access to previous stored info about color/depth buffer. I'm very anxious to see if D3D10 API can bring something to the table for this issue..

i read that with dx10 there's nothing which prevents rendering the g-buffer in MSAA mode and processing individual samples.

also, my saying it's "not possible" is not really accurate; rather it's not very feasible due to the performance cost to accomplish this in DX9. in fact, i believe with the 158 series driver it's possible to run AA in R6:Vegas, which uses the deferred rending method for shadows: http://www.nvnews.net/vbulletin/showpost.php?p=1231918&postcount=604

Only from accessing the previous color values through the buffer but I don't think the depth issue is resolved even at d3d10.. I might be mistaken though, and quite frankly I hope I am..

form http://forum.beyond3d.com/showpost.php?p=932149&postcount=21:

"AA was still a problem with deferred renderers on DX9, with DX10 we should be able to read back each subsample belonging to a pixel so that we can build an accurate stencil mask which marks edge pixels; early stencil rejection then should help us to shade only one subsample per pixel on the vast majority of the screen area, while we can directly supersample and resolve all the other pixels with a custom shader (but with the advantage of having a rotated or sparse sampling grid)"

 

[Gstanfor]

IIRC dx10 has methods for aa concurrently with deferred lighting/deferred rendering, which is not possible using DX9.

This is microsloth's way of *forcing* you into going Vista (and fattening their coffers in the process) whether you want to or not. Expect deferred rendering and anything else possible in DX10 but not in DX9 to get very popular with developers from here on out (M$ probably pays them money to do this).

 

[BFG10K]

in fact, i believe with the 158 series driver it's possible to run AA in R6:Vegas, which uses the deferred rending method for shadows: http://www.nvnews.net/vbulletin/showpost.php?p=1231918&postcount=604

I would like to see a screenshot comparison with and without driver AA. Just because he's seeing a performance hit it doesn't mean he's getting driver AA.

This is compounded by the fact that the game is so damn blurry which masks aliasing.

 

[jim1976]

Originally posted by: CaiNaM
you're absolutely correct. the problem isn't with deferred lighting/shadows/render, it's with MSAA.

i read that with dx10 there's nothing which prevents rendering the g-buffer in MSAA mode and processing individual samples.

also, my saying it's "not possible" is not really accurate; rather it's not very feasible due to the performance cost to accomplish this in DX9. in fact, i believe with the 158 series driver it's possible to run AA in R6:Vegas, which uses the deferred rending method for shadows: http://www.nvnews.net/vbulletin/showpost.php?p=1231918&postcount=604


form http://forum.beyond3d.com/showpost.php?p=932149&postcount=21:

"AA was still a problem with deferred renderers on DX9, with DX10 we should be able to read back each subsample belonging to a pixel so that we can build an accurate stencil mask which marks edge pixels; early stencil rejection then should help us to shade only one subsample per pixel on the vast majority of the screen area, while we can directly supersample and resolve all the other pixels with a custom shader (but with the advantage of having a rotated or sparse sampling grid)"

I'm very skeptical even if this is possible what would be the performance cost following this route.. I for once find this very taxing and I don't see any gains in doing that with deferred shading rather than supersampling the whole scene traditionally. Dunno. I do believe that eventually they will find a viable and efficient way in D3D10, but this one does not seem efficient. I don't know if it's even possible this way..

I'll try 158.19 and Vegas and test whether AA it works or not with them..

 

[Ulfhednar]

God I hate games that do this.

 

[xtknight]

Need some background info. What exactly does deferred shading do? Has it been implemented well in games lately?

 

[Gstanfor]

Originally posted by: xtknight
Need some background info. What exactly does deferred shading do? Has it been implemented well in games lately?

Deferred Shading

STALKER and Rainbow Six: Vegas employ deferred shading rendering engines.

 

[apoppin]

STALKER is a 7 year old engine

 

[Nightmare225]

Originally posted by: jim1976

I'll try 158.19 and Vegas and test whether AA it works or not with them..

Let us know, I'm curious as to this too...

 

[ShadowOfMyself]

Originally posted by: apoppin
STALKER is a 7 year old engine

 

[Nightmare225]

Originally posted by: ShadowOfMyself

Originally posted by: apoppin
STALKER is a 7 year old engine

It is.

 

[Mark R]

Originally posted by: xtknight
Need some background info. What exactly does deferred shading do? Has it been implemented well in games lately?

Deferred shading is a method of accelerating complex lighting.

The conventional way of rendering complex lighting requires running a pixel shading fragment on every pixel that gets rendered. That fragment calculates the lighting equations and blends them with the textures, etc. The fragment may need to be run several times (one for each light source).

The problem is that not every pixel that ends up being rendered is visible (some polygons are further away and get drawn over), and if there are many polygons repeatedly running the shaders is a big performance drain.

In deferred shading, the whole scene is rendered using simple rendering (no lighting, basic textures only), but as well as rendering the image, the renderer is set up to 'render' pixel-by-pixel hints for lighting equations.

Once that is done, the scene is shaded - the shaders only have to render a single screen sized polygon. This avoids rendering hundreds of k of polygons with complex shaders, it ensures every pixel that is rendered is visible, and the pre-calculated hints can be re-used for each light source (instead of having to be recalculated).

The problem is that the resolution is fixed early in the rendering process. With advanced AA algorithms (like MSAA), they will dynamically increase the resolution depending on how much detail is in a particular region. This can't be done with deferred rendering because the base image has to be rendered to a temporary buffer which has a fixed resolution.

There are some tricks to get around this - like detecting edges and building stencils which can be used to re-render edges in higher details. They just aren't easily done with DX9.

 

[Munky]

Originally posted by: xtknight
Need some background info. What exactly does deferred shading do? Has it been implemented well in games lately?

This GDC presentation explains deferred shading pretty well. The way I see, it makes possible to implement complex volumetric lighting and shadows with many light sources at a smaller performance hit than traditional rendering. For this reason, I believe deferred shading will become increasingly used in games, although I don't think it will become mainstream in the near future.

 

[ShadowOfMyself]

Originally posted by: Nightmare225

Originally posted by: ShadowOfMyself

Originally posted by: apoppin
STALKER is a 7 year old engine

It is.

Sure, but what does that have to do with the topic?

 

[xtknight]

Originally posted by: Mark R

Originally posted by: xtknight
Need some background info. What exactly does deferred shading do? Has it been implemented well in games lately?

Deferred shading is a method of accelerating complex lighting.

The conventional way of rendering complex lighting requires running a pixel shading fragment on every pixel that gets rendered. That fragment calculates the lighting equations and blends them with the textures, etc. The fragment may need to be run several times (one for each light source).

The problem is that not every pixel that ends up being rendered is visible (some polygons are further away and get drawn over), and if there are many polygons repeatedly running the shaders is a big performance drain.

In deferred shading, the whole scene is rendered using simple rendering (no lighting, basic textures only), but as well as rendering the image, the renderer is set up to 'render' pixel-by-pixel hints for lighting equations.

Once that is done, the scene is shaded - the shaders only have to render a single screen sized polygon. This avoids rendering hundreds of k of polygons with complex shaders, it ensures every pixel that is rendered is visible, and the pre-calculated hints can be re-used for each light source (instead of having to be recalculated).

The problem is that the resolution is fixed early in the rendering process. With advanced AA algorithms (like MSAA), they will dynamically increase the resolution depending on how much detail is in a particular region. This can't be done with deferred rendering because the base image has to be rendered to a temporary buffer which has a fixed resolution.

There are some tricks to get around this - like detecting edges and building stencils which can be used to re-render edges in higher details. They just aren't easily done with DX9.

Many thanks, that was a great explanation!

Couldn't they just do SSAA, send that to this "fixed buffer" and then do deferred shading on the bigger image or would that not work/be too slow? Actually that's a silly question as I'm sure they would do that if they could, but I'm wondering why it wouldn't be feasible.

Also, what do you mean by "precalculated hints"?

Originally posted by: munky

Originally posted by: xtknight
Need some background info. What exactly does deferred shading do? Has it been implemented well in games lately?

This GDC presentation explains deferred shading pretty well. The way I see, it makes possible to implement complex volumetric lighting and shadows with many light sources at a smaller performance hit than traditional rendering. For this reason, I believe deferred shading will become increasingly used in games, although I don't think it will become mainstream in the near future.

Why don't you think it will be used in the future? Tough to implement? Maybe a future API such as an update to DX10 (or DX11) or an extension in OpenGL 2.x will make this more straightforward to do by providing the developer with classes or structures that ease the pain? Or perhaps, they will reengineer the GPU pipeline to make it more feasible.

 

[Zstream]

Originally posted by: apoppin
STALKER is a 7 year old engine

Who cares, they made it look kick ass IMO.

 

[apoppin]

Originally posted by: ShadowOfMyself

Originally posted by: Nightmare225

Originally posted by: ShadowOfMyself

Originally posted by: apoppin
STALKER is a 7 year old engine

It is.

Sure, but what does that have to do with the topic?

the OP asked a question ...

Deferred shading - will it become commonplace? Curious after playing stalker

in the *context* of that question - Using STALKER - it is hard to say if DS will be "commonplace" by using a 7 year-old - totally unique - Engine as the "prime example"

 

[chizow]

I hope not. Maybe if they can improve performance in DS games but right now the end result doesn't justify the performance hit and inability to do AA imo.