Counterattack of the forward framework: parsing forward + Rendering

Reprinted please indicate the source for the klayge game engine, this article address for http://www.klayge.org/2012/04/21/forward%e6%a1%86%e6%9e%b6%e7%9a%84%e9%80%86%e8%a2%ad%ef%bc%9a%e8%a7%a3%e6%9e%90forward%e6%b8%b2%e6%9f%93/

AMD also launched the LEO demo at the time of the release of the 7900 series video card, indicating that it was not completed by using the popular deferred framework in recent years, but by using a framework called forward +. This framework can still render thousands of light sources in real time without the need for high bandwidth of deferred. In eg2012, a new paper called forward +: bringing deferred lighting to the next level describes this method. However, the author has not yet published the full text of this paper. Here I can only use a few words and AMD documents to parse this magic forward +.

Tiled-based deferred Shading

Before getting started, let's review Intel's tiled-based deferred shading mentioned in Siggraph courses 2010. Its Algorithm Framework is:

1. Generate G-buffer, which is the same as the traditional deferred shading.
2. Divide G-buffer into many 16 × 16 tile, and each tile gets the bounding box according to the depth.
3. For each tile, calculate the bounding box and light to obtain the Light sequence that contributes to the tile.
4. For each pixel of G-buffer, use the light sequence of its tile to accumulate and calculate shading.

In the original deferred framework, each light needs to draw a light volume to determine which pixel (that is, light culling) it will affect ). The tiled based method requires only one pass to calculate the intersection of all the light sources. If you use the OIT method used by AMD in Mecha demo, you can also create a per-tile linked list to directly store the Light sequence in the linked list.

Forward + Rendering

With the foundation of tiled-based deferred shading, it is much easier to understand forward +. The relationship between forward + rendering and tiled-based deferred shading is like the previous forward shading and deferred shading, so we can draw a picture once:

1. Z-Prepass, many forward shading will use this as optimization, and in forward +, this becomes an inevitable step.
2. Divide the Z-buffer into many 16 × 16 tile, and each tile gets the bounding box according to the depth.
3. For each tile, calculate the bounding box and light to obtain the Light sequence that contributes to the tile.
4. For each object, the Light sequence of the tile where the pixel is located is used in PS to accumulate and calculate the shading.

It can be seen from this that the first two steps are similar to tiled-based deferred shading, but only the Z-buffer, without G-buffer, which consumes a lot of bandwidth (the minimum value of G-buffer is 32bit color + 32bit depth ). The third step is exactly the same. Fourth, because forward is used, there are various advantages of forward:

• Complex Materials
• Support for hardware AA (although I always think that hardware AA is a huge waste even if it is more than enough)
• High bandwidth utilization
• Supports transparent objects

Light has already been cached in step 3, so we can mix the material with the light source, unlike the traditional forward. With the ability of dynamic branches in the shader, it is not difficult to implement massive light source support like deferred. Because the bandwidth saves a lot, the forward + speed is faster than the deferred speed. The performance in the original paper is sufficient to explain this problem.

Another interesting thing is the rendering of transparent objects. Although I used the deep G-buffer method in klayge to solve the rendering of transparent objects in pure deferred. As many readers have pointed out, doubling the bandwidth caused by this operation slows down the entire system to a large extent. In forward +, when the first step is to generate the Z-Prepass, the dual Z-buffer method can be used, one is to put the Z of the opaque object, and the other is to put the Z of the transparent object. When calculating the tile bounding box in the second step, a total bounding box is calculated regardless of transparency. The subsequent steps remain unchanged to support transparent objects.

With Z-buffer, other benefits for deferred, such as GI and SSR, can be directly applied. For methods such as ssao and ssvo, if pixel normal needs to be considered, appropriate modifications are required for the application.

In amd demo, steps 2 and 3 are implemented using compute shader. In the blog tiled-based forward rendering, he fully implemented the per-tile linked list using ps, but still needed the UAV feature of d3d11. Therefore, forward + cannot be implemented on the hardware before d3d11.

Summary

As a new development of the forward framework, forward + provides us with a new idea. Such competitive development is always better than that where all resources are invested and the other party is ignored.

From the perspective of contribution, the most breakthrough is not the forward part, but the tiled-based part. Forward + can only be counted as "Forward" of tiled-based deferred shading ". By the way, GPUs on many mobile platforms support tiled-based rendering (TBR) on hardware, which is also used to maximize computing relevance and bandwidth utilization. Tegra that does not support TBR will suffer a lot.