Understanding performance and workfow..
Hello! i'm a bit confused about differences between PCVR and Deployed APK workflow.. What i understand is that PCVR makes Quest to be used as a second screen (in this case VR screen), so, all the gpu process, computation and logics are made in the computer, Quest is only rendering results... In this case, Quest requires the computer running the application in order to work... By the other side, Deployed APK allows application to run directly in the Quest and there is no computer dependency, all computation are made directly in the Quest... Until now, this is all i know, my question points to performance, i'm using Unreal Engine 5, my game works smooth on standalone mode, very smooth...... but when i switch to VR Preview, my game lags a lot, i was wondering why is this happening if GPU computation is being made by the computer.... I tried using both Air Link and Cable, but same result... Any help will be very appreciated..
VR.WaitForGPU killing performance in Unity3D. Very difficult to profile other issues. Video Example
Here is a video showing what the issue is https://youtu.be/n5ngEzZSKH0 I'm trying to release an update to Vanguard V but perforance has become a real issue. The game runs at 150fps on my laptop but the framerate tanks when I touch the Oculus headset. I get these nasty yellow spikes and the FPS tanks to the 50s, even on my desktop (980 GTX TI). I then created a new scene with nothing but a camera and the default Directional Light. The framerate goes into the 800s until I touch the headset. It then tanks again to 90-100fps. This is an empty scene. Now, if this is by "design" it has made it very difficult to isolate any real issues in the profiler. Any help would be great. Unity 5.5.1f1 and observed in Unity 5.5.2 as well Windows 10 x64
Low FPS even with low draw calls and low number of triangles :(
Hi, I am confused about something and It would be great if someone can help me. I have around 500 trees in my scene but I optimized them so the total number of draw calls is around 200 and total number of tri around 300k. There are no scripts running and the game is literally doing nothing, there is no reflection probes, I have turned off shadows etc. When I build the game, I still do not get 90 fps whenever I look towards the trees. Why this is happening ? I checked the profiler and XR.wait for GPU is taking around 20ms. Can Someone please explain me why large number of objects is decreasing FPS even when draw calls and number of triangles is low ? Am I missing something ? is there any solution to this prob or I will have to decrease the number of trees ? Thanks
Recent performance issues
Towards the end of December I was finishing up the intro of my VR game. The intro is just 5 minute ride introducing the story and environment they are about to experience in the actual game. It is built inside of UE4 (4.23). During the intro normal controls are turned off so they can't interact with the ride aside from looking around with their head. This intro was going to be my teaser reveal for my game as well. I polished it up rather well I like to think. Before December wrapped up I backed the project up across my various devices as it was a big milestone for my project. Everything ran well. No frame hitches, no audio skipping, no tracking issues from performance. I took a couple weeks off at this point for health reasons. It was supposed to be a good stopping location. Upon returning (a couple days ago) I have noticed that with the recent Oculus updates (forced) that performance changed in my intro. Now I get frame hitches, audio skipping, and tracking issues - regularly. What happened? I wrapped up that intro. It was done. No additional work went into it. Like a nervous school kid I verified it's fluidity 100 times. It was running perfectly, and now due to some oculus update it does not. How am I supposed to trouble shoot this as a developer? It's not like I know what you did under the hood. To trouble shoot this on my side I've kept windows updated, same with Nvidia Drivers. I migrated my project to UE4 4.24.2 hoping that your update was utilizing something in UE4 current. Still I get regularly hitches. Not just in my project mind you. I get them when I put the headset on. The moment I enter VR I'm getting stuttering that never occurred before. If I open up UE4 in the background - it's nearly unbearable. At this point I have no idea what to do. I know in these situations it's common to blame the other half - UE4. If there was a way to roll back my oculus version I'm certain my backed up UE4 4.23 version of my project would run flawlessly. What are other developers doing about this? Are we expected to modify our projects to accommodate the Oculus updates?970 VR Drawcalls, Vertices, Triangles
Hi, I know that for Gear VR, there's a suggested limit of 100 drawcalls, 50-100K vertices guideline. What's the number for Rift like VR, I have a scene of about 500 drawcalls, 500K vertices, which I tested using Unity editor with CV1, all seems good. Still, is there any official guideline numbers available? Thanks, the reason I want to ask is I have a bunch of near 1M triangles models that I want to use, but kind of nervous about put them in the same screen space.Bubbles in the GPU queue at the start because of ovr_submitFrame
https://developer3.oculus.com/documentation/pcsdk/latest/concepts/dg-hud/ says: Compositor Frame-rate The rate of the final composition; this is independent of the client application rendering rate. Because the compositor is always locked to V-Sync, this value will never exceed the native HMD refresh rate. But, if the compositor fails to finish new frames on time, it can drop below the native refresh rate. The native engine I'm working on calls `ovr_submitFrame` from the render thread, and is currently designed such that the next frames work (sim + render prep + submit) starts only after `present` is called on the render thread. GPUView tells me that `libOVR*.dll` waits on a sync object, resulting in the CPU doing literally nothing during a 3-4 ms period. This happens every frame (App CPU frame time is generally 5-7 ms, App GPU frame time is 10-13 ms), and results in bubbles in the GPU Queue at the start of the next frame. When the render thread does resume execution, the stack in GPUView shows a bunch of kernel/os stuff for ~1.5 ms before `libOVR*.dll` shows up in the stack and my engine only then gets back control flow. I can't quite explain what that's about. In the pic below, notice: (a) the CPU render thread being idle because of a sync object in libOVR*.dll (b) small bubbles in the GPU queue at the start for the next frame as a result My questions are: (1) Does `ovr_submitFrame` return only after the HMD's vblank? If so, why doesn't the SDK let the app query time to vblank and throttle itself accordingly? (2) When the sync object wait returns, it still takes ~1.5 ms (from GPUView) before I see a call stack with the engine's symbols. Why this extra time? (not shown in pic) (3) More importantly, my engine should not be throttled by the render thread's inability to present and should kick off sim work for the next frame (at least) a few ms before the render thread gets back control flow. What is the recommended way (API to use) to understand when to start work for the next frame?Profiling without a headset present
Hi, we have some nice min-spec machines to do profiling on, but we've not been able to have our overnight tests running because we only have two headsets in the studio. We really wanted to enable to Debug HMD mode that used to work back in 0.8.0.0, but when we enable it now, nothing happens, and now we can't even find it in 1.3 API. Help! We can't get hold of enough physical headsets to do accurate testing, obviously, and now can't test against a virtual headset that goes through the same composition stages as the real thing. We have a large game with large levels and need to performance profile these levels on multiple machines.
