Up and Coming

[GearVR] Timewarp debug not visible with Unity 5 native VR

10 replies
3004 views

I'm trying to get the timewarp debug and general debug stats (OVRDebugGraph.cs and OVRDebugInfo.cs respectively) to show on a Gear build, but so far cannot get either of them to display anything, either in my own app or by running one of the sample scenes.

Using the Box_Room.scene as a simple test case, this looks like it's already set up to use the Gamepad Start button to toggle the timewarp graph, and it does show the TOGGLE GRAPH output in logcat, and I can see it incrementing the debugMode with the debugger, but still no timewarp graph on screen. Similar results with the OVRDebugInfo, debugging it everything appears to be working, just no output.

Am I missing something here? The documentation seems to be rather bare on these, as far as I can tell the only requirement is that the device is in developer mode, which it is. Also there's no documentation on where this scripts should go in the hierarchy, or whether they need any other components present, or what other components should be on the same entity or not.

Running Unity 5.1.3p1, with Oculus Utilities 0.1.0 beta, on a Note 4 with developer mode turned on (via the Gear VR Service option). Note 4 is running KitKat.

Thanks.

This topic has been closed for replies.

J

JonnyClangersAuthor

Up and Coming

Tried this on an S6 as well (running Lollipop) in developer mode and the same result - everything appears to function when debugging through, but nothing visible.

I'm starting to think this functionality is just broken, since much googling hasn't actually turned up any results of people actually managing to get it to work.

V

vrdaveb

Inspiring

This looks like a regression in our 0.6.0.1 mobile SDK. You can use the debug graph there, but it can no longer be enabled after VR has been initialized. Instead, set the timewarp graph values via local prefs (would need to pause and then resume the app for the change to take place). Unfortunately, developer mode can cause clock locks to fail so this wouldn’t be the best way to test performance. We're looking into a proper fix for a future release.

adb shell "echo dev_timeWarpDebugGraphMode 1 dev_timeWarpDebugGraphValue 0 > /sdcard/.oculusprefs"

where possible values are:
"dev_timeWarpDebugGraphMode" // "0" = off, "1" = running, "2" = frozen
"dev_timeWarpDebugGraphValue" // "0" = draw, "1" = latency

J

JonnyClangersAuthor

Up and Coming

Thanks for the reply.

So if this is only visible in developer mode, and clock rates are unreliable in developer mode this suggest that I've got no 100% accurate way of measuring performance or not? That seems like a huge issue to me.

- I can't measure performance with the Unity profiler, as that requires a development build and so is far, far slower than a proper release build.

- I can't measure performance with my own code, as the values unity provides (Time.unscaledDeltaTime) don't seem to be 100% accurate, and can't actually show me the complex interaction between me finishing a frame and whether timewarp was completed in time.

- Android / OpenGL performance tools suffer from the same issue, in that they can't tell me exactly whether timewarp is hitting it's deadlines or not.

Is there an estimated date when this will be fixed?

Edit: Additionally, I've been trying to get timewarp data out via OVRManager.display.latency, but these all report zero, regardless of developer mode, build type, hardware or whether I set OVRPlugin.collectPerf to true. It seems that OVRPlugin.GetString(Key.Latency) just returns an empty string.

Is this also broken? When will this be fixed?

Thanks.

V

vrdaveb

Inspiring

Does it help to pause and then unpause the app after enabling the debug graph? That will re-initialize the VR thread and your settings should take at that point. Unfortunately, we don't have an ETA for the fix yet. Are you able to use systrace or another profiling tool? OVRManager.display.latency isn't implemented for Android yet.

J

JonnyClangersAuthor

Up and Coming

As I already said above, other system-level profiling tools won't work, because they can't tell me exactly what timewarp actually did, and so whether the game has dropped a frame or not.

Pausing and resuming the app makes no difference.

I don't understand how OVRManager.display.latency isn't implemented yet, since:
1. It's in the public api. If it's not working yet don't expose it.
2. Clearly this information exists, since it's being used to draw the timewarp graph. I just need access to it.

For a platform where performance is *critical*, this is really hampering our ability to make content that runs in frame. :cry:

Do you have an ETA on when we'll have an ETA for these being fixed?

V

vrdaveb

Inspiring

There isn't an ETA yet, but we are working on it. The information in OVRmanager.display.latency isn't quite the same as the data displayed by the render timings graph. The latency string is driven by the Rift's latency tester, which isn't available on Gear VR, but we didn't want to force you to use #if UNITY_ANDROID in your code just to use our API. For now, you can use 5.1.1f1 (the official 5.1.1 release) to restore OVRDebugGraph's functionality. 5.1.1f1 has some issues with the initial head pose, so I would suggest switching back to 5.1.2f1 before making any release builds of your game.

V

vrdaveb

Inspiring

If you are blocked on OVRDebugGraph and can't wait for us to fix it, please switch back to Unity 4.

J

JonnyClangersAuthor

Up and Coming

Unfortunately we switched from Unity 4 to Unity 5 to avoid several nasty Oculus/Unity bugs, and we've found that 5.1.1x releases have significant performance issues compared to 5.1.2x versions. It seems like there's no good Unity+Oculus version pair that doesn't have major issues for us right now. :cry:

Could you go into more detail about the issues around developer mode and clock locks please? We've got an automated performance tester, but without being able to run it in developer mode we lose the ability to have it fully automated.

V

vrdaveb

Inspiring

"JonnyClangers" wrote:
Unfortunately we switched from Unity 4 to Unity 5 to avoid several nasty Oculus/Unity bugs

Which bugs were those?

"JonnyClangers" wrote:
we've found that 5.1.1x releases have significant performance issues compared to 5.1.2x versions.

I'm not aware of performance issues that were fixed between 5.1.1f1 and 5.1.2f1. Note that 5.1.2p1-5.1.3p1 are broken.

"JonnyClangers" wrote:
Could you go into more detail about the issues around developer mode and clock locks please?

On Gear VR we lock the frequencies of 2 cores to guarantee consistent scheduling of asynchronous TimeWarp. Without the clock locks, screen refreshes and head tracking can be applied at inconsistent rates, resulting in hitching or vibration in the image. If you enable developer mode, our attempts to lock the cores can fail, causing inconsistent latency and making the game less comfortable for users.

J

JonnyClangersAuthor

Up and Coming

"vrdaveb" wrote:

Which bugs were those?

Objects/lights being incorrectly culled in the left eye, and crashes when both multithreaded rendering and dynamic batching were enabled. Both of these were marked "fixed" in release notes but were only made less frequent. I submitted tiny repro projects for both of these but never heard anything back.

I'm not aware of performance issues that were fixed between 5.1.1f1 and 5.1.2f1. Note that 5.1.2p1-5.1.3p1 are broken.

Well, we're seeing them. I haven't had time to track them down to a particular system yet though.

If you enable developer mode, our attempts to lock the cores can fail, causing inconsistent latency and making the game less comfortable for users.

Is that something that can be fixed, or is this an Android/OS issue?

Given all of the above, how would you recommend building an automated performance tester for a Gear VR app?

Get Help

Sign up

Login with SSO

Login to the community

Login with SSO