I was not aware there is something oculus specific I can enable. What can I try on that front? I just used useMultiview with create default VR experience method. I tried with and without antialias and the difference was in order of 5%. The CPU usage was lower than 15%.
When entering chrome://flags you can enable one of two extensions for multiview - the oculus specific one (which supports anti-aliasing) and the regular multi-view extension, which doesn’t support anti-alias (even if set to true).
GPU should not be so high in any way, but the oculus version will use much more GPU time.
I am using Oculus Quest (standalone headset). In Quest I use the Oculus Browser and I did not need explicitly set any extensions. According to Oculus the oculus_multiview is the one enabled by default:
I am not sure where the problem is but something odd is happening as the GPU usage is more than twice higher with multiview enabled when expected to be lower.
That’s a new (and blessed) change. Both used to be behind a flag last time i checked…
I did some tests just now (the hill valley VR scene):
Without multiview - 47 FPS, 85% average GPU (R) usage
With Oculus Multiview - 40 FPS, 95% GPU Usage
Standard Multiview2 - 58 FPS, 75% GPU utilization. But no antialiasing…
Seems like the oculus multiview is not bringing anything positive to the table. I will dig in and see how we can improve that, it is always possible we are doing something fundamentally wrong.
Spent a long time on this (since there is another issue with multiview).
Unless I am missing something, we are using multiviews as they were intended to be used. There is a small issue with texture resizing, which leads to a bit of increase in GPU, but it shouldnt influence that much.
And then I went and tested 03 - VR Presentation WebGL2 with my quest , which is the demo oculus puts on their multiview pages:
No multiview - 18% GPU
Multiview OVR (no antialias) - 26%
Multiview Oculus extension - 32%
Dunno… it seems to me like multiview is a nice idea on paper, but when it comes to the extension implementation, it doesn’t fulfill its potential. It is probably due to the fact that for webvr it requires a workaround, which actually makes it work harder.
Having said that, CPU was lower when multiview were used, which kind’a makes sense - less CPU computations, more GPU computations.
I will keep on checking things and try to optimize it as much as we can, but i believe it is a more fundamental issue with multiview and webvr (which is deprecated).
WebXR should support multiview in a different and better way, I am crossing my fingers that by then we will have much better process optimization in the browser.