cancel
Showing results for 
Search instead for 
Did you mean: 

AMD Ryzen Threadripper plus Oculus Home equals high CPU usage.

OttersGonnaOtt
Honored Guest
So I just got done building a Ryzen 1950x Threadripper box.  It uses the Asus Zenith Extreme motherboard.  It uses G.Skill Trident Z RGB RAM, 4x8GB sticks in quad channel.  Everything is updated and running steady.  Every app or game I throw at this thing fails to make it use more than 20% CPU for working tasks (though 95% for passives, like video rendering, which is expected).  Then I decided to set up my Rift again, so I could get back to pre-vis modeling in Medium and the occasional game, thinking the RAM and CPU bottlenecks of my old i7 4930K rig would be a thing of the past.

Boy was I wrong.

The Sensors (three of them) seem to work just fine.  Plug in the Rift HMD while Home is closed, still fine.  Open Home with the HMD plugged in, then laugh as the CPU jumps between 50% and 90% usage.  It's enough to make devices like mice and keyboards lag, prevent apps from loading and rendering properly, and generally locks up the whole system.  Unplug the HMB or close Home and you drop back down to 3-10% like you'd expect.

The truly concerning element?  The Oculus runtimes do not tally up to the bump in CPU usage.  If I'm at 50% all of a sudden, I'll see the OVRServer_x64 process max at 10% and the Home runtime hit maybe 25%, with the rest of the system at about 3% total.  A service that isn't tied to a process might be using the rest, maybe?  It baffles the mind.

The same issues happen if launching a game directly, only the game process is what has the huge CPU usage increase.  This leads me to believe anything running the SDK or runtimes is affected.

In the HMD, the view renders smoothly, but tracking is extremely broken (accurate, but maybe updating five times a second) and ASW is very evidently kicking in to fill in the gaps.  On the PC view of any apps or games, the app/game is running perfectly smooth and having no issues.  Tracking is perfect in the 2D window, just choppy to the extreme in the HMD.  Again, this seems like an issue with the backend and not apps themselves.

I have tried disabling SMT/hyperthreading, disabling cores, switching on the AMD game compatibility mode in Ryzen Master (unique to Threadripper CPUs), and even base-clocking my RAM down to 2166MHz in case it was a latency issue from the XMP upclock.  Game Mode helped a smidgen, but at the expense of the CPU now ranging from 80% to 100%.  Nothing else had any effect.

I realize this is a new processor and a new motherboard to go with it.  They released very recently and are expensive, so not many people have them.  That's my issue though, that not enough people own a 1950X and a Rift.  I have no clue if this is a localized issue or something that Oculus needs to address with an update.  That's where you guys come into frame.  If you have a Ryzen system, preferably one with 8+ physical cores (I think my high 16 core, 32 thread count may be partially to blame), please speak up with your results.  If there's a fix or specific setting needed, we need to catalog it for others in my position.

I love my Rift, but I need my Threadripper.  I'd love to keep both, but I may have to buy a Vive instead just to access Medium now.  

Thanks, guys.  All input is appreciated and very welcome.
25 REPLIES 25

OttersGonnaOtt
Honored Guest
Attaching a log file dump in case anyone feels like perusing for issues.

TehJumpingJawa
Expert Protege
What are the USB chipsets on your board?
Which are your sensors/HMD connected to?
Is the same behaviour experienced with fewer sensors attached?

kojack
MVP
MVP
It makes me think of this recent article by Bruce Dawson:
https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/
Windows 10 has a bug where the more cores you have the worse performance can become if you do certain workloads (in his case lots of process spawning), to the point of his 48 hyperthread xeon barely moving the mouse. This is because every thread was bottlenecked waiting for a global lock.

Might not be related, but who knows.

Try setting the process affinity of the oculus stuff (home, etc) to less than the full number of cores to see if that helps (process affinity is an option in task manager).


Author: Oculus Monitor,  Auto Oculus Touch,  Forum Dark Mode, Phantom Touch Remover,  X-Plane Fixer
Hardware: Threadripper 1950x, MSI Gaming Trio 2080TI, Asrock X399 Taich
Headsets: Wrap 1200VR, DK1, DK2, CV1, Rift-S, GearVR, Go, Quest, Quest 2, Reverb G2

OttersGonnaOtt
Honored Guest


What are the USB chipsets on your board?
Which are your sensors/HMD connected to?
Is the same behaviour experienced with fewer sensors attached?


My motherboard has a few USB controllers and I spread the load evenly.  The HMD is on the Asus 3.1gen2 port, the front camera is on an AMD 3.1gen1 port, a rear camera is on an Asus 3.1gen1 port, and the last rear camera is on a 2.2 port using the same controller as the Asus 3.1gen1 camera. Both rears are shared (one is in 2.0 mode) and the rest are all alone. Again, the game or app tracks perfectly using the PC monitor view so the devices appear to have good bandwidth and power.


kojack said:

It makes me think of this recent article by Bruce Dawson:
https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/
Windows 10 has a bug where the more cores you have the worse performance can become if you do certain workloads (in his case lots of process spawning), to the point of his 48 hyperthread xeon barely moving the mouse. This is because every thread was bottlenecked waiting for a global lock.

Might not be related, but who knows.

Try setting the process affinity of the oculus stuff (home, etc) to less than the full number of cores to see if that helps (process affinity is an option in task manager).




I think this might be hitting the nail on the head. Ill try to create a bunch of artificial serialized threads tonight, similar to the tests that auther ran. It very well could be either a Windows serialized wait chain issue, or on the flip side that may be an innate issue with serialized threads and the solution is to parallelize now that 8+ cores are about to become standard. If the latter is true, the Oculus runtimes or even the HMD driver stack may simply (not the same as 'easily'!) need to be parallelized to prevent wait chain congestion.

This is a great insight here, and something I would have never assumed. Thanks. More to come after some tests tonight.

OttersGonnaOtt
Honored Guest
So I did some basic tests:

I physically removed RAM and used one stick at a time, both for a memtest86 validation on each and to test the Oculus app.  All sticks check out, and the issue persists on all sticks.  Pretty damn sure the RAM isn't the issue then.

I checked wait chains on processes.  OVRServer_x64.exe has about a dozen threads it's waiting upon, each showing as other Oculus processes (overlay, client, etc.)  The others have a pretty typical one or no threads in their wait chains.

I swapped around affinity values for all Oculus processes, trying evens, odds, the first four only, one only, and finally each process having a few different cores (4 each).  This did nothing to solve the system slowdown, and only had detrimental effects on the performance of Home.

I went a step further and set memory to local mode, switched on/off game mode, on/off SMT, and combinations of each--only this time I tried differing amounts of disabled cores, down to just 4 active ones in the end.  Again, no settings seem to have any impact, and the disabling of cores performed about the same as setting affinity (which is expected normally).

I tried reinstalling the Oculus software from a scratch, clean directory.  No impact, other than requiring I re-download apps and everything. ;(

I tried moving all devices to ASUS provided USB ports, thinking maybe the AMD USB controller was overloaded and that somehow bogged down the whole system.  No dice.  Still getting slowdown like that.

I then tried to disable ASW, but it looks like the keyboard shortcuts for this are no longer active.  I've noticed that Home runs and tracks relatively smoothly compared to apps and games, but it's unnecessarily correcting for rendering with what looks like ASW (there's smudging/motion-blocking on edges of objects when in motion).  That got me thinking--the only time I have issues is when the headset is rendering.  I apparently confirmed this with a few games that shut off the display when the HMD is removed.  The PC view still renders fine (on some games that keep it active) and Touch controllers track fine, but CPU usage looks to be normal.  Cover up that presence sensor though and the HMD sends the system back into meltdown.  That scenario could be a false positive though, as I don't know how things are actually handled when the HMD display shuts off.

This is quite confusing, because the USB and CPU stack (the usual culprits) seem to be working as intended.  Something about the Oculus device drivers or software is apparently just...  doing something wrong.  I do notice that I get mouse lag when the system boots (startup apps eat CPU for a few seconds and I get the same instability), and that points to a partial blame on the OS or AMD chipset drivers...  but that issue only replicates when all cores hit 80+% usage.  Oculus Home and the related secondary processes hover around 50-60% usually and not all cores are maxed out, which usually isn't an issue.  The idea that thread wait chains are bogging the system down does seem likely, but that's partially a software fix and not just hardware.

I'm going nuts here.  I don't have much else I know to test here.

TehJumpingJawa
Expert Protege
A shame you can't install win7(or Oculus had Linux support....) to see if that win10 serialised process destruction bug is the cause.

kojack
MVP
MVP
I tried to find any reports of Vive performance with threadripper, but I didn't find any (I also didn't try for long).

I'm planning on getting a 1950x, so I'm definitely interested in seeing what's up here.
(I do non real time graphics work, genetic algorithm and neural network training and c++ compiling, all of which benefit from lots of cores)


Author: Oculus Monitor,  Auto Oculus Touch,  Forum Dark Mode, Phantom Touch Remover,  X-Plane Fixer
Hardware: Threadripper 1950x, MSI Gaming Trio 2080TI, Asrock X399 Taich
Headsets: Wrap 1200VR, DK1, DK2, CV1, Rift-S, GearVR, Go, Quest, Quest 2, Reverb G2

OttersGonnaOtt
Honored Guest

kojack said:

I tried to find any reports of Vive performance with threadripper, but I didn't find any (I also didn't try for long).

I'm planning on getting a 1950x, so I'm definitely interested in seeing what's up here.
(I do non real time graphics work, genetic algorithm and neural network training and c++ compiling, all of which benefit from lots of cores)




I'm in the same boat, where everything I do on the side benefits greatly from additional cores and Threadripper saves a load of my limited time outside of work. If you have a use for it, likely you won't want to go back after experiencing a 16 core system. Considering the major vendors (Intel, AMD) have officially stated all planned future chips will start at 8 cores though, the issues I'm having will need to be sorted out sooner or later. I hope this doesn't turn into a Vista fiasco, where everyone throws around blame instead of just fixing their drivers and code.

Sadly I can't find anyone else talking about Threadripper in conjunction with VR myself either. That partly is due to the insane amount of clone blog news articles regarding the processor though, and it may become easier in a while when the hype dies down.

TehJumpingJawa said:


A shame you can't install win7(or Oculus had Linux support....) to see if that win10 serialised process destruction bug is the cause.


Strangely (and ironically taking my rant above to heart) the material I've found regarding this issue starts in the Vista era. Windows 7 is definitely affected as well as anything newer. Likely XP would be as well if many-core processors existed in higher quantities at the time; there probably just weren't enough people with many-core rigs at the time to warrant reporting (or even noticing) the issue.

That said, I think that is an inherant problem in application design and not really an OS bug. Serializing processes means something is always waiting on something else. Asynchronous and parallel processing are the better options if possible. Imagine if a website like Google was serialized: People would need to 'wait in line' to perform searches and the whole site would get backed up to infinity. This is why servers run non-blocking code, so one action won't block another and artificially slow down an app.

This wouldn't be an issue for me if the Oculus software / driver stack was coded to use 32 threaded cores. That actuallt would help people with 4-core i5 systems, so basically everyone gets a boost. That's a huge request though, and there's likely a solid reason they chose to use the current system over a parallel, scaling one.  Not trying to complain here, I promise. 😉

OttersGonnaOtt
Honored Guest
Linking in a Reddit thread for cross-examination. 🙂

Threadripper Plus Rift Nukes CPU Usage?