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

The traditional way to handle this process is known as forward rendering. With for-
ward rendering, geometry is rendered with various surface properties stored in the vertex
attribute data, in textures, and in constant buffers. Then, for each pixel that is rasterized for
the input geometry, the material data is used to apply the lighting equation for one or more
lights. The results of evaluating the lighting equation are then output for each pixel, and
possibly summed with the previous contents of the render target. This approach is straight-
forward and intuitive, and it was the overwhelmingly dominant approach for real-time
3D graphics before the advent of programmable graphics hardware. These fixed-function
GPUs (and the earlier Direct3D APIs for using them) supported three different light types,
as follows:
1. Point lights —these lights have an equal contribution in all directions and are at-
tenuated based on the distance from the light source to the surface being lit. As a
result, they have a spherical area of effect.
2. Spot lights —these have a direction associated with them, and the light contribu-
tion is attenuated based on the angle between the surface and the light direction.
Consequently, spot lights have a conical area of effect.
3. Directional lights — unlike the other two light sources, this type is considered a
"global" light source. This is because the position of the surface is not taken into
account when determining the light contribution. In fact, directional light sources
have no position, and are instead defined by only a direction. The light is treated
as if it were a point light infinitely far away from the surface, in the direction
specified for the light.
As real-time rendering engines have scaled to accommodate programmable hardware
and more complex scenes, these basic light types have mostly remained, due to their flex-
ibility and ubiquity. However, the means in which they are applied have begun to show
to show their age. This is because with modern hardware and APIs, forward rendering
exhibits several key weaknesses when it comes supporting large numbers of dynamic light
sources.
The first disadvantage is that the application of light sources is tied to the granular-
ity at which scene geometry is drawn. In other words, when we enable a light source, we
must apply it to all the geometry that is rasterized during any particular draw call. At first
it may not be obvious why this is a bad thing, especially for simple scenes with few lights.
However, as the number of lights scales up, it becomes important to apply a light source
selectively, to reduce the number of lighting calculations performed in the pixel shader.
But since changing which lights are applied can only be done in between draw calls, we're
limited in how much we can cull lights that aren't needed. So for cases where a light only
affects a small portion of the geometry rasterized by a draw call, we must still apply that
light to all geometry, since we can't selectively apply the light per-pixel. We could split the