Switching scenes in a WebXR session makes Quest 2 go out of memory

Questions
,
1

Hi!

A project I am working on requires the user to be able to jump between scenes within the same WebXR Session.

After a lot of research, we found this topic: Jumping between scenes while in WebXR.

So we used @JCPalmer’s implementation as a starting point and now we are actually able to perform seamless navigations between scenes while in WebXR!

Now the problem is: everything works fine on PC with an emulator, but as soon as we use an actual device (a Meta Quest 2) we experience some OOM issues, which eventually cause the browser (or even the whole device) to crash and reboot.

After we perform a scene navigation, we actually dispose the previous scene and everything it contains, but still we see the “Free memory” value in the Meta Quest Developer Hub’s perform analyzer inexorably decrease after each navigation.

At this point I’m even running my tests with empty scenes to exclude there is something wrong with our contents.

Also, I was not able to identify relevant memory leaks in Google Chrome’s performance profiler.

I suspect it is something related to the memory allocated within the WebGL context itself, which is never released until the session is closed.

This seams to be confirmed when I run the command “adb shell dumpsys meminfo -d” after I have performed about 10 scene navigations in WebXR:

image
image282×699 11.1 KB

As you can see, the values of “GL mtrack”, “EGL mtrack” and “Other mtrack” increase by a lot after each navigation, and they almost clear up as soon as I close the WebXR session.

Another thing I notice, when I run the command “adb shell gpumeminfo -l -d”, is that the count of renderbuffers increases by one on every scene navigation.

Can someone help me sorting out what is going on?
All I found about the “mtrack” metrics is some sparse information, and I still don’t understand why they are growing so fast.

Thanks in advance and sorry for the very long question!

2

The garbage collection of the scene is the tricky part, of course, once it works. Finding references being held is never easy.

BTW, I know I ended up with 5 replacement classes, not just the 3 from that thread. I also ended up replacing classes, not sub-classing. Just more workable, & less worry that those classes are changed somehow for a bug fix or something. The other side of that is you need to periodically check current code of those classes, with a snapshot of the classes at the time you grabbed. For me that was Babylon version 5.30.1, I think.

You are in really deep water. I do not know what that android terminology is, but the render buffer increase was not expected.

I would say, if you had something which was a good test, that I would report to Oculus, but we are just swapping the scene & the browser should not even have known that it happened.

3

Thank you so much for your response!

I confirm our implementation of the WebXR navigation was built up starting from your latest commits on your fork, so we are already using the class-replacing approach.

About my OOM problem, it turns out it was mainly caused by a call to WebXRManagedOutputCanvas’ initializeXRLayerAsync method, which we performed upon each navigation in order to remove a reference to the previous scene in the WebXRLayerRenderTargetTextureProvider.

1 Like
4

I can see how this will cause an increase in memory usage. We don’t support it, but I will be happy to put it on my backlog to check the implementation and give a few hints, if I find any issue with GC.
This might take a little while since my backlog is growing daily but not equally shrinking. Just one of those months… :slight_smile:

1 Like
5

Right now, I am not working on this. I have the blessing / curse of too many problems. Right now I Am working on the ones I have answers for / draining the swamp. Anything for this was kind of scheduled after the 7.0 print, to catch any changes to original classes at the same time. I have this inside a much bigger thing.

Probably should make a highly contained example / unit test page, so any leaks can be isolated to just this, and not the whole thing.

Have bookmarked this, to check on. If there is any hints, please toss them on this thread.