cancel
Showing results for 
Search instead for 
Did you mean: 

0.7 BUG: Oculus Service consumes CPU on multiple uses

CrazyNorman
Protege
I already have a thread vaguely describing the issue, but at the point of writing it, I wasn't sure if I had encountered a bug or not. I've further isolated the issue, and it's definitely a bug with the 0.7 Oculus Runtime.

Reproduction Steps:
1. Boot up your computer, from a fresh power-off state (not sleep or hibernate)
2. Open the Oculus Configuration Utility
3. Press "Show Demo Scene" to run the Desk Demo.
4. Note CPU usage. The desk demo itself will be using some, but other than that CPU utilization should be low:

5. Press escape to close the Desk Demo while leaving the Oculus Configuration Utility open.
6. Note CPU usage. It should be extremely low (nothing's really running)

7. Repeat steps 3-6 as many times as you want. Results are consistent.
8. Press "Close" to close the configuration utility. Your camera light should turn off, indicating that the DK2 is no longer in use.
9. Re-open the Oculus Configuration Utility
10. Press "Show Demo Scene" to run the Desk Demo.
11. Note CPU usage. While the configuration utility is using a similar amount of CPU, there is a new contender for processing power. "System" is now maxing out one core of processing power. For my 4-core 3570k that's 25%.

12. Press escape to close the Desk Demo while leaving the Oculus Configuration Utility open.
13. Note CPU usage. "System" continues to consume as much processing power as it can on one thread, while the Oculus Configuration Utility itself stops consuming any CPU.

14. Repeating steps 10-13 as many times as you'd like. Results are consistent.
15. Press "Close", Oculus Configuration Utility closes.
16. Note that the "System" process is no longer using any CPU. This heavily implies that it's something to do with the DK2 runtime.
17. Run any Oculus app you want, System will jump back up to >= 25%
18. Sleeping the computer, restarting the Oculus Service, turning your Rift on/off, etc, will make no difference. The only thing that will work is a full reboot.


This isn't specific to the desk demo. After a fresh reboot, the first VR application run against 0.7 will function normally (showing that it isn't a necessary behavior of the new run-time, but rather a regression). After closing it and running a second Oculus application (or the same one a second time) will result in the System process maxing out a CPU core full-blast. None of this behavior occurred for me on 0.6

My specs are as follows:
  • Oculus Runtime 0.7.0.0

  • NVIDIA 355.84 Driver (355.83 is the same)

  • Windows 8.1 64-bit

  • Intel i5 3570k @ 3.8ghz. Same issue whether underclocked or overclocked

  • NVIDIA 780 Ti

  • 16GB RAM


Please let me know what I can do to help the development team reproduce and resolve this issue. Quite a few of my application's users have encountered this bug also.
67 REPLIES 67

gaelhonorez
Honored Guest
"cybereality" wrote:
Yes, this is a serious issue. However, the engineering team has seemed unable to reproduce (which means it can't be fixed). And it's not happening to everyone, or we would see a lot more reports. So there is some specific set of conditions which cause the issue, and we don't yet know what those are. I'll keep looking out for more information, though.


Actually, you have a lot of report about it on several threads and reddit. Most people don't check their CPU usage and says that "0.7.0 stutter while 0.6.0 doesn't" instead of "a service takes 100% of a core after the first usage".

And I don't think a lot of people (except dev and people on win10) updated to 0.7.0 due to the lack of support on the software side of things (or went back on 0.6.0 after seeing these bad performances).

cybereality
Grand Champion
I'll plug in my DK2 and see if I can repro myself. I was (at one point) able to see it, but that was a while ago and I've been unable to repro since then. However, I do have a newer (unreleased) runtime, so I can try to confirm if the issue has been fixed already.
AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV

Alric
Explorer
I get this issue too. I think more people than you think have this issue, the faster the PC the less you notice but it's still there. Easy to reproduce too.

Scawen
Heroic Explorer
User kokonut says he installed the new drivers 358.70 and it seems to have fixed it for him.
Post: viewtopic.php?f=34&t=25914&p=301460#p301460

I have not tried yet as my Rift is not plugged in. Would be interested to hear if it solves the CPU usage issue.
358.70: https://developer.nvidia.com/gameworks- ... er-support
Live for Speed - www.lfs.net

Scawen
Heroic Explorer
Now I've tried the 358.70 drivers.

I still get the stutter and the System process consuming one core's worth of CPU time.

Yes, I rebooted the computer after installing the drivers. I even uninstalled and reinstalled Oculus 0.7 drivers, restarting the computer each time. The problem persists.

To reproduce:

Start your computer. Do not run the config utility.
Run a VR program. The Rift light goes blue.
Exit the VR program. The Rift light goes yellow.
Run a VR program. The Rift light goes blue.
Now look in task manager, processes tab, "Show processes from all users".
You will see a mysterious "System" process by User Name "SYSTEM", consuming an entire core.
Live for Speed - www.lfs.net

axelat
Honored Guest
I can reproduce the problem.
(Win 10, SDK 0.7, Nvidia 358.50)

cybereality
Grand Champion
Sadly, I am not able to reproduce, System process reaches around 10% while a VR app is running, but quickly drops to normal levels (less than 1%) after closing the app. I would like to see this fixed, but there is some factor missing.
AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV

Scawen
Heroic Explorer
That's it, Cyber. It's not a problem after you exit VR and the System process drops down again. The problem is the consumption of one entire core while VR is running (except the first time, of course).

Now if you do that on a quad core machine you will find that 25% of CPU is used. On a dual core, 50% of CPU is used by that system process.

But it does not happen the first time you run VR.

You are thinking "oh 10% of cpu, no problem" but it is a big problem. That process isn't really doing anything. It's not there the first time you run VR after a reboot. It is one entire core. I speculate that you have 8 cores and just don't notice that you have lost an entire core. But you are reproducing the bug, and therefore it can be fixed.
Live for Speed - www.lfs.net

cybereality
Grand Champion
OK, yeah, I think I see what you're saying. I have a 6-core machine, so it wasn't a full core. Still, we will need to figure out what the issue is here. Certainly, if the 10%+ CPU is not actually needed, that is a lot of performance to lose for no reason. I have messaged the team again on this issue, and will make sure to follow up to get a resolution.
AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV

ralfal
Honored Guest
Just speculating, but since this still seems to be the case in 0.8 I could imagine that it's by design. Judging from my own experience over the last months it can be tough to get precise frame timing right without completely using up one thread. Spinning at full CPU usage is just better than putting a thread to sleep in this regard, even if there is nothing else to do than waiting. Maybe that's what happens in the Oculus compositor on purpose.

If one wants to implement asynchronous rendering that means on a non-hyperthreading quad core essentially half the CPU is blocked by the Oculus runtime doing things that hardly consume any CPU time at all by themselves except for waiting... One core is used entirely by the app's async render thread since ovrSubmitFrame blocks the CPU, another core is blocked by the System process (which I imagine to be largely the Oculus compositor in this case).

On quad/hexa cores with hyperthreading (Core i7) that is OK, as it still leaves at least 75% of the processor available. But on non-hyperthreading CPUs (Core i5 and below), which probably are used by the majority of gamers, it only leaves 50% of the CPU available, which is clearly not good enough.

Hopefully I'm completely wrong though and this is a solvable bug after all.