Update explainer to account for multi-GPU handling #226

toji · 2017-05-02T23:51:28Z

Closely follows Microsoft’s suggestion from #223, though I’ve moved the
ensureCompatibility call to the VRDevice because it feels a bit better
localized that way.

Closely follows Microsoft’s suggestion from #223, though I’ve moved the ensureCompatibility call to the VRDevice because it feels a bit better localized that way.

NellWaliczek · 2017-05-03T01:02:37Z

Thanks! This generally looks great :)
A few small things:

Your framing about "VR-Centric" vs "VR-Enhanced" was really helpful and it might be useful to include something similar here to assist developers in determining which approache is right for them.
Can we call out something about the fact that calling ensureContextCompatibility may (will always?) have impact on more than just the glcontext supplied? I'd love to know how folks are approaching the implementation of the power preference attribute. It may make sense for us to align with that pattern...
Can we say that ensureContextCompatibility may reject for other reasons (such as already having been paired with an incompatible VRDevice already?)

RafaelCintron · 2017-05-03T15:19:48Z

I'd love to know how folks are approaching the implementation of the power preference attribute. It may make sense for us to align with that pattern...

@grorg detailed how Webkit is approaching the powerPreference attribute in a post to the WebGL mailing list. The latest I've heard from @kenrussell is Chrome will be following a similar approach.

The language in the spec is written such that contextLost/restored can happen at any time to regulate power and memory consumption.

RafaelCintron · 2017-05-03T15:22:15Z

explainer.md

@@ -499,6 +512,8 @@ interface VRDevice : EventTarget {

  Promise<boolean> supportsSession(VRSessionCreateParametersInit parameters);
  Promise<VRSession> requestSession(VRSessionCreateParametersInit parameters);
+
+  Promise<void> ensureContextCompatibility(WebGLRenderingContext context);


We should use WebGLRenderingContextBase instead of WebGLRenderingContext so that the API can be used with WebGL 2.

Agree with this, or perhaps use a union type if you want to refer to a data type that's exposed to JavaScript. (WebGLRenderingContextBase isn't.)

Good catch. I swear I had already done that.

I don't think there's a problem with using WebGLRenderingContextBase here, even if it isn't Javascript exposed. The IDLs should still parse correctly. (But if not, then yes. A union would work just fine.)

@NellWaliczek

Thanks @NellWaliczek, @RafaelCintron, and @kenrussell!

toji · 2017-05-07T04:35:08Z

Updated the pull request based on feedback. Felt silly adding a couple of lines around some unrelated topics that I know we'll be replacing soon, but it was necessary to maintain a decent flow in the document. 🤷‍♂️

PTAL!

NellWaliczek

Looking good!

NellWaliczek · 2017-05-08T16:58:33Z

explainer.md

+
+**VR Enhanced:** The app can take advantage of VR, but it's used as a progressive enhancement rather than a core part of the experience. Most users will probably not interact with the app's VR features, and as such asking them to make VR-centric decisions early in the app lifetime would be confusing and innapropriate. An example would be a news site with an embedded 360 photo gallery or video. (We expect the large majority of early WebVR content to fall into this category.)
+
+This style of application should call `VRDisplay.ensureContextCompatibility` with the WebGL context in question. This will set a compatibility bit on the context that allows it to be used. Contexts without the compatibility bit will fail when attempting to create a `VRLayer` with them. In the event that a context is not already compatible with the `VRDisplay` the [context will be lost and attempt to recreate itself](https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.14.13) using the compatible graphics adapter. It is the page's responsibility to handle WebGL context creation loss properly, recreating any necessary WebGL resources in response. If the context loss is not by the page handled the promise returned by `ensureContextCompatibility` will fail. The promise may also fail for a variety of other reasons, such as the context being actively used by a different, incompatible `VRDevice`.


"It is the page's responsibility to handle WebGL context creation loss properly," Did you mean to have the word "creation" in this sentence?

NellWaliczek · 2017-05-08T16:59:04Z

explainer.md

+
+The content to present to the device is defined by a [`VRLayer`](https://w3c.github.io/webvr/#interface-vrlayer). In the initial version of the spec only one layer type, `VRCanvasLayer`, is defined and only one layer can be used at a time. This is set via the `VRSession.baseLayer` attribute. (`baseLayer` because future versions of the spec will likely enable multiple layers, at which point this would act like the `firstChild` attribute of a DOM element.)
+
+In order for a WebGL canvas to be used with a `VRCanvasLayer`, it's context must be _compatible_ with the `VRDevice`. This can mean different things for different environments. For example, on a desktop computer this means that the context should be created against the graphics adapter that the `VRDevice` is physically plugged into. On most mobile devices though, that's not a concern and so the context will always be compatible. In either case, the WebVR application will need to take steps to ensure WebGL context compatibility before using it with a `VRLayer`.


it's context must be->its context must be

NellWaliczek · 2017-05-08T17:13:38Z

explainer.md

+
+In order for a WebGL canvas to be used with a `VRCanvasLayer`, it's context must be _compatible_ with the `VRDevice`. This can mean different things for different environments. For example, on a desktop computer this means that the context should be created against the graphics adapter that the `VRDevice` is physically plugged into. On most mobile devices though, that's not a concern and so the context will always be compatible. In either case, the WebVR application will need to take steps to ensure WebGL context compatibility before using it with a `VRLayer`.
+
+When it comes to ensuring canvas compatibility there's a two broad categories that apps will fall under.


there's a two -> there's two

NellWaliczek · 2017-05-08T17:14:47Z

explainer.md

+
+The content to present to the device is defined by a [`VRLayer`](https://w3c.github.io/webvr/#interface-vrlayer). In the initial version of the spec only one layer type, `VRCanvasLayer`, is defined and only one layer can be used at a time. This is set via the `VRSession.baseLayer` attribute. (`baseLayer` because future versions of the spec will likely enable multiple layers, at which point this would act like the `firstChild` attribute of a DOM element.)
+
+In order for a WebGL canvas to be used with a `VRCanvasLayer`, it's context must be _compatible_ with the `VRDevice`. This can mean different things for different environments. For example, on a desktop computer this means that the context should be created against the graphics adapter that the `VRDevice` is physically plugged into. On most mobile devices though, that's not a concern and so the context will always be compatible. In either case, the WebVR application will need to take steps to ensure WebGL context compatibility before using it with a `VRLayer`.


on a desktop computer this means that the context should be created -> on a desktop computer this may mean the context must be created

NellWaliczek · 2017-05-08T17:15:26Z

explainer.md

+
+The content to present to the device is defined by a [`VRLayer`](https://w3c.github.io/webvr/#interface-vrlayer). In the initial version of the spec only one layer type, `VRCanvasLayer`, is defined and only one layer can be used at a time. This is set via the `VRSession.baseLayer` attribute. (`baseLayer` because future versions of the spec will likely enable multiple layers, at which point this would act like the `firstChild` attribute of a DOM element.)
+
+In order for a WebGL canvas to be used with a `VRCanvasLayer`, it's context must be _compatible_ with the `VRDevice`. This can mean different things for different environments. For example, on a desktop computer this means that the context should be created against the graphics adapter that the `VRDevice` is physically plugged into. On most mobile devices though, that's not a concern and so the context will always be compatible. In either case, the WebVR application will need to take steps to ensure WebGL context compatibility before using it with a `VRLayer`.


the WebVR application will need to take -> the WebVR application must take

NellWaliczek · 2017-05-08T17:16:27Z

explainer.md

+
+The content to present to the device is defined by a [`VRLayer`](https://w3c.github.io/webvr/#interface-vrlayer). In the initial version of the spec only one layer type, `VRCanvasLayer`, is defined and only one layer can be used at a time. This is set via the `VRSession.baseLayer` attribute. (`baseLayer` because future versions of the spec will likely enable multiple layers, at which point this would act like the `firstChild` attribute of a DOM element.)
+
+In order for a WebGL canvas to be used with a `VRCanvasLayer`, it's context must be _compatible_ with the `VRDevice`. This can mean different things for different environments. For example, on a desktop computer this means that the context should be created against the graphics adapter that the `VRDevice` is physically plugged into. On most mobile devices though, that's not a concern and so the context will always be compatible. In either case, the WebVR application will need to take steps to ensure WebGL context compatibility before using it with a `VRLayer`.


Perhaps...
compatibility before using it with a VRLayer. ->compatibility before using it with a VRCanvasLayer.

NellWaliczek · 2017-05-08T17:18:39Z

explainer.md

+let gl = glCanvas.getContext("webgl", { compatibleVrDevice: vrDevice });
+```
+
+Ensuring context compatibility with a `VRDisplay` through either method may have side effects on other graphics resources in the page, such as causing the entire user agent to switch from rendering using an integrated GPU to a discreet GPU.


Is there a way to make this last sentence more visible? Since this could have a big impact, it's pretty important it not get lost in the explainer ^_^

RafaelCintron

Thank you for making these changes @toji . I have mostly minor issues.

RafaelCintron · 2017-05-08T21:46:01Z

explainer.md

@@ -120,15 +120,13 @@ function BeginVRSession(isExclusive) {
 }
 ```

-Once the session is started some setup must be done to prepare for rendering. The content to present to the device is defined by a [`VRLayer`](https://w3c.github.io/webvr/#interface-vrlayer). In the initial version of the spec only one layer type, `VRCanvasLayer`, is defined and only one layer can be used at a time. This is set via the `VRSession.baseLayer` attribute. (`baseLayer` because future versions of the spec will likely enable multiple layers, at which point this would act like the `firstChild` attribute of a DOM element.)
+Once the session is started some setup must be done to prepare for rendering. When using an exclusive session the canvas width and height must be set to the appropriate size for the `VRDevice` display. The correct size can be queried from `VRSession.getSourceProperties()`. The depth range the session will use should also be set to something appropriate for the application. This range will be used in the construction of the projection matricies provided by `VRSession.getDevicePose()` each frame.


Once the session is started some setup must be done to prepare for rendering

Should be: "Once the session has started, some setup must be done to prepare for rendering."

When using an exclusive session the canvas width and height must be set to the appropriate size for the VRDevice display.

Should be: "When using an exclusive session, the canvas width and height must be set to the appropriate size for the VRDevice display."

RafaelCintron · 2017-05-08T21:46:48Z

explainer.md

+### Setting up a VRLayer
+
+The content to present to the device is defined by a [`VRLayer`](https://w3c.github.io/webvr/#interface-vrlayer). In the initial version of the spec only one layer type, `VRCanvasLayer`, is defined and only one layer can be used at a time. This is set via the `VRSession.baseLayer` attribute. (`baseLayer` because future versions of the spec will likely enable multiple layers, at which point this would act like the `firstChild` attribute of a DOM element.)
+


In the initial version of the spec only one layer type, VRCanvasLayer, is defined and only one layer can be used at a time.

Should be: "In the initial version of the spec, only one layer type, VRCanvasLayer, is defined and only one layer can be used at a time. "

RafaelCintron · 2017-05-08T21:51:08Z

explainer.md

+
+**VR Enhanced:** The app can take advantage of VR, but it's used as a progressive enhancement rather than a core part of the experience. Most users will probably not interact with the app's VR features, and as such asking them to make VR-centric decisions early in the app lifetime would be confusing and innapropriate. An example would be a news site with an embedded 360 photo gallery or video. (We expect the large majority of early WebVR content to fall into this category.)
+
+This style of application should call `VRDisplay.ensureContextCompatibility` with the WebGL context in question. This will set a compatibility bit on the context that allows it to be used. Contexts without the compatibility bit will fail when attempting to create a `VRLayer` with them. In the event that a context is not already compatible with the `VRDisplay` the [context will be lost and attempt to recreate itself](https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.14.13) using the compatible graphics adapter. It is the page's responsibility to handle WebGL context creation loss properly, recreating any necessary WebGL resources in response. If the context loss is not by the page handled the promise returned by `ensureContextCompatibility` will fail. The promise may also fail for a variety of other reasons, such as the context being actively used by a different, incompatible `VRDevice`.


If the context loss is not by the page handled the promise returned by ensureContextCompatibility will fail.

Should be: "If context lost is not handled by the page, the promise returned by ensureContextCompatibility will be rejected."

Oof. 😫 Yoda my fingers think I am.

RafaelCintron · 2017-05-08T21:52:11Z

explainer.md

+When it comes to ensuring canvas compatibility there's a two broad categories that apps will fall under.
+
+**VR Enhanced:** The app can take advantage of VR, but it's used as a progressive enhancement rather than a core part of the experience. Most users will probably not interact with the app's VR features, and as such asking them to make VR-centric decisions early in the app lifetime would be confusing and innapropriate. An example would be a news site with an embedded 360 photo gallery or video. (We expect the large majority of early WebVR content to fall into this category.)
+


innapropriate -> inappropriate.

RafaelCintron · 2017-05-08T23:01:06Z

explainer.md

 }
 ```

+**VR Centric:** The app's primary use case is VR, and as such it doesn't mind initializing resources in a VR-centric fashion, which may include asking users to select a headset as soon as the app starts. An example would be a game which is dependent on VR presentation and input. These types of applications can to avoid the need to call `ensureContextCompatibility` and the possible context loss that it may trigger by passing the `VRDevice` that the context will be used with as a context creation argument.
+


These types of applications can to avoid the need to call ensureContextCompatibility and the possible context loss that it may trigger by passing the VRDevice that the context will be used with as a context creation argument.

Should be: "These types of applications can avoid calling ensureContextCompatibility, and the possible context loss that it may trigger, by passing the VRDevice that the context will be used with as a context creation argument.

RafaelCintron · 2017-05-09T02:03:01Z

explainer.md

+let gl = glCanvas.getContext("webgl", { compatibleVrDevice: vrDevice });
+```
+
+Ensuring context compatibility with a `VRDisplay` through either method may have side effects on other graphics resources in the page, such as causing the entire user agent to switch from rendering using an integrated GPU to a discreet GPU.


One disadvantage of having the developer pass the VRDevice as a context creation attribute and/or calling ensureContextCompatibility is that multiple documents on the page can fight about the GPU if each one passes a different VRDevice to these two mechanisms. Perhaps we only allow one selection at a time per document. For iFrames, we can use the permissions API to mitigate this.

toji · 2017-05-09T04:20:18Z

Thanks for calling out my atrocious grammar. 😅 Updated with the above suggestions.

toji · 2017-05-12T18:31:41Z

Given the lack of negative feedback I'm going to merge this. As always, nothing is final yet so please file issues or follow up pull requests if there's some aspect of this change that needs clarification.

Following the language from the PR for the 2.0 explainer (#226), this adds a paragraph that describes the expected sequence of events during requestPresent, in the event that a WebGL context is not compatible with the VRDisplay's graphics adapter. The webglcontextlost will be fired, and if Event.preventDefault() is called, the user agent will at that point switch to the VRDisplay's graphics adapter and continue the requestPresent process.

Updated explainer to account for multi-GPU handling

26741c3

Closely follows Microsoft’s suggestion from #223, though I’ve moved the ensureCompatibility call to the VRDevice because it feels a bit better localized that way.

toji force-pushed the multi-gpu branch from cf43ca1 to 26741c3 Compare May 2, 2017 23:55

RafaelCintron reviewed May 3, 2017

View reviewed changes

Addressing feedback from the pull request

9ca555d

Thanks @NellWaliczek, @RafaelCintron, and @kenrussell!

NellWaliczek suggested changes May 8, 2017

View reviewed changes

RafaelCintron reviewed May 9, 2017

View reviewed changes

Addressing grammatical feedback.

f6632ea

dlibby- mentioned this pull request May 11, 2017

Update WebVR 1.1 spec to account for multi-GPU handling #230

Merged

toji merged commit 446d1a9 into master May 12, 2017

toji deleted the multi-gpu branch May 12, 2017 18:31

toji mentioned this pull request Jun 7, 2017

GL Context Lost - preventDefault mrdoob/three.js#11435

Closed

13 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update explainer to account for multi-GPU handling #226

Update explainer to account for multi-GPU handling #226

toji commented May 2, 2017

NellWaliczek commented May 3, 2017

RafaelCintron commented May 3, 2017 •

edited

RafaelCintron May 3, 2017

kenrussell May 3, 2017

toji May 5, 2017

toji commented May 7, 2017

NellWaliczek left a comment

NellWaliczek May 8, 2017

NellWaliczek May 8, 2017

NellWaliczek May 8, 2017

NellWaliczek May 8, 2017

NellWaliczek May 8, 2017

NellWaliczek May 8, 2017

NellWaliczek May 8, 2017

RafaelCintron left a comment

RafaelCintron May 8, 2017

RafaelCintron May 8, 2017

RafaelCintron May 8, 2017

toji May 9, 2017

RafaelCintron May 8, 2017

RafaelCintron May 8, 2017

RafaelCintron May 9, 2017

toji commented May 9, 2017

toji commented May 12, 2017


		VR Enhanced: The app can take advantage of VR, but it's used as a progressive enhancement rather than a core part of the experience. Most users will probably not interact with the app's VR features, and as such asking them to make VR-centric decisions early in the app lifetime would be confusing and innapropriate. An example would be a news site with an embedded 360 photo gallery or video. (We expect the large majority of early WebVR content to fall into this category.)

		This style of application should call `VRDisplay.ensureContextCompatibility` with the WebGL context in question. This will set a compatibility bit on the context that allows it to be used. Contexts without the compatibility bit will fail when attempting to create a `VRLayer` with them. In the event that a context is not already compatible with the `VRDisplay` the [context will be lost and attempt to recreate itself](https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.14.13) using the compatible graphics adapter. It is the page's responsibility to handle WebGL context creation loss properly, recreating any necessary WebGL resources in response. If the context loss is not by the page handled the promise returned by `ensureContextCompatibility` will fail. The promise may also fail for a variety of other reasons, such as the context being actively used by a different, incompatible `VRDevice`.


		The content to present to the device is defined by a [`VRLayer`](https://w3c.github.io/webvr/#interface-vrlayer). In the initial version of the spec only one layer type, `VRCanvasLayer`, is defined and only one layer can be used at a time. This is set via the `VRSession.baseLayer` attribute. (`baseLayer` because future versions of the spec will likely enable multiple layers, at which point this would act like the `firstChild` attribute of a DOM element.)

		In order for a WebGL canvas to be used with a `VRCanvasLayer`, it's context must be _compatible_ with the `VRDevice`. This can mean different things for different environments. For example, on a desktop computer this means that the context should be created against the graphics adapter that the `VRDevice` is physically plugged into. On most mobile devices though, that's not a concern and so the context will always be compatible. In either case, the WebVR application will need to take steps to ensure WebGL context compatibility before using it with a `VRLayer`.


		In order for a WebGL canvas to be used with a `VRCanvasLayer`, it's context must be _compatible_ with the `VRDevice`. This can mean different things for different environments. For example, on a desktop computer this means that the context should be created against the graphics adapter that the `VRDevice` is physically plugged into. On most mobile devices though, that's not a concern and so the context will always be compatible. In either case, the WebVR application will need to take steps to ensure WebGL context compatibility before using it with a `VRLayer`.

		When it comes to ensuring canvas compatibility there's a two broad categories that apps will fall under.

		### Setting up a VRLayer

		The content to present to the device is defined by a [`VRLayer`](https://w3c.github.io/webvr/#interface-vrlayer). In the initial version of the spec only one layer type, `VRCanvasLayer`, is defined and only one layer can be used at a time. This is set via the `VRSession.baseLayer` attribute. (`baseLayer` because future versions of the spec will likely enable multiple layers, at which point this would act like the `firstChild` attribute of a DOM element.)

Update explainer to account for multi-GPU handling #226

Update explainer to account for multi-GPU handling #226

Conversation

toji commented May 2, 2017

NellWaliczek commented May 3, 2017

RafaelCintron commented May 3, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

toji commented May 7, 2017

NellWaliczek left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RafaelCintron left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

toji commented May 9, 2017

toji commented May 12, 2017

RafaelCintron commented May 3, 2017 •

edited