Webxr: Document possible side effects of making a context xrCompatible

[toji]

I've seen that many frameworks doing WebXR integrations are blindly setting xrCompatible on every WebGL context they create, regardless of whether or not the apps content will ever use WebXR. This is something that may have long-reaching negative side effects on some devices, as it may cause some devices (like VR-capable laptops) to forcibly switch the entire system to render on the high-powered discreet GPU rather than the low-powered integrated one. Worse, the page's developer may not have any indication this will happen for their users because their development devices may not have multiple GPUs (as is the case with most mobile/standalone/desktop devices).

This should be documented in a visible place in the spec, probably as a non-normative note, to discourage over-use of xrCompatible in contexts where it's not needed. We should also do some dev rel with the major frameworks to try and work out a better usage pattern.

[toji]

Outreach to Three.js: https://github.com/mrdoob/three.js/issues/19275

[asajeffrey]

Ouch. Related to https://github.com/immersive-web/webxr/issues/603

[asajeffrey]

I'll repeat https://github.com/immersive-web/webxr/issues/603#issuecomment-616921006 again and say that the worst case I can imagine for this is if we're sending GL commands over a WiFi TCP stream to a thin-client headset. If every canvas is marked as xr-compatible, then this will result in a lot of texture data being sent of the wire.

[Maksims]

In PlayCanvas, it is set true by default as well.
There are two workflows, we can modify it:

1. Editor (online), where UI can be used to toggle it on/off. If developer uses XR without pre-flagging application, in Debug mode, we can give them console info "please use XR flag..".
2. engline-only, developer instantiate Application himself, and can provide appropriate flags.

Also, is this flag basically a "cheat": to guarantee use of discrete GPU for WebGL application? ;)

[toji]

There are two workflows, we can modify it:

Those both sound good. And with the right console messaging it should be a very minor thing for developers to fix when they first encounter the issue.

is this flag basically a "cheat": to guarantee use of discrete GPU for WebGL application? ;)

No, if that was all it was we'd have simply reused powerPreference: 'high-performance'. It specifically selects the best GPU for performing low-latency XR. It's true that in a majority of the cases this will simply be the discreet GPU, but in the case of something like an SLI system where you have multiple GPUs of similar or equal capabilities xrCompatible should cause the context to reside on the device the HMD is physically connected to, whereas powerPreference would have no to switch GPUs in that scenario.

[RafaelCintron]

@Maksims , @toji is correct with regard to not re-using powerPreference.

In addition, some runtimes require that the application use a specific adapter on the system. No other adapter is allowed. The specified adapter may or many not be the same as the adapter enumerated by power preference, though it generally is.

If you miss out on specifying the xrCompatible attribute at context creation time, you can use WebGLRenderingContextBase.makeXRCompatible. Be warned that you may receive webglcontextlost/webglcontextRestored events if you're not on the runtime's preferred adapter while the makeXRCompatible promise is outstanding.

[a2sheppy]

Note to whoever deals with the spec changes here; although the word "discreet" is being used throughout the comments here, what's really intended is "discrete."

[toji]

although the word "discreet" is being used...

🤣 They're very careful GPUs, Eric. They'd never tell another process about your draw calls.

[a2sheppy]

@toji That's good to know, because I'm very much in the "if it looks right, who cares what's under the hood" kind of guy when it comes to this stuff... :)

(I see this particular homophone _all the time_).