cancel
Showing results for 
Search instead for 
Did you mean: 

Gear VR Unity bug rendering time oscillates despite no change in image / scene

Brainlogin
Protege
I'm experiencing rendering and culling times increasing by about 4-5 ms once or more every few seconds for irregular periods (0.5-1s). Nothing changes / moving in the image, not even moving the view (phone sitting on table outside of Gear VR). These rendering oscillations result in dropping to 30FPS from 60FPS time by time. Issue persists even after removing all my scripts / characters / physics, only leaving about 100 static tiles (batch called at once) and some more simple immobile objects and UI elements, 25 draw calls (20K tris) altogether counting both eyes. Most of the time launching the same build results in a lot of these FPS drops, sometimes none at all for minutes. Building with VR supported turned OFF (so as a non-VR android app) shows NO such rendering / performance oscillations, nor when running in Unity Editor. Only when compiled for Gear VR.

Using Unity 5.5.3f and Galaxy S7 Edge (Android 7.0), OVR 1.0.1 plugin. No particles, No realtime lights, only one baked directional, no lightmap baked, no spotlights. Occlusion culling turned off (no need as we have only 25 draw calls in the entire scene, all packed in one place). Unity profiler and internal profiling from adb logcat shows the same so its not the profiler's fault.

How is it possible that rendering and culling times oscillate by 4+ ms while nothing changes in the scene, scripts Update() methods are all disabled, no animations, it's just a few simple static objects and UI elements. Looking away those 100 tiles does get rid of the oscillation but it still doesn't explain why a couple of tiles, 30 vertices each, called in one or two dynamic batches would result in such strange oscillations.

EDIT: another observation is that these slow rendering periods tend to increase in length and frequency with time and sometimes Unity profiler even ends up freezing after half a minute or so. This is despite no memory build up as you can see in the screenshot.

rsk9y6ip2owp.pngzelw0nb8n27z.pnghtcn434wp7ay.png08kzzuhxf5jh.jpg
4 REPLIES 4

Brainlogin
Protege
Thanks a lot @imperativity
Your hint indeed led me to an improvement although at a cost that I'm hoping I can avoid to pay with some workaround. I've managed to work my SetPass count down closer to a 1:1 proportion with the draw calls (21:27) and this indeed got rid of most of those huge bursts, although sporadic spikes at every few seconds still exist. I'm not sure if it's directly caused by reducing SetPasses or rather just eliminating alpha-blended particles because most of the set passes were caused by those. And this is where my concern starts:

Looks like even just a single particle system with Particles/Alpha Blended shader already adds GPU spikes on Gear VR, does that mean I'm not supposed to have a single alpha blended particle in my scene, ever? They're quite inevitable to use, my game heavily relies on them so I'm hoping there's some way to keep some of them. The other surprise came as it turned out a couple more SetPass were added just by some inactive particle systems in my scene which were not even playing yet (play on awake unchecked)! They were just placed on objects waiting for certain events that would trigger them to play. I have no idea why would they add SetPasses while not playing, any idea? Anyways, that would be the easier thing to avoid, by just instantiating them when they're needed. But I'm more worried about the prospective of not being able to use Alpha blended particles on Gear VR at all...

Maybe you're already aware of these limitations or something else that explains the above? 

Edit: After more tests I found no matter what shader I use for my particles, they'll always add extra SetPasses which in turn immediately result in huge performance spikes. It just doesn't feel right that mobile VR games would not allow to include a single particle, something must be wrong here.

x4he9px5ea4e.png

And this is what OVR Lint says in a screenshot. As for the warning about skybox, I've already read many times that I shouldn't use Oculus built-in skybox but I can't just have a clear solid color background in my game and I don't know what alternatives are better. I could use a simple box with a 2-sided shader and have it surround my scene but I don't get how that would be better than the built in skybox. Any other ways to display my sky / background textures without the built-in skybox that's better for the performance?

Brainlogin
Protege
A few more bugs since I've clicked accepted OVR Lint to fix those issues listed (which resulted in no performance improvement): Now I see a slow turning of the view towards the right even though the phone is steady sitting on the table in front of me. No idea what causes this. Never seen it before. And I'm still stuck as OVR Lint basically marked every one of my shaders in the scene as having more than 2 SetPasses (as you can see even Default Material) while they don't. But I've also experienced a huge increase of SetPasses since I've updated my OVR package and accepted the Lint changes, despite no materials changing. Now even after removing all particles and all alpha blended materials and having only a UI and opaque objects my SetPass is still 51 despite a draw call of only 31. Problem is still not solved ...
Question remaining:
1. How to reduce setpasses
2. How to find shaders that have 2 or less setpasses (according to OVR Lint none of my shaders meet this criteria, although I've tried everything from Standard Assets and more).
3. How to eliminate the above rendering issue (most likely related to too many SetPasses related to above 2 questions)?

jons190
Adventurer
Hey krisventure   Did you ever find any resolution to any of this?   I too am having some of these same issues on my VR mobile game and am wondering if you ever found out any further info.

Thanks!

oculus_gabor
Protege
I suspect the issue here is actually the version of Unity being used. 5.5.3f had a bug which exhibits the symptoms described. See https://issuetracker.unity3d.com/issues/android-arm-big-dot-little-cores-are-identified-incorrectly-on-s8 for details and the versions of Unity the fix was back ported to.