Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Understanding iPhone OpenGL Profiling

My app is up and running and now I am looking to improve the rendering performance. Using 'Instruments' I have collected some data. I am working with an old iPhone 3G as a worst case senario.

Time Profiler:

-30%    CopyVertexElementsMultipleSequential
-11%    mach_msg_trap
-4%     _semwait_signal
-2%     ValidateState

However using the Open GL ES Driver, the Sampler reads:

-70%    _semwait_signal
-24%    CopyVertexElementsMultipleSequential
-0.7%   mach_msg_trap

Poking around the docs I haven't been able to come with what what the difference between the OpenGL ES Sampler and the Timer Profiler are. Can anyone enlighten me?

like image 552
TurqMage Avatar asked Apr 22 '11 00:04

TurqMage


1 Answers

First, that's just the Sampler instrument you're looking at. The OpenGL ES Driver template simply includes the Sampler instrument along with the OpenGL ES Driver one. It doesn't have anything special to do with OpenGL ES.

The Sampler instrument and the Time Profiler differ in the way they gather data. From the Instruments User Guide:

The Time Profiler instrument and the Sampler instrument are similar, but there are some differences:

  • Time Profiler gathers backtrace data in the same manner as Shark, from kernel space. Sampler, on the other hand, gathers data from user space. Consequently, Time Profiler is more efficient than Sampler at gathering data.

  • Note: Time Profiler (and Shark) can yield inaccurate backtrace data if the target process is optimized to omit frame pointers.

  • Time Profiler can gather data from one or all processes. Sampler can only sample a single process.

  • Time Profiler can sample all thread states or running threads only. Sampler always samples all thread states. Generally, you’re interested in running threads. When your application is hung, you want to examine all thread states.

I prefer to use Time Profiler myself, with appropriate data mining like charging libraries or methods to their callers.

In regards to profiling an OpenGL ES application, you'll want to look first at the various statistics that you can enable in the OpenGL ES Driver instrument. Click the i to the right of the instrument name to bring up a popup, then click Configure to show a list of possible statistics you can log. In particular, look at the Tiler Utilization and Renderer Utilization stats. Enable the ones you want, go back to the previous screen, and click the checkboxes to make sure they're logged.

If your application maxes out the Tiler Utilization stat, you are being limited by the size of your geometry. Do what you can to reduce that (using some of the tips I mention here) and you'll see a significant boost in performance. On the other hand, if you're hitting a Renderer Utilization max, you're fill-rate limited and you may need to turn off MSAA, tune your fragment shaders (if on OpenGL ES 2.0), or reduce the size of the area you're rendering, among other things.

Beyond that, run your application on a device that's on iOS 4.0 and use the new OpenGL ES Analyzer instrument that comes with Xcode 4. That instrument is great for suggesting hotspots in your rendering code, or wasted performance from redundant state calls, etc.

Looking at your specific trace data, it appears that you are spending an awful lot of time copying geometry to the GPU. I'd look at using a vertex buffer object (VBO) to significantly reduce that.

like image 133
Brad Larson Avatar answered Oct 29 '22 11:10

Brad Larson