Jump to content

  • Log In with Google      Sign In   
  • Create Account

Revival of Forward Rending?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
35 replies to this topic

#21 Chris_F   Members   -  Reputation: 2461

Like
0Likes
Like

Posted 02 April 2012 - 02:35 AM

How easy would it be to implement transparency in a LI renderer? The z prepass suffers from the same issue as a geometry pass in a deferred shading renderer.

Sponsor:

#22 phantom   Moderators   -  Reputation: 7558

Like
0Likes
Like

Posted 02 April 2012 - 02:52 AM

It would be the same as a normal forward lighting system; render transparent objects back to front. You'd just get early rejection for objects which are behind the layed down z-pass.

The other option is an order independant transparency system but those are still pretty heavy on the hardware it would seem.

#23 olaolsson   Members   -  Reputation: 136

Like
0Likes
Like

Posted 02 April 2012 - 03:20 AM

It would be the same as a normal forward lighting system; render transparent objects back to front. You'd just get early rejection for objects which are behind the layed down z-pass.


Just note that the restriction applies to lights as well, so when you build the grid you can only reject lights entirely behind the scene (only use max depth). Obiously one could elaborate on this with a min depth buffer, but before you know it we'll have implemented depth peeling :)

Otherwise I think the fact that you can reuse the entire pipeline including shader functions to access the grid, is one of the really strong features of the tiled deferred-forward combo. Easy to to tiled deferred for opaque objects, and then add a tiled forward for transparent, if that is what works. It is very easy to move between tiled deferred and forward shading, and this got to be good for compatibility/scaling/adapting to platforms.

#24 Chris_F   Members   -  Reputation: 2461

Like
0Likes
Like

Posted 02 April 2012 - 03:33 AM

Just note that the restriction applies to lights as well, so when you build the grid you can only reject lights entirely behind the scene (only use max depth). Obiously one could elaborate on this with a min depth buffer, but before you know it we'll have implemented depth peeling Posted Image

Otherwise I think the fact that you can reuse the entire pipeline including shader functions to access the grid, is one of the really strong features of the tiled deferred-forward combo. Easy to to tiled deferred for opaque objects, and then add a tiled forward for transparent, if that is what works. It is very easy to move between tiled deferred and forward shading, and this got to be good for compatibility/scaling/adapting to platforms.


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.

#25 MJP   Moderators   -  Reputation: 11737

Like
0Likes
Like

Posted 02 April 2012 - 01:07 PM

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.).


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. Posted Image

#26 olaolsson   Members   -  Reputation: 136

Like
0Likes
Like

Posted 02 April 2012 - 05:51 PM

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.

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).

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.

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.

Everybody always just does point lights in their demos. Posted Image

Yes, guilty as charged... damn those paper deadlines :)

#27 Frenetic Pony   Members   -  Reputation: 1396

Like
0Likes
Like

Posted 03 April 2012 - 01:35 PM

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.


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.

#28 InvalidPointer   Members   -  Reputation: 1443

Like
0Likes
Like

Posted 03 April 2012 - 02:40 PM

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.


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.


The problem is that they still won't look like leaves, though. Even super-dumb N dot E hacks do an absolutely insane amount to 'sell' the substance of a virtual material. Compare to how fake 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)

Lack of anisotropic shading on hair 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.
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.

#29 phantom   Moderators   -  Reputation: 7558

Like
0Likes
Like

Posted 03 April 2012 - 03:01 PM

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


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 ;)

#30 Frenetic Pony   Members   -  Reputation: 1396

Like
0Likes
Like

Posted 03 April 2012 - 03:16 PM

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 Posted Image

#31 Chris_F   Members   -  Reputation: 2461

Like
0Likes
Like

Posted 03 April 2012 - 04:15 PM

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.

#32 MJP   Moderators   -  Reputation: 11737

Like
0Likes
Like

Posted 03 April 2012 - 07:01 PM

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.


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

Then someone even smarter than them create a deffered shading technique that allows easy usage of arbitrary bdrfs so we don't care anymore Posted Image


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 easier 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.

#33 bombshell93   Members   -  Reputation: 210

Like
1Likes
Like

Posted 03 April 2012 - 08:24 PM

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.

#34 InvalidPointer   Members   -  Reputation: 1443

Like
1Likes
Like

Posted 03 April 2012 - 11:38 PM

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.


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.
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.

#35 Chris_F   Members   -  Reputation: 2461

Like
0Likes
Like

Posted 04 April 2012 - 05:55 AM

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.


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.

#36 Hodgman   Moderators   -  Reputation: 31799

Like
4Likes
Like

Posted 04 April 2012 - 06:50 AM

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.

To kind-of expand on this with a rant of my own:

It isn't really as simple as forward vs deferred (so yes, forward techniques definitely didn't "die"). 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:
ZPP (models) -> S-Buffer (lights) -> forward shading (models*lights/lightsPerPass)
Deferred:
G-Buffer (models) -> S-Buffer (lights) -> deferred shading (lights)

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 (and treating ambience as another light/render-target), then shadowing can be applied after forward shading (i.e. shade all pixels as non-shadowed, then correctly darken pixels to the right levels after the fact). I'll call the forward-render pass's output the f-buffer, which gives:
forward shading (models*lights/lightsPerPass) -> S-Buffer (lights) -> combine (final = fbuffer[0..lights] * sbuffer[0..lights] + ambient)

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS