Downscale Render Targets (If Possible)

Examining the trade-off between performance and graphics quality

As described in Remove Unused Render Targets, more render targets mean more tiles that demand more GMEM operations, affecting performance. Similarly, larger surfaces also mean more tiles and more GMEM operations.

But in Avoid GMEM Loads and Remove Unused Render Targets, the app was doing something unnecessary that harmed performance, so each fix resulted in a pure gain of performance. In other cases, the choice is not so clear-cut. You may have to decide between better performance and higher graphics quality.

You can use Snapdragon Profiler to help you make that decision. Its metrics let you see how rendering graphics at different levels of quality affects performance. Based on the results, you can add settings to your app to let users regulate the trade-off between performance and graphical intensity.

Using Snapdragon Profiler in Trace Capture mode, you can utilize the Rendering Stages metric. The screenshot below is based on the Depth of Field demo application:

Clicking on surfaces lets you examine properties like size and Color/Depth/Stencil precision in the Inspector view and quickly traverse all the drawn surfaces. Once you have found candidates for downscaling, you can decide whether to change precision or size. The screenshot below shows scene rendering using a DEPTH24_STENCIL8 target:

Since the underlying type is UINT32, the DEPTH24 value (24 bits per pixel) is being inefficiently stored in a 32-bit container. That is an opportunity for optimization, if it does not visibly sacrifice quality.

After modifying the code for the selected surfaces from 32 to 16bits per pixel, you can validate the results in Trace Capture mode:

The Inspector view shows that the Stencil attachment is now absent and render time (Duration) has decreased from 2.17ms to 2ms, for a small overall performance improvement.

Also, the number of bins rendered has dropped from 30 to 24. Note that it is not really possible to predict the kind of bin reduction a code change will cause. In general, though, a surface (e.g., RenderTarget) that is smaller in height/width dimensions or uses fewer bits per pixel will require fewer bins (and GMEM tiles) to process.