All Oculus Quest developers MUST PASS the concept review prior to gaining publishing access to the Quest Store and additional resources. Submit a concept document for review as early in your Quest application development cycle as possible. For additional information and context, please see Submitting Your App to the Oculus Quest Store.
This section covers the general principles that you should follow in order to effectively optimize your VR applications.
Optimizing VR applications can be challenging. It is easy to go down the wrong path, and end up optimizing code that doesn’t improve the overall performance of your application. It is important to identify and focus on where the bottlenecks really are, and optimize those sections first.
VR performance issues are generally of two types: CPU issues and GPU issues. The CPU tends to be involved with simulation logic, state management, and generating the scene to be rendered. The GPU tends to be involved with sampling textures and shading for the meshes in your scenes. It is important to determine whether a performance problem is due to CPU load or GPU load, and to optimize your code accordingly.
In general, you follow Amdahl’s Law for parallel programming: Optimize the sections that are utilizing the system the most. Focus on the big expensive code paths. This document will provide guidance on how to identify these. Don’t focus on issues which, even if you reduce the costs to near zero, you would only achieve minor reductions to the overall performance costs.
It is not uncommon for one area within your application to utilize a large percentage of the system’s processing time, while the remaining areas consume much smaller percentages. You should aim to optimize the larger problem area first.
As you optimize your application, strive to change one thing at a time. Keep in mind that there can be non-trivial interactions between the changes you make, especially with complex VR applications. If you are tracking down a performance regression in your application, try to locate in your version control software history the single change that caused the performance problem you are experiencing. Then, look for the root cause of the performance issue there. Don’t assume that multiple changes work together to cause a single performance problem.
For many people, it is easy to get a bit pedantic or obsessive about things that don’t matter in terms of bottom line performance. It is usually best to simply consider timing issues: Is the application hitting frame rate? If so, you may not need to further optimize your application, even if your code is not designed as well as would be ideal. Focus on what really counts, in terms of performance issues that impact the user experience.
With VR, every frame must be typically drawn twice, once for each eye. That typically means that every draw call is issued twice, every mesh is drawn twice, and every texture is bound twice. There is also a small amount of overhead that is required to apply distortion and TimeWarp to the final output frame (approximately 2 ms per frame). Since the Rift refreshes frames at 90 Hz, it can be challenging to hit frame rate consistently.
The following general guidelines can help you to meet frame rate:
Performance problems are most commonly caused by the following issues (in order of severity):
|Performance Problem||Resource Costs|
|Scenes that require dependent renders, including shadows and reflections||CPU, GPU|
|Binding of Vertex Buffer Objects (VBOs) in order to issue draw calls||CPU, Graphics Driver|
|Transparency, multi-pass shaders, per-pixel lighting, and other effects that fill large numbers of pixels||GPU|
|Large texture loads, blits, and other forms of memcpy||GPU, Memory Controller|
|Skinned animation||CPU, GPU|
|Unity garbage collection overhead||CPU|