Search Issue Tracker
Won't Fix
Won't Fix in 1.11.X, 3.2.X
Votes
0
Found in [Package]
1.11.2
3.2.1
Issue ID
OXPB-83
Regression
No
[Performance][Oculus] OculusRuntime.WaitToBeginFrame takes approximately 10ms when running on a new project with Oculus Integration
Steps to reproduce:
1. Create a new unity project
2. Switch target platform to Android
3. Change Color Space to Linnear
4. Install OculusXR plugin: 1.11.2 or 3.2.2
5. Use OpenGLES3 as the Graphics API
6. Install Oculus Integration V 46.0 (Meta Quest Pro support)
7. In XR Plugin Management select Oculus as the plug-in provider
8. Select any scenes included in the Oculus integration package as the start Scene
9. Build to Oculus Quest device using Development Build and selecting Autoconnect Profiler
10. See the consumption of OculusRuntime.WaitToBeginFrame
Expected results: OculusRuntime.WaitToBeginFrame does not take 10ms when running on a new project with Oculus Integration
Actual results: OculusRuntime.WaitToBeginFrame takes approximately 10ms when running on a new project with Oculus Integration
Reproducibble on OculusXR 1.1.2 - 3.2.2 (2020.3.41f1, 2021.3.12f1, 2022.1.23f1 2022.2.0f1)
Could not test on 2023.1.0a20 and below due to Gradle and Java errors
Reproducible with these devices:
N/A, Oculus (Quest 2), Android 10, CPU: Snapdragon XR2, GPU: Adreno (TM) 650
Notes:
-Does not reproduce using OpenXR
-When using Vulkan the Profiler shows EarlyUpdate.XRUpdate taking ~10ms
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Crash on ModelImporter::ImportSkinnedMesh when disabling "Strip Bones" on a specific FBX model
- WebGL Development builds ignore the "Compression Format" setting when using "Gzip" compression
- [tvOS] Project crashes on startup on Apple TV simulator (both X86_64 and ARM64 architectures)
- Context menus open on a different monitor when there are three monitors used
- Crash on Umbra::QueryExt::queryStaticShadowCasters when opening a specific project
Resolution Note:
In the Oculus runtime, it is completely normal for WaitToBeginFrame to take 10 ms, based on the application's actual performance.
In an empty project, you can expect vsync to be about 10 ms. That coincides with the numbers you're seeing with WaitToBeginFrame.
When you see spikes in WaitToBeginFrame, that means your app is doing something that causes a miss in the VSYNC deadline. In essence, the last frame gets reprojected and the Oculus runtime decides that you need to wait before starting the next frame. Otherwise you're going to start introducing latency in your app. That's all decided on by the Oculus runtime.
As to what causes missing that vsync deadline, that could be anything, from your app taking extra time on the CPU or GPU. One thing you can do is check the frame (or two) before the spike to see if there's anything suspect there.
Resolution Note (1.11.X):
In the Oculus runtime, it is completely normal for WaitToBeginFrame to take 10 ms, based on the application's actual performance.
In an empty project, you can expect vsync to be about 10 ms. That coincides with the numbers you're seeing with WaitToBeginFrame.
When you see spikes in WaitToBeginFrame, that means your app is doing something that causes a miss in the VSYNC deadline. In essence, the last frame gets reprojected and the Oculus runtime decides that you need to wait before starting the next frame. Otherwise you're going to start introducing latency in your app. That's all decided on by the Oculus runtime.
As to what causes missing that vsync deadline, that could be anything, from your app taking extra time on the CPU or GPU. One thing you can do is check the frame (or two) before the spike to see if there's anything suspect there.
Resolution Note (3.2.X):
In the Oculus runtime, it is completely normal for WaitToBeginFrame to take 10 ms, based on the application's actual performance.
In an empty project, you can expect vsync to be about 10 ms. That coincides with the numbers you're seeing with WaitToBeginFrame.
When you see spikes in WaitToBeginFrame, that means your app is doing something that causes a miss in the VSYNC deadline. In essence, the last frame gets reprojected and the Oculus runtime decides that you need to wait before starting the next frame. Otherwise you're going to start introducing latency in your app. That's all decided on by the Oculus runtime.
As to what causes missing that vsync deadline, that could be anything, from your app taking extra time on the CPU or GPU. One thing you can do is check the frame (or two) before the spike to see if there's anything suspect there.