Sign in to follow this  
Chris_F

Revival of Forward Rending?

Recommended Posts

MJP    19754
[quote name='olaolsson' timestamp='1333353313' post='4927391']
Btw, one thing that could may affect your results that I noticed is that you make use of atomics to reduce the min/max depth. Shared memory atomics on NVIDIA hardware serialize on conflicts, so to use them to perform a reduction this way is less efficient than just using a single thread in the CTA to do the work (at least then you dont have to run the conflict detection steps involved). So this step gets a lot faster with a SIMD parallel reduction, which is fairly straight forward, dont have time to dig out a good link sorry, I'll just post a cuda variant I've got handy, for 32 threads (a warp), but scales up with apropriate barrier syncs, sdata is a pointer to a 32 element shared memory buffer (is that local memory in compute shader lingo? Anyway, the on-chip variety.).
[/quote]

Yeah, most of the code for the light/tile intersection was copied straight from Andrew Lauritzen's sample. He didn't want to do a reduction because of the extra shared memory pressure that it would add (which makes sense, considering he was already using quite a bit of shared memory for the light list + list of MSAA pixels), but it might be worth it if you're just outputting a light list for forward rendering. I wouldn't expect very big gains since the light/tile intersection tends to be a small portion of the frame time, but it could definitely be an improvement. Maybe if I have some more free time soon (not likely) I'll give it a shot. I would also definitely like to play around with more optimized intersection tests, especially for spotlights. Everybody always just does point lights in their demos. [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img]

Share this post


Link to post
Share on other sites
olaolsson    142
[quote name='MJP' timestamp='1333393678' post='4927595']
He didn't want to do a reduction because of the extra shared memory pressure that it would add (which makes sense, considering he was already using quite a bit of shared memory for the light list + list of MSAA pixels), but it might be worth it if you're just outputting a light list for forward rendering.
[/quote]
In my implementation I always build the grid in a separate pass. It's a fairly trivial ammount of extra bandwidth and you remove shared memory limitations, and it is inherently more flexible. I implemented lauritzens single kernel version too, more or less a straight port, but with parallel depth reduction, (was significant at least on a gtx 280), it did not perform as well (but was only fairly marginally slower).

[quote name='MJP' timestamp='1333393678' post='4927595']
I wouldn't expect very big gains since the light/tile intersection tends to be a small portion of the frame time, but it could definitely be an improvement.
[/quote]
Well, since you are brute forcing (lights vs tiles) you just need to ramp the lights up, and voila it'll become an issue sooner or later. This is also highly (light) overdraw dependent, so I think the portion of frame time can vary quite a bit. Sorry to say, I can't run your demo, because I've only got access to a windows xp machine at the moment, so I cant offer any comments based on how your setup looks.

[quote name='MJP' timestamp='1333393678' post='4927595']
Everybody always just does point lights in their demos. [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img]
[/quote]
Yes, guilty as charged... damn those paper deadlines :)

Share this post


Link to post
Share on other sites
FreneticPonE    3294
[quote name='Chris_F' timestamp='1333359199' post='4927417'] But then you loose the benefit of easily being able to use different BRDFs, unless you resort to storing material ID in your gbuffer and then use branching in your lighting shader. [/quote]

Like I said, why would we particularly care with the upcoming consoles? I, personally, would rather throw ultra high poly meshes and render individual leaves and a hundred shadow mapped lights with ultra high radius's (radii?) than storing however many bdrfs someone might go crazy with. So far as I'm concerned the former will require less art asset creation AND make level designers and modelers happier.

Share this post


Link to post
Share on other sites
InvalidPointer    1842
[quote name='Frenetic Pony' timestamp='1333481707' post='4927973']
[quote name='Chris_F' timestamp='1333359199' post='4927417'] But then you loose the benefit of easily being able to use different BRDFs, unless you resort to storing material ID in your gbuffer and then use branching in your lighting shader. [/quote]

Like I said, why would we particularly care with the upcoming consoles? I, personally, would rather throw ultra high poly meshes and render individual leaves and a hundred shadow mapped lights with ultra high radius's (radii?) than storing however many bdrfs someone might go crazy with. So far as I'm concerned the former will require less art asset creation AND make level designers and modelers happier.
[/quote]

The problem is that they still won't look like leaves, though. [url="http://theplayvault.com/wp/wp-content/uploads/2011/10/Crysis-1-Ultra.jpg"]Even super-dumb N dot E hacks[/url] do an absolutely insane amount to 'sell' the substance of a virtual material. Compare to how [url="http://www.pcgameshardware.de/screenshots/medium/2007/11/Crysis_Ultra_neu_03.jpg"]fake[/url] everything looks when you remove that (even just a stupid change in lighting!) from the equation. (hurp durp that was a punne, or a play on words)

[url="http://i149.photobucket.com/albums/s67/lmj15/shire4.jpg"]Lack of anisotropic shading on hair[/url] will also drag the overall perceived realism down in dramatic, screaming fashion.

In short, I think an extensive library of believable materials is more important than most would think.

Share this post


Link to post
Share on other sites
_the_phantom_    11250
[quote name='InvalidPointer' timestamp='1333485606' post='4927995']
In short, I think an extensive library of believable materials is more important than most would think.
[/quote]

And I think many artists would agree... of course at that point you would have to stop them going crazy with materials and causing a draw call explosion but with a decent stick you can train that out of them ;)

Share this post


Link to post
Share on other sites
FreneticPonE    3294
True, believable materials are something that can definitely be improved upon.

So, I guess it would highly depend on your polycount, amount of different materials you have, and how you store them. Someone smarter than I am, please present a test of the tradeoffs between such variables between pure forward tiled and deffered/forward tiled. Then someone even smarter than them create a deffered shading technique that allows easy usage of arbitrary bdrfs so we don't care anymore [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img]

Share this post


Link to post
Share on other sites
Chris_F    3030
I certainly don't think you need 1000 unique BRDFs, but I roll my eyes at anybody who tries to call a game with just 1 "next-gen". Especially if that BRDF amounts to a simple Phong equivalent.

Share this post


Link to post
Share on other sites
MJP    19754
[quote name='Frenetic Pony' timestamp='1333481707' post='4927973']
Like I said, why would we particularly care with the upcoming consoles? I, personally, would rather throw ultra high poly meshes and render individual leaves and a hundred shadow mapped lights with ultra high radius's (radii?) than storing however many bdrfs someone might go crazy with. So far as I'm concerned the former will require less art asset creation AND make level designers and modelers happier.
[/quote]

Who cares if you have a million lights or a billion triangles if everything looks like plastic?

[quote name='Frenetic Pony' timestamp='1333487764' post='4928009']
Then someone even smarter than them create a deffered shading technique that allows easy usage of arbitrary bdrfs so we don't care anymore [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img]
[/quote]

You don't need anyone to do it for you. Just stuff an ID in your G-Buffer indicating which BRDF to use, and make sure that your G-Buffer has all of the data you need. Then you can branch away. You can also play around with redistributing threads for better coherency, or doing the lighting in multiple passes to prevent the register count from exploding.

The major advantage that forward rendering has is that it can be [i]easier[/i] to do multiple BRDF's, since you can restrict yourself to 1 BRDF per pixel shader and you don't need to have everything in a G-Buffer. There's also the possibility for better performance, since you may not have to branch in a forward renderer.

Share this post


Link to post
Share on other sites
Bombshell93    245
I'm only posting out of curiosity but isn't the title of the topic a bit bold? I had no idea forward rendering was even dead, I understand deferred shading can be of great advantage, but even in some of the best deferred systems forward rendering can still be of great use. Hybrids aside forward rendering when mixed with a pre-z-pass (read and to a tiny degree tested) is a viable alternative and offers many great advantages, ranging from memory and bandwidth saving, to diversity of shaders.

Share this post


Link to post
Share on other sites
InvalidPointer    1842
[quote name='bombshell93' timestamp='1333506286' post='4928078']
I'm only posting out of curiosity but isn't the title of the topic a bit bold? I had no idea forward rendering was even dead, I understand deferred shading can be of great advantage, but even in some of the best deferred systems forward rendering can still be of great use. Hybrids aside forward rendering when mixed with a pre-z-pass (read and to a tiny degree tested) is a viable alternative and offers many great advantages, ranging from memory and bandwidth saving, to diversity of shaders.
[/quote]

Deferred shading is just really, really in vogue right now and it ends up being one of those hobbyist engine bullet points. Plenty of modern games (Skyrim, MW3, Mass Effect 3 and basically any UE3 game for that matter) use forward shading, some to very great effect.

Share this post


Link to post
Share on other sites
Chris_F    3030
[quote name='bombshell93' timestamp='1333506286' post='4928078']
I'm only posting out of curiosity but isn't the title of the topic a bit bold? I had no idea forward rendering was even dead, I understand deferred shading can be of great advantage, but even in some of the best deferred systems forward rendering can still be of great use. Hybrids aside forward rendering when mixed with a pre-z-pass (read and to a tiny degree tested) is a viable alternative and offers many great advantages, ranging from memory and bandwidth saving, to diversity of shaders.
[/quote]

Yes, the title was a gambit to help ensure this topic got some attention since it was something I was particularly interested in. Ever since S.T.A.L.K.E.R. made use of deferred shading, it and light pre-pass have increased in popularity steadily. It seems most "next-gen" engines are going deferred in some way or another. I'm not aware of the exact statistics, but if deferred hasn't already surpassed forward, then it probably soon will if things stay the same.

My title wasn't really so much a statement that forward was dead, but that maybe the growing trend of deferred might swing back around toward forward.

Share this post


Link to post
Share on other sites
Hodgman    51231
[quote name='InvalidPointer' timestamp='1333517902' post='4928111']Deferred shading is just really, really in vogue right now and it ends up being one of those hobbyist engine bullet points. Plenty of modern games (Skyrim, MW3, Mass Effect 3 and basically any UE3 game for that matter) use forward shading, some to very great effect.[/quote]To kind-of expand on this with a rant of my own:

It isn't really as simple as forward vs deferred ([i]so yes, forward techniques definitely didn't "die"[/i]). An engine that lists one or the other as a feature is missing the point (or it's customers are missing the point) -- different games need different rendering pipelines, so an engine must be a platform for developing rendering pipelines. There's a lot more details to a pipeline than at which point you evaluate your lighting functions.

To illustrate: "deferred shadow maps" was a popular technique before deferred shading -- where you use your ZPP to composite shadow maps into a screen-sized buffer. These "S-Buffers" were originally used in forward renderers, but can just as well be used in a deferred renderer, where it can become a part of the G-buffer.
So traditionally, this looks like:
Forward:
[font=courier new,courier,monospace]ZPP [/font]([i]models[/i]) -> [font=courier new]S-Buffer[/font] ([i]lights[/i]) -> [font=courier new,courier,monospace]forward shading[/font] ([i]models*lights/lightsPerPass[/i])
Deferred:
[font=courier new,courier,monospace]G-Buffer[/font] ([i]models[/i]) -> [font=courier new,courier,monospace]S-Buffer[/font] ([i]lights[/i]) -> [font=courier new,courier,monospace]deferred shading[/font] ([i]lights[/i])

But using MRT (tech behind deferred) I can also re-arrange forward to remove the ZPP requirement. By outputting each light's diffuse+specular to a different render-target ([i]and treating ambience as another light/render-target)[/i], then shadowing can be applied [b]after [/b]forward shading ([i]i.e. shade all pixels as non-shadowed, then correctly darken pixels to the right levels after the fac[/i]t). I'll call the forward-render pass's output the [font=courier new,courier,monospace]f-buffer[/font], which gives:
[font=courier new,courier,monospace]forward shading[/font] ([i]models*lights/lightsPerPass[/i]) -> [font=courier new,courier,monospace]S-Buffer[/font] ([i]lights[/i]) -> [font=courier new,courier,monospace]combine[/font] ([i][font=courier new,courier,monospace]final = fbuffer[0..lights] * sbuffer[0..lights] + ambient[/font][/i])

Now what is this? It's a renderer that uses MRT to output forward-shaded pixels to a fat buffer typical of a deferred renderer... and defers it's shadow map filtering, but without the typical ZPP prerequisite... If your light count is low enough, and/or you're ok with some chroma artefacts you could even do this without MRT, and with only a single model rendering pass.
Is it a forward renderer? It makes use of forward shading... Is it a deferred renderer? It defers a lot of rendering calculations using fat buffers...
It's these kind of situation-specific, frankenstein hybrids that you're likely to see behind most games. The "right pipeline" really, really does depend on the game.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this