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

Scawen
Heroic Explorer
I haven't tried the Config Utility trick since installing the new drivers, so don't know if it still works. I just got the Rift all set up, found the CPU consuming bug was still not fixed and put the Rift away again, as I have done several times in the last 8 weeks.

No point trying to develop for the Rift at the moment while the new drivers are full of bugs. Best to stick with 0.6 as it has the best compatibility and fewest bugs.

I don't know what NVIDIA surround and bezel correct are, I have the simplest setup. I think this CPU consuming process is initialised on most if not all computers with an NVIDIA card. I don't think it is some specific setup.
Live for Speed - www.lfs.net

TrevorA
Protege
"scawen" wrote:
I haven't tried the Config Utility trick since installing the new drivers, so don't know if it still works. I just got the Rift all set up, found the CPU consuming bug was still not fixed and put the Rift away again, as I have done several times in the last 8 weeks.

No point trying to develop for the Rift at the moment while the new drivers are full of bugs. Best to stick with 0.6 as it has the best compatibility and fewest bugs.

I don't know what NVIDIA surround and bezel correct are, I have the simplest setup. I think this CPU consuming process is initialised on most if not all computers with an NVIDIA card. I don't think it is some specific setup.


Good, so just a simple bug then. Can't believe they are saying they can't reproduce it, that seems impossible.

Config utility worked for me just now, so maybe only an issue on a driver crash, at least that's something, but no real response in 8 weeks is frankly...... quite normal 🙂

Scawen
Heroic Explorer
Cyber confirms that he can reproduce it now. Eight weeks ago, they really didn't want to know there was a bug, so they didn't bother to follow CrazyNorman's simple instructions to reproduce it. They basically hoped we were a bunch of crazy lunatics seeing bugs that didn't really exist. It was easier for them to believe that, rather than spend 5 minutes looking into the bug.

"TrevorA" wrote:
but no real response in 8 weeks is frankly...... quite normal 🙂
The Oculus developers seem to have this idea that fixing bugs will slow their development, and therefore they shouldn't waste any time fixing them (or even having a quick look to see what the problem is). Meanwhile, fewer and fewer customers and software developers can actually use their Rift.
Live for Speed - www.lfs.net

cybereality
Grand Champion
I know this has taken awhile, but we are currently investigating this issue. I was able to repro, and obtained some logs that I have forwarded to the engineering team. I believe that should be enough information for them to track it down, but I will continue to stay on top of the bug until it is resolved. Thanks for your patience.
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
For everyone in need of a workaround until the issue is sorted out:

Opening the Oculus Config Utility before anything else Rift related and then not close it again seems to prevent the issue from occuring. Obvious downside is that both headset and camera are powered on the whole time, but apart from that it seems to help.

cybereality
Grand Champion
You guys will be happy to hear that we have found the problem! Very sorry for the long run around on this one.
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
Thanks for the info.
Live for Speed - www.lfs.net

gaelhonorez
Honored Guest
"cybereality" wrote:
You guys will be happy to hear that we have found the problem! Very sorry for the long run around on this one.


Is it possible to have a quickfix ASAP ? This is a showstopper for us on the Oculus target machine.

cybereality
Grand Champion
A fix is coming, but I don't have a solid ETA. I can't imagine it will be too long though.
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

DeathZone
Honored Guest
"CrazyNorman" wrote:
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.



Windows 8.1 has a memory leak and it doesn't replace memory that it uses. you can fix it by doing some registry editing but i recommend that you just update to windows 7 or 10.