November 6, 2019 update:
  • There's a new open source Cardboard SDK for iOS and Android NDK that offers a streamlined API, improved device compatibility, and built-in viewer profile QR code scanning. A corresponding Unity package (SDK) is planned for a future release. We recommend that all developers actively building for Google Cardboard migrate (iOS, Android NDK) to the new Cardboard SDK.
October 15, 2019 update:
  • The Daydream View VR headset is no longer available for purchase. However, you can continue to use the existing Google VR SDK to update and distribute your apps to the Google Play Store, and make them available to users in the Daydream app.

Performance HUD

The Daydream Performance HUD is a performance overlay enabled for all Daydream applications built with Google VR SDK 1.60 and above. It provides a quick insight into performance issues you might encounter when working with VR applications.

This tool is useful if you’re trying to monitor frame rate or asynchronous reprojection issues while you’re working within VR. The overlay is rendered in stereo and head-locked so you don’t need to leave VR to see this data.

Using this overlay, you are able to see:

  • Application frame submit rate and whether frames were blocked on the GPU
  • Asynchronous Reprojection statistics
  • Process memory usage
  • How many degrees (°C) the device is from thermal throttling

Enabling the HUD

  1. Open VR Settings, available by tapping the gear icon at the top right of the phone's screen after launching a Daydream application.
  2. Tap Build Version six times to make the Developer Options item appear.
  3. Select Developer Options -> Enable performance heads-up display. Enabling this option also implicitly enables the Enable performance monitoring option.

  4. You should now see the performance overlay the next time you run a VR app.

Metrics displayed

Application Rendering Metrics

This graph shows the behaviour of your running VR application.

  • Submitted: The number of application submitted frames per second, ideally matching the device hardware frame rate.

  • Blocked: Number of frames per second whose submission was blocked waiting on GPU work for the previous frame to finish executing. Generally if you are seeing an equal number of frames submitted as blocked on GPU, your application is GPU bound.

Google VR SDK (GVR) Metrics

The Google VR SDK utilizes an asynchronous reprojection pipeline for display stability and user comfort. In brief, a dedicated high priority thread asynchronously picks up frames submitted from the application and applies distortion and reprojection as necessary. In the absence of any new frames from the application, the reprojection pipeline will utilize an older frame, reprojecting the older frame with updated information about head rotation from system sensors.

  • New App Frames (NAF): The number of times per second that the display reprojection pipeline picked up a new frame from the application. An ideal ‘New App Frame' rate is the native display frame rate - e.g. 60hz on a Daydream phone device, meaning that every physical refresh of the screen has updated application data.
  • Reused App Frames (RAF): The number of times per second that the display reprojection pipeline did not have a new frame from the application, and had to reproject a previously provided frame A non-zero value here represents increased input to photon latency, and a constantly changing re-used app frame value can lead to animation and motion discontinuities.
  • VSync Misses (VMISS): This value represents an inability of the display pipeline to reproject any frames in time for the hardware's vertical synchronization deadline. This is usually out of the developer's specific control but can be caused by systems in a generally overburdened state. For some architectures, it can be an indication of excessive work in the vertex shaders, excessive I/O or using large vertex buffers.

Application System Metrics

  • Process Memory: The memory currently being used by your process.

  • Temp to Throttling: The approximate temperature (in degrees in Celsius) before the device will enter a thermal shutdown state to protect against overheating. The temperature of the device is driven from multiple factors, .e.g. CPU, GPU, network, etc. Applications usually make use of ‘Sustained Performance Mode' to ensure a cap on these resources in an attempt to prevent thermal shutdown.