What do you need help with?

Optimizing Applications on ODG Glasses

Follow

It is commonly reported that processor CPU, GPU and resource intensive Apps tend to heat up the glasses, especially when the glasses are charging from a Power Hub battery. If all compute elements are pegged, it is possible to raise the surface temperature of the glasses ~ 30 C over the ambient temperature.

We know that if the glasses are charging and running a lot of processing, they will heat up. It is unfortunately a matter of thermodynamics; the glasses have only a small surface area to diffuse ~ 5-6 Watts of power when they are running flat out. We have the ability to throttle down the CPUs clock rate based on temperature, and we do that now, but only to protect the hardware, and to maintain a max 35 C temp differential. We could change that to kick in sooner, but then all Apps would not get the cycles they wanted during peak periods, and would be less performant, so it is a trade off. Usually the best approach is to try and optimize the application. Many times, Apps are built using engines like Unity that are running a virtual machine (Unity runs a derivative of Mono) which are flexible, but inherently inefficient. Codecs and image processing are the other usual areas which do heavy processing.

For this reason, it is good to know which audio & video codec(s) your App is using. Depending on if there's an alternative to pick one that is hardware based, that can reduce the heat.  WebRTC is a component that can be configurable, and is most likely using a software based codec (VP8 perhaps?), which are using cycles which may not show up when you look at the CPU load. One thing to investigate is the codecs in use and if you can switch to one that is implemented in hardware on the Snapdragon version in your glasses. HW encoding for VP8 is not available on the 805 (R-7). Attached an App that can be run on the R-7 and it will give you a list of all supported encoders and decoders; Changing to H.264 would help.

We also know there are areas in the system that are known to be not currently (KitKat) optimized well, particularly around the use of the camera. The CPU utilization you are seeing is what we typically see. One offender, mm-qcamera-daemon is qualcomm proprietary process that includes the camera server, media control, sensor drivers etc. All qualcomm proprietary solutions run as linux daemons. We do have the sources for the mm-camera, but we've made no changes to it. Only drivers have been adapted for our platform. Changes made post KitKat we are eventually going to pick up when we update the OS. Our current plan is to update the R-7 to Android 6 / Marshmallow; the current plan has us completing that in Q117, but in advance of that, we are pretty unlikely to do any optimization of the current KitKat implementation.

We certainly will look at performance once we update to M. But, know that we are also updating our line of glasses to the best CPUs available from Qualcomm, and so we will have the best performance possible in a mobile device. We'll be announcing more details about all of that as we approach CES in Jan.

 

Optimization Checklist:

Most developers probably already know and have looked at these, but some of the things to check:

  1. Can you turn down your camera frame rate without effecting performance below a satisfactory level?
  2. Is your image processing per frame open ended? Can it be optimized, or throttled at least, again without effecting performance below a satisfactory level?
  3. Is your GPU rendering as optimized as possible?
  4. Can you reduce the display brightness within your use case (not advised unless your use case has very static lighting conditions).
  5. As the device heats up and crosses a temp threshold, it will clock down; does this make your App thrash and be even less efficient?

Profiling tools vary, providing a view at the Linux process or application thread level.  We did see this one recently advertised:

https://developer.qualcomm.com/software/snapdragon-profiler?utm_source=exacttarget&utm_medium=email

 

To view Linux level process utilization, adb shell into the glasses, and you should be able to use top to get a Linux level process activity snapshot.

 

130|shell@apq8084:/ $ top -?

Usage: top [ -m max_procs ] [ -n iterations ] [ -d delay ] [ -s sort_column ] [ -t ] [ -h ]

   -m num  Maximum number of processes to display.

   -n num  Updates to show before exiting.

   -d num  Seconds to wait between updates.

   -s col  Column to sort by (cpu,vss,rss,thr).

   -t      Show threads instead of processes.

   -h      Display this help screen.

Have more questions? Submit a request

Comments

Powered by Zendesk