0.7 BUG: Oculus Service consumes CPU on multiple uses - Page 2 — Oculus
New to the forums? Click here to read the "How To" Guide.

Developer? Click here to go to the Developer Forums.

0.7 BUG: Oculus Service consumes CPU on multiple uses

2

Comments

  • cyberealitycybereality Posts: 26,156 Oculus Staff
    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
  • AlricAlric Posts: 112
    Hiro Protagonist
    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.
  • ScawenScawen Posts: 589
    Trinity
    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
  • ScawenScawen Posts: 589
    Trinity
    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
  • axelataxelat Posts: 7
    I can reproduce the problem.
    (Win 10, SDK 0.7, Nvidia 358.50)
  • cyberealitycybereality Posts: 26,156 Oculus Staff
    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
  • ScawenScawen Posts: 589
    Trinity
    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
  • cyberealitycybereality Posts: 26,156 Oculus Staff
    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
  • ralfalralfal Posts: 191
    edited October 2015
    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.
  • ralfal wrote:
    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.

    Errr, one entire thread whatever the power of the thread is ? And why shouldn't need it the first time after a boot ? :)
  • ralfalralfal Posts: 191
    Maybe you have something else in mind than me. What I was describing always happens, even the first time after a reboot. At least on all machines here.
  • ScawenScawen Posts: 589
    Trinity
    The subject of this thread is a bug that does not happen on the first run of VR after a reboot but then does happen on all subsequent runs. It still happens in 0.8 runtime.

    Cybereality now knows how to reproduce it: viewtopic.php?f=34&t=26161&start=20#p301752

    I believe it is reproducible on all computers. On some computers it causes stutter that makes the Rift unusable, even if that computer runs good VR on the first run after a reboot. On other computers with many cores, the performance loss due to the bug may go unnoticed.

    The high CPU usage is only while the VR program is still running (the second time and thereafter).

    How to reproduce it, explained slightly differently:

    1) In task manager, make sure you have "Show processes from all users" set. Otherwise you will not see the CPU consuming process.

    2) Probably leave the task manager running on your desktop so you can look at it any time by lifting the Rift up, while a VR program is still running.

    3) The first time you run a VR program after a reboot, there is no "System" process with high CPU usage. All OK.

    4) When you exit a VR program, then start VR again, then there is a "System" process using a whole core.

    5) Do not have the Config Utility open while doing this test. If it is open, the Rift light never goes from blue to yellow. The high CPU usage is when the Rift light goes from blue to yellow and back to blue again (when the second VR run is started, and all runs thereafter until reboot).
    Live for Speed - www.lfs.net
  • ScawenScawen Posts: 589
    Trinity
    User mabsey has done some good research and tracked down the process responsible for the CPU consumption.
    viewtopic.php?f=34&t=25914&start=60#p301915
    Live for Speed - www.lfs.net
  • TrevorATrevorA Posts: 60
    Hiro Protagonist
    ?Any news on this?


    100% a bug, it has been described very clearly, first run the system process is there but runs at a very low process, on my 6 core about 1-3% max, then close VR app and reopen and immediately the system process takes over a random core. Having hyperthreading on disguises it, I only realised it was an issue during testing with hyperthreading off and wondering why everything ran better after a reboot. Now I know.

    But this is a VERY easily reproduce-able issue.

    I'm on win 10, runtme 0.8 nvidia .78 drivers, 5820 and 980Ti. And having to reboot EVERY single time I go into or out of a VR app, on my task manager this process goes up to 25% CPU even on a 6 core, so actually it must be going across multiple cores.

    On the first run it is negligible and anything I run in VR runs smoother and better, so zero chance it isn't a bug in either the runtime or the nvidia driver.
  • cyberealitycybereality Posts: 26,156 Oculus Staff
    I am able to repro this myself, and I'm working with the team to investigate further.
    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
  • ScawenScawen Posts: 589
    Trinity
    TrevorA wrote:
    having to reboot EVERY single time I go into or out of a VR app
    Hi Trevor. I can't believe they are taking so long to fix this. Eight weeks now...

    Anyway I am posting to let you know a sort of workaround. If you know you are going to be doing several VR runs, you can open the Oculus Configuration Utility before you start, and leave it running. Then for some reason the Rift light never goes back from blue to yellow when you end a VR program.

    And that means the second time you start VR, it doesn't start that stupid process. The stupid process is only started when the light goes from yellow to blue (after the first time).
    Live for Speed - www.lfs.net
  • TrevorATrevorA Posts: 60
    Hiro Protagonist
    Scawen wrote:
    TrevorA wrote:
    having to reboot EVERY single time I go into or out of a VR app
    Hi Trevor. I can't believe they are taking so long to fix this. Eight weeks now...

    Anyway I am posting to let you know a sort of workaround. If you know you are going to be doing several VR runs, you can open the Oculus Configuration Utility before you start, and leave it running. Then for some reason the Rift light never goes back from blue to yellow when you end a VR program.

    And that means the second time you start VR, it doesn't start that stupid process. The stupid process is only started when the light goes from yellow to blue (after the first time).

    That worked for me until the .78 drivers, I spotted yesterday it isn't working anymore, for me. Boot the comp, run the config utility, all good, run a game or demo and immediately system at 25% on a 6 core 5820.

    Reboot and run the same game, no issues until 2nd run. It is so easy to reproduce!

    I'll try the config utility again, as I only checked it once, maybe a fluke.
  • TrevorATrevorA Posts: 60
    Hiro Protagonist
    one thing, are any of you guys with this problem running nvidia surround/bezel correction? probably nothing but wonder if it could be a common factor. I am.
  • RoasterRoaster Posts: 1,052
    3Jane
    0.8 worked for me
    win 10 pro, GTX750
    i7-5820K @ 4.2Ghz, water cooled, Asus X99-Pro USB 3.1, 48 Gb DDR4 2400, Samsung 950 pro M.2 SSD, GTX 980 Ti SC, 750w psu
  • ScawenScawen Posts: 589
    Trinity
    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
  • TrevorATrevorA Posts: 60
    Hiro Protagonist
    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 :)
  • ScawenScawen Posts: 589
    Trinity
    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
  • cyberealitycybereality Posts: 26,156 Oculus Staff
    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
  • ralfalralfal Posts: 191
    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.
  • cyberealitycybereality Posts: 26,156 Oculus Staff
    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
  • ScawenScawen Posts: 589
    Trinity
    Thanks for the info.
    Live for Speed - www.lfs.net
  • 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.
  • cyberealitycybereality Posts: 26,156 Oculus Staff
    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
  • DeathZoneDeathZone Posts: 40
    Brain Burst
    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:
    DkTJP26.png
    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)
    vmTuh6k.png
    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%.
    68Vq9uH.png
    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.
    QSc6fPF.png
    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.
  • SharkkuSharkku Posts: 575
    Art3mis
    A fix is coming, but I don't have a solid ETA. I can't imagine it will be too long though.
    This is great news! I hadn't checked in on this thread in a while, so I didn't know that the problem was found. It's affecting my computer quite badly. Will there be a hotfix, or will it be in release 0.9?
    DK1 - previously owned
    DK2 - 2014-08-26 RECEIVED (ordered 2014-04-24)
    CV1 - 2016-05-25 RECEIVED (ordered on release day)
    Touch - 2016-12-07 RECEIVED (pre-order with CV1)
Sign In or Register to comment.