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

Package: Oculus XR Plugin

-

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

  1. 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.

  2. 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.

  3. 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.

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.