Why Deferred Rendering is so important?

[frameavenger]

Hi Masters of 3D!!

Why Deferred Rendering is so important for the games?

Examples: GRAW and UE3.0?


Thanks a lot!!
:smile:

 

[ShootMyMonkey]

It's not really "important" per se. It's just another method that proves useful in various situations. The main thing with deferred rendering is that you fill in info in a giant buffer about every point until you've gotten through all the geometry. Then you just render a full-screen flat polygon using that buffer in the pixel shader so it can get info about every point.

The biggest advantage for a lot of games is how well it scales with lighting complexity, especially since you never light a pixel that isn't visible.

Biggest disadvantages include transparency rendering (which is really a pain, but not impossible), and inability to use hardware AA (and even software AA cheats don't work out so smoothly).

 

[SuperCow]

Biggest disadvantages include transparency rendering (which is really a pain, but not impossible), and inability to use hardware AA (and even software AA cheats don't work out so smoothly).

Inability to use hardware AA on the DirectX9/OpenGL API, yes. In DX10 nothing is preventing you to render your G-Buffer in MSAA mode and using custom resolves to process each individual samples prior to the resolve operation.

 

[nAo]

Examples: GRAW and UE3.0?

Dunno about GRAW, but UE3.0 graphics engine is not a deferred renderer, only shadows (maps) computations are deferred (or better decoupled) from the renderer.

Marco

 

[ShootMyMonkey]

I don't think either of them is fully or even *majority* deferred rendering. It's more or less reserved for specific functions. I don't know of any commercial game off the top of my head that uses it, for instance, for all lighting. Deferred shaderized AA cheats, I've seen dozens of places, but I'd call that post-processing more so than "deferred rendering".

 

[frameavenger]

Dunno about GRAW, but UE3.0 graphics engine is not a deferred renderer, only shadows (maps) computations are deferred (or better decoupled) from the renderer.

Marco

RoboBlitz uses UE3.0 and lacks in the Anti-Aliasing option!!!

Why isn't there a menu option to turn on/off Anti-Aliasing (AA) in RoboBlitz?

http://www.roboblitz.com/HTML_SITE/support/support.shtml#system_requirements

* RoboBlitz uses delayed rendering that renders the scene once per visible light, which doesn't allow for realtime AA on today's graphics cards. There might be optimizations made in the future allowing for AA on certain lighting passes, but they're not in place yet, so that means no AA for now (even if you turn it on in your graphics card control panel). You can still turn on Anisotropic Filtering (AF) in your control panel and have that improve the texture filtering.

 

[NeARAZ]

That does not mean deferred rendering. Most likely they just want to say "we render into a floating point buffer, one pass per light to get HDR". AA and floating point buffers are not supported on the majority of hardware, but some of the later HW can do it.

 

[nobond]

Hi,
can you explain
"physicall" where is this giant buffer located in ?

It is in the CPU memory space or the GPU memory space ?

It's not really "important" per se. It's just another method that proves useful in various situations. The main thing with deferred rendering is that you fill in info in a giant buffer about every point until you've gotten through all the geometry. Then you just render a full-screen flat polygon using that buffer in the pixel shader so it can get info about every point.

The biggest advantage for a lot of games is how well it scales with lighting complexity, especially since you never light a pixel that isn't visible.

Biggest disadvantages include transparency rendering (which is really a pain, but not impossible), and inability to use hardware AA (and even software AA cheats don't work out so smoothly).

 

[ShootMyMonkey]

It's in GPU memory space in any major case I could possibly bring up. The "giant" buffer is a render-to-texture field, so it gets used in a later pass as a texture from which to access data and actually draw stuff based on what you find in the buffer. On the PC, it will be at least another 2 decades or longer (I actually believe it will be never) before bandwidth to/from main memory and the bandwidth across the video card's buslink is capable of keeping up with the data throughput rate necessary to move that much data as fast as the GPU would like.

If some sort of CPU-side processing is necessary for whatever reason, it'll usually be copied after the fact, but the preference is to do all that work on the GPU if you can.

Consoles are another ball of wax -- e.g. Xbox360 having one memory pool, or PS3 having not too bad observed bandwidth from the GPU to the main memory pool compared to its observed bandwidth to its own local pool. That said, I can't say I've ever heard of any specific counterexample.

 

[nobond]

For the Deferred Mode Rendering

Still something a little bit confused.

To my knowledge, even the non-deferred mode (immediate mode) you still need to buffer something
then kick off a render. What is the point to make a distinctin between the immediate mode and deferred mode ( maybe just the difference of the buffer ...)

 

[Simon F]

If you are referring to PowerVR's deferred rendering, then it also does so re-ordering of the polygons as it puts data into the pre-rasterisation buffer. In fact, that buffer is not just a single big FIFO but consists of multiple "bins".

 

[Cal]

GRAW X360 did not use deferred shading, but the PC version did. The online part of SCDA used deferred shading.

As for the advantages of DS: in current graphics pipeline, pixle shading is always done before ROP (including z-test), that means every pixel on a geometry will be shaded in despite of its visibility. So if DS is applied, by generating a g-buffer we can manage to do the z-test before actual shading. Even the latest hardwares featuring early z-test via hierarchical-z are not as efficient as DS. Another good aspect of DS is you can add a lot of light sources. Just project the light volume into screen space and rendering it with g-buffer, no pixel will be wasted.

 

[nAo]

Even the latest hardwares featuring early z-test via hierarchical-z are not as efficient as DS.

Umh..this is not really true, in the general case.

 

[Rodéric]

As for the advantages of DS: in current graphics pipeline, pixle shading is always done before ROP (including z-test), that means every pixel on a geometry will be shaded in despite of its visibility.

AFAIR, it's not true, as long as the fragment shader doesn't change the depth or texkill, the depth test is performed before shading, that's the early-z reject test.

 

[ShootMyMonkey]

To my knowledge, even the non-deferred mode (immediate mode) you still need to buffer something then kick off a render. What is the point to make a distinctin between the immediate mode and deferred mode ( maybe just the difference of the buffer ...)

I think you're confusing things like the vertex buffer and index buffer with the g-buffer in a deferred shader. The buffering of geometry before sending it off is grouping some sections or groups of geometry into a single batch sent off at once. This you typically group by renderstates (including things like transformations, which shaders, and which textures need be applied). That's something you do anyway. That's buffering the *input* to the GPU. In a deferred shader, on the "main" pass, you have a giant buffer that is the *output* of that pass.

Deferred shading means the actual "shading" part is not done immediately on that main pass. Rather, there is a pass that renders information about how to shade the pixels. Information on a per-pixel level is buffered off and then there's a "deferred" pass that actually does the shading.

Comparatively, with an immediate mode renderer, the output you get in the primary pass is the actual shaded pixels (i.e., they're shaded "immediately").

I'm kind of ignoring other passes you make like shadow map passes and what not, because those are really independent of how you actually perform your shading. Although since the word "deferred" has the meaning of postponing something, there are certain other cases where it's used in a different context. For instance, PSP has both immediate mode and deferred mode rendering, but what's deferred is actually the issuing of geometry.

 

[Cal]

AFAIR, it's not true, as long as the fragment shader doesn't change the depth or texkill, the depth test is performed before shading, that's the early-z reject test.

Then you need a pre-zpass to use hier-z. Alpha masked object like foliage will cause trouble there when you try to exploit the z-only double speed output.

Umh..this is not really true, in the general case.

Well, I haven't tested deferred shading thoroughly. But according to my experience, the vertex cost is still there when the early z-reject is enabled in the regular rendering mode.

 

[ERP]

The PowerVR version of deffered shading needed to do the vertex work aswell. As would any solution that allowed vertex shader to do none standard transforms.

You could strip all the unneeded crap out, and with stream out, you could even do the transform work only once.

 

[Mintmaster]

Even the latest hardwares featuring early z-test via hierarchical-z are not as efficient as DS. Another good aspect of DS is you can add a lot of light sources. Just project the light volume into screen space and rendering it with g-buffer, no pixel will be wasted.

Not really true at all. You need a lot of extra bandwidth to write the normals and position then read them back. Even using Z and calculating position is a notable cost. Then there's lack of AA as well.

Then you need a pre-zpass to use hier-z. Alpha masked object like foliage will cause trouble there when you try to exploit the z-only double speed output.

Early z-test doesn't have to use a Z prepass. Rough front to back sorting will take care of most of the overdraw. Even if you did a prepass, lack of double Z under certain circumstances is almost irrelevent nowadays because the base pixel fill rate is so high. 10 GPix/s will fill a 1080p screen with 5x overdraw in a millisecond. The setup cost of sending twice the geometry is a bigger issue.

 

[nAo]

Well, I haven't tested deferred shading thoroughly. But according to my experience, the vertex cost is still there when the early z-reject is enabled in the regular rendering mode.

You assume deferred shading has not additional costs compared to non deferred shading, unfortunately this is not true as writing and reading back g buffer(s) is not free from a performance and memory stand point.
Can be a win in the end, but as I said, not in the general case.

 

[Andrew Lauritzen]

The largest advantage of deferred shading is the decoupling of lighting and surface computations, which simplifies engine management, improves batching, improves asymptotic complexity and solves the light contribution problem cheaply per-pixel.

It's also often useful to have various attributes (such as depth) available in the shader. Still this is a secondary benefit IMHO.

I wouldn't be surprised if more games star using deferred shading in the future. Sure it has it's share of overhead, but much of that is becoming less important as technology progresses. In particular, coherent and predictable memory access like that of deferred shading can be totally hidden (in the long run, if not already) - it will be random access that poses a significant problem for all architectures (and for algorithms in general) in the long run.

Having written both a forward and deferred renderer, I personally like the latter much more It's simple, elegant and efficient. It also runs plenty fast on modern hardware.