-
Notifications
You must be signed in to change notification settings - Fork 279
History
Dzmitry Malyshau edited this page Feb 1, 2017
·
1 revision
The benefits of tiles:
- In some cases, rendering into a tile can be completely omitted. For example, if we know that a tile is fully covered by another primitive that is supposed to be on top of the current one, there is no need to draw the current. The main save here is in the fragment processing and fill rate.
- They serve as a coarse collision detection structure, allowing us to conclude that some primitives don't overlap, which reduces the constraints on batching, resulting in less batches being generated. The main save here is the number draw calls and state switches.
The problems of tiles:
- Each primitive needs to draw a separate instance for each tile that it intersects, which adds vertex processing and primitive assembly load.
- Transformed primitives have complex shader logic to figure out what pixels they affect. These shaders do quite a bit of work on the vertex processing side, and also issue a discard on the pixel side, which prevents HiZ and early-Z hardware optimizations, also increasing the rasterizer and fragment processing load.
- Code complexity, including the separate set of shaders for the transformed case.
- Difficulty handling the effects that need to sample outside of their bounds, e.g. blur.
If we simply remove the tiling code, we'd face the overhead from the increased fragment processing and draw call count. However, using the depth testing can partially address the fragment processing cost:
- we draw the opaque primitives front to back (so, in the opposite order from what they are given in the display list), we test & write the depth
- we draw the transparent primitives back to front, just testing for the depth
This way, the pixels occluded by other primitives get rejected by the depth, which helps reduce the fragment processing load. Note that the depth testing is not an alternative to tiles, it just helps the tile-less case more.
Benchmarking regular websites (like https://github.com/servo/servo) showed the depth + no tiles code path to be faster than the old tiled one. Coming up with the worst case for the new approach is still TODO.
The transition to tile removal happened in 2 stages:
- The depth testing was enabled in https://github.com/servo/webrender/pull/648
- The tiles got removed in https://github.com/servo/webrender/pull/685