Overview of Major Changes
Mobile SDK 1.0.3 adds multi-view rendering support. Multi-view rendering allows drawing to both eye views simultaneously, significantly reducing driver API overhead. It includes GPU optimizations for geometry processing.
Preliminary testing has shown that multi-view can provide:
Obviously the freed up CPU time could be used to issue more draw calls. However, instead of issuing more draw calls, we recommend that applications maintain the freed up CPU time for use by the driver threads to reduce/eliminate screen tears.
While current driver implementations of multi-view primarily reduce the CPU usage, the GPU usage is not always unaffected. On the Exynos based devices, multi-view not only reduces the CPU load, but slightly reduces the GPU load by only computing the view-independent vertex attributes once for both eyes, instead of separately for each eye.
Even though there are significant savings in CPU time, these savings do not directly translate into a similar reduction in power draw. The power drawn by the CPU is only a fraction of the total power drawn by the device (which includes the GPU, memory bandwidth, display etc.).
Although all applications will have their unique set of challenges to consider, multi-view should allow most applications to lower the CPU clock frequency (CPU level) which will in turn improve power usage and the thermal envelope. However, this does not help on the Exynos based devices where CPU level 1, 2 and 3 all use the same clock frequency.
Multi-view will not be available on all Gear VR devices until driver and system updates become available.
The current set of supported devices as of the date of this release is:
For detailed instructions on how to structure a native application for multi-view rendering, see Migrating to Mobile 1.0.3.
We are working with Unity and Epic to support multi-view in Unity and Unreal Engine.
VrAppInterface has been refactored to simplify the interface, support multi-view rendering, and enforce per-frame determinism. We highly recommend updating your VrAppInterface based application to support multi-view. However, even if you are not planning on supporting multi-view, it would be good to adopt the VrAppInterface changes because they also pave the way for Vulkan support in the future.
VrAppFramework-based applications now explicitly pass EGL objects to VrApi. Previously, the various VrApi functions had to be called from a thread with a specific EGLContext current. The current EGLContext and EGLSurface were basically invisible parameters to the VrApi functions. By explicitly passing the necessary EGL objects to the API, there are no threading restrictions.
Volume notifier is now rendered automatically in VrApi as a TimeWarp layer – the application is no longer responsible for generating and displaying this notification. Be sure not to render your own volume interface!
Various build steps have been moved from the Python build scripts into Gradle.
