New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document possible side effects of making a context xrCompatible #1014
Comments
Outreach to Three.js: mrdoob/three.js#19275 |
Ouch. Related to #603 |
I'll repeat #603 (comment) 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. |
In PlayCanvas, it is set
Also, is this flag basically a "cheat": to guarantee use of discrete GPU for WebGL application? ;) |
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.
No, if that was all it was we'd have simply reused |
@Maksims , @toji is correct with regard to not re-using 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 |
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." |
🤣 They're very careful GPUs, Eric. They'd never tell another process about your draw calls. |
@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). |
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.The text was updated successfully, but these errors were encountered: