Deferred Rendering - Practical Rendering and Computation with Direct3D 11 - page 489

meshes in the scene into smaller parts to improve granularity, but this increases the number
of draw calls in a frame (and thus increases the CPU overhead). It would also increase
the number of intersection tests required to determine if a light affects a mesh, which also
increases the amount of work performed by the CPU. Another related consequence is that
our ability to render multiple instances of geometry in a single batch is reduced, since the
set of lights used has to be the same for all of the geometry instances in a batch. Since in-
stances may appear in different areas of a scene, they typically will be affected by different
combinations of lights.
The other major disadvantage of forward rendering is shader program complexity.
Being able to handle various numbers of lights and light types with various material varia-
tions can require an explosion in the number of required shader permutations. 2 A high
number of shader permutations is undesirable, since it increases memory usage, as well
as overhead from switching between shader programs. Depending on how the permuta-
tions are compiled, they can also significantly increase compilation times. An alternative
to using many shader programs is to use dynamic flow control, which has various GPU
performance implications. Another alternative is to only render one light at a time and
additively blend the result into the render target, which is known as multipass rendering.
However, this approach requires paying the cost for transforming and rasterizing geometry
multiple times. Even ignoring the issues associated with using many permutations, the re-
sulting pixel shader programs can become very expensive and complex on their own. This
is because of the need to evaluate material properties and perform necessary lighting and
shadowing calculations for all active light sources. This makes the shader programs dif-
ficult to author, maintain, and optimize. Their performance is also tied to the overdraw of
the scene, since overdraw results in shading pixels that aren't even visible. A z -only prepass
can significantly reduce overdraw, but its efficiency is limited by the implementation of the
Hi- Z unit in the hardware. Shader executions will also be wasted, since pixel shaders must
run in 2×2 quads at a minimum, which can be particularly bad for highly-tessellated scenes
with many small triangles.
These disadvantages collectively make it difficult to scale the number of dynamic
lights in a scene while maintaining adequate performance for real-time applications.
However if you look at the descriptions very carefully, you'll notice that all of these disad-
vantages stem from one primary problem that is inherent to forward rendering: lighting is
tightly coupled with the rasterization of scene geometry. This means that if we were to de-
couple those two steps, we could potentially limit or completely bypass some of those dis-
advantages. But how can we do this? If we look at step 2 in the lighting process, we see that
to calculate lighting, we need both the material properties and the geometric surface prop-
erties for our scene geometry. This means that if we have a step where we rendered out all
2 The term shader permutations refers to compiling many variants of shader program using common HLSL
source code as the base. Typically, conditional compilation and macros are used to enable or disable certain por-
tions of the shader program, and the permutations are compiled with various combinations of those features