Hi, I am getting some strange lag spikes from time to time in editor and in builds. Was curious if someone could help out. I attached some screenshots of the profiler window (normal and deep profiling).
Looks like it has something with the new Input System maybe? Have the same problem too, but not with spikes, just a constant big CPU usage (around 92% of total usage)
Here’s a link to the code where this profiles samples comes from: InputSystem/Packages/com.unity.inputsystem/InputSystem/Plugins/Users/InputUser.cs at 3e5024ed660fda2f0f4c6b5b068ed6880bea04d7 · Unity-Technologies/InputSystem · GitHub
Also made some quick test on my Oculus Quest 2. Using the new input system, I got around 58 fps, disabling the new input system and removing the PlayerInput script from my player object, I got 90 fps. So something is definitely wrong here.
Tried again with some optimizations, and got it to run at 90 fps without any spikes or FPS drops. Posted an example repo here with different examples of my implementation, all running very smoothly.
Getting the same issue. CheckForUnpairedDeviceActivity takes up most of my CPU budget on an Oculus Quest 2 + Oculus Link project.
Hi, I’m wondering what you did to get it to work. I thought that (due to the deep profiling) that control schemes was the issue, but your branch with PlayerInput does use control schemes, and it doesn’t suffer from this issue? I’m curious what you changed exactly 
@IgnisIncendio Mostly went trough the settings suggested by the Menu > Oculus > Tools > OVR Performence Lint Tool. So not related to the Input System.
But yeah, I only have on schema (a custom that I named Quest). And under supported devices, that list is empty. And the Player Input script default scheme is set to my own created schema “Quest”. Auto-switch is on, but doesn’t do anything due to I only has one scheme.
But just for debugging purpose, make sure it’s not the debugger it self that is causing the spikes, I would suggest doing one build, and using the OVR Metrics Tool on your Quest, look at the framerate and CPU level. Then disable the Player Input script (so there is not input’s at all) and try that build too and see if there is any differences.
1 Like
I had a similar problem. My game was sluggish the second I was moving a joystick or pressing a button with massive InputCheckForUnpairedDeviceActivity spikes in the profiler but was smooth the rest of the time. The crazy thing was I didn’t always had that problem while not modifying the input code.
I finally found out that, because I was using DS4 to use my PS4 controller recognized as an XBOX one, I had multiple gamepads detected in the Input Debug window (search Window > Analysis > Input Debugger) and I think this creates conflicts resulting to the spikes in the profiler and the game slowing down.
So I disconnected the gamepad, deleted the controllers detected by the Unity editor in the Devices section of the Input Debug window and reconnected the gamepad again, no more problems.
Hope this helps !
We took a couple steps to address slowdowns caused by listenForUnpairedDeviceActivity. One is still incoming for a patch after 1.1 final.
In one of the 1.1 previews, we added a much more performant path (InputControlExtensions.EnumerateChangedControls) for scanning changed controls in an event. This massively reduces the amount of work done per event. However, if there’s a great many events to process, it’s still too slow. Especially troublesome is stuff like high-frequency mouse and touch (something that has been causing problems in a number of areas).
To that end, we’ve introduced a new mechanism that cuts down on the amount of events being processed by merging events that contain no relevant signal. This is currently implemented for mouse and touch. Doing this also for gamepads is slated for a patch release after 1.1.
1 Like
Great news. But this would also be very beneficial for XR headsets. Headset and controller tracking also has a high frequency tracking.
The gamepad path will hopefully result in a generic merging mechanism that can be toggled on for any device. Mouse and touch are somewhat special snowflakes because of their delta controls but any device that doesn’t need custom logic to merge events should be able to just employ the same generic codepath.
1 Like