So far in this series, I’ve described what PVRTrace is and outlined the core features of PVRTraceGUI. In this post, I’ll detail the advanced features of our analysis tool that simplify the process of identifying misuses of the API, redundancies & potential performance bottlenecks.

PVRTrace

Pixel Analysis: Frame Summary

PVRTraceGUI_PixelAnalysis

Selected Pixel

A pixel can be selected by clicking on it in the Image Analysis widget. When this is done, the Selected Pixel interface displays the coordinates of the pixel & lists the fragment shader ID’s than contributed to its colour. This inspection – paired with our Depth Complexity and PowerVR Depth Complexity modes – makes it easy to identify redundant/unnecessary blended primitives in the render that can be optimized out.

Frame Summary

The Frame Summary uses data from our Image Analysis and offline profiling compilers to highlight the most ALU intensive parts of the render’s fragment shading.

In the above screenshot, we can see that shader A (#12110173) accounts for more than 50% of the ALU cost of colouring pixels in the frame. Although this shader is only 7 cycles, reducing this to 6 cycles or less will be the best way to increase performance on an ALU bottlenecked device as the shader is used on so many pixels. The next most costly shader is B (#7490107) – accounting for ~20% of the pixel processing computations. As shader B requires many more cycles than shader A, there are likely to be more opportunities to optimize it.

Image Analysis: Pixel Heatmap

PVRTraceGUI_Heatmap

As the name suggests, this mode visualizes fragment shader ALU complexity by rendering a heatmap. This uses a colour scale of red (the most expensive shaders) to green (the cheapest shaders).

Paired with the data in the Pixel Analysis widget, this mode makes the process of isolating the costly parts of your render trivial.

Export Data

It’s basic, but it’s extremely useful. The FileàExport Data options can be used to dump the call log, the call statistics (e.g. the number of times each call is made in the recording) & all of the shaders that were captured. This data can then be inspected outside of PVRTraceGUI or parsed in custom tools.

Conclusion

The PVRTraceGUI interface is designed to give you everything you need to quickly identify redundancies and errors in your render. In our upcoming 3.2 SDK release, we’ll be adding a whole host of new features that will make this even easier.

In the next post, I’ll detail how the Playback tool can be used to replay captured data on any of our supported platforms, and also discuss how the Trace Modifications feature can be used to make simple alterations to shaders and the GL call stream for testing (much safer than attempting to hack code in a complex rendering engine!). In the meantime, please check out the previous posts in the series, download the PowerVR Graphics SDK (if you haven’t done so already) and post on our forum if you have any questions. Remember to follow us on Twitter (@ImaginationPR and @PowerVRInsider) and subscribe to our blog.

About the author: Joe Davis

Profile photo of Joe Davis

Joe Davis leads the PowerVR Graphics developer support team. He and his team support a wide variety of graphics developers including those writing games, middleware, UIs, navigation systems, operating systems and web browsers. Joe regularly attends and presents at developer conferences to help graphics developers get the most out of PowerVR GPUs. You can follow him on Twitter @joedavisdev.

View all posts by Joe Davis