CPU usage increases over time

User Code & Projects virtual-reality
1

[Workaround and explanation further down. This initial post is not relevant]

Hi.
We’ve noticed that over time, the CPU usage will increase to a point where it leads to frame drops. This happens in as little as 5 minutes with no other activity.
Afaik, it can be tracked down to this call in OpenVR:

[removed to not cause confusion]

Some reading on the topic suggests it is a timing issue:

I’m continuing to look into this but wonder if anyone else can verify the issue. I’ve tried both with and without vsync.

I’m measuring using the resource manager and the Frame Timing display in SteamVR

@jseinturier ?

2

I’ll treat this as a “live” thread and update this as I investigate.
I’ve managed to stop the increase in cpu usage. I moved the contents of the update() thread in OpenVRViewManager to render() instead. The motivation was the first link I posted:

“The documentation says to call it right before starting to render. It does some important syncing and ensures that your rendered frames can be displayed in the headset with as little latency as possible.”

I first tried just moving dev.updatePose(); but that didn’t do anything.

I need to continue looking into it. Not sure if it affects the general framerate or not, yet.

3

I see now that the branch I’m working on is based on older code. So I can’t say whether it applies to the latest version. The relevant parts seem to be the same, though.
#lostinbranchlation

4

I turns out I was wrong on the cause, it (thankfully) seems to be simpler. I had missed the following code that I had commented out:

if( environment.hasTraditionalGUIOverlay() ) {
            // update the mouse?
//            environment.getVRMouseManager().update(tpf);

            // update GUI position?
            if( environment.getVRGUIManager().isWantsReposition() || environment.getVRGUIManager().getPositioningMode() != VRGUIPositioningMode.MANUAL ) {
                    environment.getVRGUIManager().positionGuiNow(tpf);
                    environment.getVRGUIManager().updateGuiQuadGeometricState();
            }
        }

The line now commented was the cause. It requires some further digging to solve, which I might do eventually, but I don’t have time now. Since we don’t use the mouse inside the app, the above solution is OK for now.

2 Likes
5

Thanks for sharing mate.

How are you finding VR dev? It interests me very much but I am yet to give it a crack

6

It might sound exotic, but in most cases it’s a lot like developing any app for jme. Apart from the rare excursion here above, worrying about the VR capabilities is not that common. The difference is mostly when testing, you need to put on an HMD (which may sound trivial but can become cumbersome when you do it 10 times in an hour).

Biggest difference are user interaction, because you don’t see the devices, and gui because you have a limited FOV (but that is solvable with the api). Then there are a couple of filters that don’t work correctly yet in stereo view.

The biggest downside is that (as in most cases), when you work with something every day, it loses its glamor. :slight_smile:

4 Likes