Hidden Surface Removal Efficiency

Overdraw is where pixels are wastefully coloured when they will not contribute to the final image colour as they are overwritten by another object.

In a traditional IMR architecture, the scene shown above would cause green and red colours to be calculated for the sphere and cube respectively in the areas that are occluded by the yellow cone.

In architectures that include early-Z testing, an application can avoid some overdraw by submitting draw calls from front to back. Submitting in this order builds up the depth buffer so occluded fragments further from the camera can be rejected early. However, this creates additional burden for the application, as draws must be sorted every time the camera or objects within the scene move. It also does not remove all overdraw as sorting per-draw is very coarse – for instance, it cannot account for overdraw caused by object intersections. It also prevents the application from sorting draw calls to keep graphics API state changes to a minimum.

With PowerVR TBDR, Hidden Surface Removal (HSR) will completely remove overdraw regardless of draw call submission order.

The screenshot below is a capture from MadFinger Game’s Shadowgun.

The image below highlights the amount of overdraw in the same scene, ignoring early-Z or HSR optimisations that may be applied by a graphics core. The closer to white a pixel is, the more overdraw is present.

In this frame, 4.7 fragments are coloured on average per screen pixel.

The final image below shows the amount of “PowerVR overdraw” (post-HSR) for the same captured frame. On a PowerVR device, 1.2 fragments are coloured on average per screen pixel, which is 75% fewer fragments than the application submitted.

The render cannot achieve a 1:1 ratio between coloured fragments per screen pixel as the scene isn’t completely opaque, because blended UI elements are contributing to the average.