TAG feedback on WebGPU

[Kangz]

The TAG review for WebGPU has been posted, with "Resolution: Satisfied"! However they still had a number of comments that we should discuss in the group and see if we need to do changes to the spec to address them. I'll copy them below so we can discuss before posting the resolution back to the TAG review issue.

(from @cynthia)

• Should there be a higher granularity for selecting devices? For example, for cases where one wants to select a high-VRAM device (e.g. for machine learning workloads) or the non-dominant (e.g. secondary device which hopefully will not jank the current compositor) device. Allowing a single application to be the dominant resource user is not new, but it is definitely something that want to be careful about.
• Power consumption is a concern. While there is a mechanism to allow applications to request a high power vs low power device, we are wondering if the choice should be initiated by the user, and not the application. e.g. if the user is on the go, let them choose integrated GPU instead of discrete to save power. Initially, we discussed the possibility of forcing the application to integrated in low-power scenarios, but adds another fingerprinting surface so we don't think this is a valid suggestion.
• It might be useful to have a note suggesting implementations should surface a warning about power usage at some point, given that this would be permission free.
• We have since revisited our position on permissions based on this data. Based on some informal asking around non-technical folks, the terms "graphics" is too generic and users will likely be confused - e.g. “yes, I guess the website needs graphics” when it is actually trying to mine Ethereum. For these reasons, gating behind a permission might not be adequate; but it might be useful to add a note (implementation detail) which allows users to revoke access (or kill it) if an application is hogging the GPU. (this would be analogous to the "this tab is hanging" dialog)
• Re: Figure out places where we should use USVString #784 - we are happy with the group's conclusion.

There is one meta-question that remains to be answered here, how can we do better with large specs like this? Current process is very optimized towards small-ish, self-contained specs that can be reviewed in a single day. This definitely wasn't one of them and we had multiple F2F meetings where we would not have enough time in a single sitting, causing it to be rescheduled multiple times. We'll discuss this internally and see if we can make a proposal to improve this going forward.

[greggman]

this is interesting feedback but not sure how relevant is it to the spec

• Should there be a higher granularity for selecting devices? For example, for cases where one wants to select a high-VRAM device (e.g. for machine learning workloads) or the non-dominant (e.g. secondary device which hopefully will not jank the current compositor) device. Allowing a single application to be the dominant resource user is not new, but it is definitely something that want to be careful about.

What percent of users have machines with multiple GPUs and is it increasing or decreasing?

Power consumption is a concern. While there is a mechanism to allow applications to request a high power vs low power device, we are wondering if the choice should be initiated by the user, and not the application. e.g. if the user is on the go, let them choose integrated GPU instead of discrete to save power. Initially, we discussed the possibility of forcing the application to integrated in low-power scenarios, but adds another fingerprinting surface so we don't think this is a valid suggestion.

Seems like this is not a spec thing but a UA thing. Any UA is free to choose one GPU or another other and/or let the user choose the GPU(s) in settings or disable WebGPU.

• It might be useful to have a note suggesting implementations should surface a warning about power usage at some point, given that this would be permission free.

Again, UA, not spec (guess that's why it says 'note'). Also seems wrong to be WebGPU specfic. Any site can spend lots of battery in JavaScript or complex CSS animations or lots of embedded video or animated SVG. If a UA wants to list battery usage by page, or battery usage / view time, that seems out of scope for WebGPU

• We have since revisited our position on permissions based on this data. Based on some informal asking around non-technical folks, the terms "graphics" is too generic and users will likely be confused - e.g. “yes, I guess the website needs graphics” when it is actually trying to mine Ethereum. For these reasons, gating behind a permission might not be adequate; but it might be useful to add a note (implementation detail) which allows users to revoke access (or kill it) if an application is hogging the GPU. (this would be analogous to the "this tab is hanging" dialog)

Again, this seeems a UA level thing, not a spec thing (again, I guess it's just suggesting a 'note')?

[kdashg]

I filed issues for the first three, which are the ones that sound actionable for us: #2945 #2946 #2947

[Kangz]

Closing since there are more granular issues now.