A

Anonymous

5.1.2p2 -> 5.2.1f1 - Large Performance Loss

58 replies
18583 views

Long post short (i.e. tl;dr;): Avoid 5.2.1 for now. Major performance loss. I'm sure nobody will read the rest of this since Oculus Connect is happening now, but if you want more details, read on!

Just a heads up for those who are tempted to try 5.2.1 that came out 2 days ago. I'm seeing a large performance drop, similar to what was seen when moving to 0.1.0 utils and away from legacy integration. That performance drop was fixed in 5.1.1p3 -> 5.1.2p2, but now something worse seems to have happened 5.1.2p2 -> 5.2.1f1.

I had previously posted these "benchmark" results in the "Oculus Utilities for Unity 0.1.0 Beta released" topic when I was seeing issues with 5.1.1p3 + 0.1.0 utils. This benchmark is a measure in ms of how much CPU time is left for your own scripts outside of rendering a fairly complex scene. I put this together so I could track how Unity + Oculus runtimes improved or degraded over time. It involves a script that acts as fake CPU load, that allows adjusting ms of CPU load until frame skips and judder kick in. This essentially calculates the performance overhead you have. Here were my previous results from the other post:

5.1.1p3 + 0.1.0 Utils: 6.0ms
5.1.1p3 + 0.5.0.1 Legacy Integration: 9.0ms
5.1.2p2 + 0.1.0 Utils: 7.9ms
5.1.2p2 + 0.5.0.1 Legacy Integration: 9.0ms

New data for 5.2.1:
5.2.1f1 + 0.1.0 Utils: 4.0ms

Not good. Can't do much with 4ms of CPU time. I'm rolling back to 5.1.2p2. Unfortunately this means the 0.7 features can't be used as that is what 5.2.1 offered up:

http://unity3d.com/unity/whats-new/unity-5.2.1

VR: Oculus: Upgraded to 0.7 dependencies.
VR: For Windows Oculus Development, the Oculus 0.7.0.0 runtime is required in order to run in VR mode. Future releases will also require this runtime going forward.

I did verify the performance monitor HUD is working now in 5.2.1f1, but unfortunately it just tells me the performance sucks. :)

I'm starting to cringe every time a new SDK version and/or Unity version comes out.

ccs

This topic has been closed for replies.

Show previous replies

S

SvenViking

Inspiring

Excellent indeed. Just confirming, but will the fix improve performance on Gear VR as well as PC? For me, Android performance is still lower in 5.1.3p2 than with Unity 5.0.2p2 and Oculus SDK 0.5.1, in some situations at least, so there must be some earlier regression. (TimeWarp seems to more effectively cover for skipped frames in 5.1.3, though.) I could probably create a benchmark scene if that helped.

Scorched Battalion - VR Jam edition available for Gear VR and DK2 (Win/Mac/Linux) Jungle Juice Sven Co-op

A

Anonymous

Tested 5.2.1p3 today. I wasn't expecting any improvement given Dave's statement of a few weeks. Similar results. Updated table (all run using 0.7 runtime):

5.1.2f1 (0.1.0 utils) 7.1ms
5.1.2p2 (0.1.0 utils) 9.2ms
5.1.2p3 (0.1.0 utils) 9.2ms
5.1.3f1 crash every time - can't benchmark
5.1.3p2 (0.1.0 utils) 9.4ms (BEST! my default version now)
5.1.3p3 (0.1.0 utils) 6.8ms (note this is 1st version of Unity to use 0.7 plugin)
5.2.0p1 (0.1.0 utils) 6.5ms
5.2.1p1 (0.1.0 utils) 6.7ms
5.2.1p2 (0.1.0 utils) 6.5ms
5.2.1p2 (0.1.2 utils) 7.1ms
5.2.1p3 (0.1.2 utils) 7.2ms

ccs

sh0v0r

Up and Coming

I just sat down today to update Lunar Flight to 0.7 and 5.2.1p3 using the recommend AMD drivers on Win 8.1. i7 4770k CPU

There is a noticeable difference in performance from the 0.6 with 5.1.2 release which would hold 75 FPS solid 99% of the time on my machine.

The average frame rate is now dropping to around 57 FPS, what's interesting is that it is a pretty consistent drop.

I did some quick reading up on the the WaitForGPU discussion. It is pretty much spending 13ms all the time waiting.

I'm guessing these issues are combination for changes across Unity, Oculus and AMD Drivers since the previous release which had much better performance.

One other issue that cropped up and is likely a Unity problem is that my projector based shadows are messed up as well.

O

Optimus6128

New Participant

I had some very bad performance issues since with 5.2.0f3 using the GearVR with Galaxy Note 4. Besides the dropped framerate, there were some serious stalls. I later found out it happens when I bake the Occlusion Culling, no matter the size or holes. Disabling it would not longer make these stalls, but of course the performance would be reduced without culling tree.

Now with 5.2.1f1 this bug is fixed, so I can properly test my scenes with occlusion culling on. But at moments where I wouldn't drop under 30fps (in old 5.1.2f1) I now get 25fps or even 20fps at worse cases. I haven't tried the 5.2.1p3 version yet though (we try to keep the some versions with the team, so everyone is on 5.2.1f1, maybe in an official update I will switch).

M

motorsep

Inspiring

5.2.1p4 is out already.

V

vrdaveb

Inspiring

5.2.0f3, 5.2.1f1, and 5.2.1p4 are all broken on Gear VR. Please don't use them. The latest recommended version is 5.2.1p3.

C

Channex

New Participant

Wow! I just tried the benchmark on runtime 0.8 and nvidia 358.50.

Unity 5.2.2f1: 4.1ms
Unity 5.1.2p2: 9.6 ms

No wonder our demo ran like crap all of the sudden!

I really hope this has a very strong focus, because there are some pretty useful fixes in 5.2.2, so going back to 5.1.2p2 is kinda bad..

A

Anonymous

Reran today with newer runtime, drivers, and Unity version for good measure and to make sure new drivers and runtime didn't break anything further (they don't).

i7-4710@2.5Ghz
980M (no optimus - performs somewhere between 960 and 970)
Windows 8.1 64-bit

Previous results copied from previous post, included here for comparison:

Nvidia driver 355.98 & Runtime 0.7
5.1.2f1 (0.1.0 utils) 7.1ms
5.1.2p2 (0.1.0 utils) 9.2ms
5.1.2p3 (0.1.0 utils) 9.2ms
5.1.3f1 crash every time - can't benchmark
5.1.3p2 (0.1.0 utils) 9.4ms (BEST! my default version now)
5.1.3p3 (0.1.0 utils) 6.8ms (note this is 1st version of Unity to use 0.7 plugin)
5.2.0p1 (0.1.0 utils) 6.5ms
5.2.1p1 (0.1.0 utils) 6.7ms
5.2.1p2 (0.1.0 utils) 6.5ms
5.2.1p2 (0.1.2 utils) 7.1ms
5.2.1p3 (0.1.2 utils) 7.2ms

New results:

Nvidia driver 358.78 & Runtime 0.7
5.1.3p2 (0.1.0 utils) 9.4ms (same as before)

Nvidia driver 358.78 & Runtime 0.8
5.1.3p2 (0.1.0 utils) 9.6ms (new best!)
5.2.2p1 (0.1.0 utils) 7.2ms
5.2.2p1 (0.1.2 utils) 7.1ms

Nothing really surprising, but nice to see new driver and runtime 0.8 doesn't cause any additional issues. I actually obtained the highest score yet with 5.1.3p2, 0.1.0 utils, 358.78 nvidia driver, and 0.8 runtime.

I'm hoping to find some time to do deeper profiling in parallel with Dave's effort.

ccs

V

vhamm

Participant

Hi,

I have been investigating this, and I was wondering if you could try something out for me. In your script, can you set the queueAheadFraction to 0? A simple OVRPlugin.queueAheadFraction = 0; in DelayTest::Start should do.
I've been able to get some perf back doing this, and I would be interested to see if that is the same thing for you.

-Vincent

A

Anonymous

Hi Vincent-

Putting that into DelayTest Start wouldn't do the trick due to these lines in OVRManager.cs change the value every frame based on queueAhead boolean set on the component:

	
private void Update()
	{
		tracker.isEnabled = usePositionTracking;

		// Dispatch any events.
		isHmdPresent = OVRPlugin.hmdPresent;

		if (isHmdPresent)
		{
			OVRPlugin.queueAheadFraction = (queueAhead) ? 0.25f : 0f;
		}

Therefore I just ran the test with queueAhead set to false on OVRManager which accomplishes the same thing. I actually found performance is way worse with queueAhead off:

5.2.2p1 (0.1.2 utils - queue ahead .25) 7.1ms
5.2.2p1 (0.1.2 utils - queue ahead 0) 4.1ms

Maybe I will try some higher values and see what happens.

ccs

Show more replies

Get Help

Sign up

Login with SSO

Login to the community

Login with SSO