Note that WebGPU's concept of invalid objects is where a bunch of its innovation budget is, and different compared to all the other Javascript APIs (except some similarities with WebGL) so I expect you'll want to take a detailed look at it.

Hi @Kangz thanks for bearing with us as we get a review going on this. It's a dense piece of work so any further steer you have on what you would like us to particularly look at would be great. Appreciate the thoroughness of the review request especially responses to the Security & Privacy questionnaire.

@torgo Of course, we understand it's a huge API :) Are you looking for pointers to content covered by the explainer, or to content in the spec that is not covered by the explainer?

The items discussed by the explainer are the ones that we thought would be of greatest interest, both in terms of design scrutiny and for understanding the API at a high level. It's hopefully organized in such a way that you can skip over details as needed to make it more digestible.

Of course there are a lot of aspects of the API that are not touched upon by the explainer, but for the most part these are highly domain-specific designs that are constrained by the shape of underlying native APIs, where we don't have that much design freedom. And there's a huge volume of these, so they are hard to summarize in an explainer.

I haven't had enough time to dive deep into the spec, but here are some questions after giving it a quick first-pass.

1. Lots of strings in the API is USVString - feels like DOMString would be more appropriate, is there something I'm missing?
2. Given the power of the API, would it make sense to consider gating this behind a permission? I believe the counter argument is - why should this be behind a permission when WebGL is not, and I think WebGL was an unfortunate choice given how it is being abused to fingerprint users. (Also, I sense crypto miners would love to abuse this...)
3. Should the cache be origin-gated? If the compilation is incredibly fast this shouldn't be an issue, but with slow enough compilation times timing-based fingerprinting feels like it would be possible.
4. Is there a story for mitigating denial-of-service by exhausting VRAM? (Technically, I guess it won't be a denial of service, but more of a "new tabs paint crazy slow" from an end-user perspective.)

2. Given the power of the API, would it make sense to consider gating this behind a permission? I believe the counter argument is - why should this be behind a permission when WebGL is not, and I think WebGL was an unfortunate choice given how it is being abused to fingerprint users. (Also, I sense crypto miners would love to abuse this...)

There's also the WebGL argument, but also that having permission-less access to at list the basic features of WebGPU is generally useful. More and more websites are showing 3D content and it would add a lot of friction to ask for a permission just to show this content. (use cases are online shops, journal/blog articles, ads, company websites, fancy backgrounds, etc). With the structure of the API, the browser should have a lot of choice in how it exposes WebGPU depending on the context of the page (how much the user interacts with it, iframe vs not, etc).

I'm not an expert on fingerprinting but AFAIK WebGL fingerprinting (outside the renderer string) is somewhat equivalent to the 2D-canvas fingerprinting. WebGPU should be the same. Likewise crypto-mining abuse is already available with JS/WASM/WebGL and WebGPU shouldn't make it that much more efficient than WebGL AFAIK so browsers should develop/are developing means to detect abuse.

3. Should the cache be origin-gated? If the compilation is incredibly fast this shouldn't be an issue, but with slow enough compilation times timing-based fingerprinting feels like it would be possible.

These caches should be origin-gated, and are listed in https://github.com/privacycg/storage-partitioning

4. Is there a story for mitigating denial-of-service by exhausting VRAM? (Technically, I guess it won't be a denial of service, but more of a "new tabs paint crazy slow" from an end-user perspective.)

The browsers could track VRAM usage on the GPU process, decide on quotas if needed and "lose the device" if they needs to reclaim quota. It's easy to VRAM denial-of-service via other means too (like 2D canvas, but also many stacked GPU-accelerated DOM layer with stuff like will-animate etc).

• Lots of strings in the API is USVString - feels like DOMString would be more appropriate, is there something I'm missing?

Good question. This was a deliberate decision in the places where we used it:

• All of the debug strings (GPUObjectBase/label, GPUObjectDescriptorBase/label, pushDebugGroup/groupLabel, insertDebugMarker/markerLabel) may optionally be passed down to the GPU driver to enhance the debugging experience for developers running specialized GPU debugging tools against the browser. Implementations which choose to do this would presumably perform some further sanitization on these strings before passing them, but nonetheless invalid unicode strings don't make sense - at least some drivers would take UTF-8 (or maybe ASCII) to drivers.
• Shader code (GPUShaderModuleDescriptor/code, GPUProgrammableStage/entryPoint) is processed as a unicode string by WGSL, so a restriction is needed here as well. In practice, implementations are likely to do that processing in UTF-8, and this also enables that. Once again however, there is still a requirement to handle certain other edge cases (like \0, filed https://github.com/gpuweb/gpuweb/issues/1816)

It was discussed in https://github.com/gpuweb/gpuweb/issues/784

It's a dense piece of work so any further steer you have on what you would like us to particularly look at would be great.

We talked about this further and here are the explainer sections that I think you should focus on:

• Introduction
• Additional Background
• Adapters and Devices intro section
• Optional Capabilities: important because it exposes hardware differences.
• Object Validity and Destroyed-ness: important because it introduces a new error mechanism to the platform.
• Errors intro section, Problems and Solutions intro section, rest as interested.
• Buffer Mapping intro section, rest as interested.
• Multithreading: eventually important, but not urgent because not part of MVP.
• Image, Video, and Canvas input, Canvas Output: if interested in these topics.
• Bitflags: optional, a small peculiarity in the JS API.

I'm not specifically aware of any important items that are in the spec but not in the explainer. (If I were, I'd have written an explainer section on them :) However, I could be forgetting something.)

Hey all, any progress on the review for WebGPU and WGSL? We are making significant progress in the group towards a first version of WebGPU and would like to incorporate feedback from the TAG early if possible.

For info, we've announced an origin trial in Chrome 94. See https://twitter.com/ChromiumDev/status/1432257883912216577 and https://web.dev/gpu/

A particular issue here where the specification is departing from web API design best practices is https://github.com/gpuweb/gpuweb/issues/244 ; that might be worth looking into.

Hey all, any progress on this review? I know it's a big chunk of work, but all browsers are actively implementing the spec now and looking forward to ship, so it would be nice to make changes based on TAG feedback earlier than later.

This is a very nice explainer and it is quite clear that you have put a lot of effort into this and it really shows! @cynthia and I discussed in our breakout that as this has more raw access to the GPU, what is the mitigation in place to make sure this doesn't negatively affect other GPU intensive apps, like the browser itself or the host OS?

If you have a misbehaving web app, how is this handled? For CPU in Chrome today there is infinite loop detection and the tab can be closed, but GPU can affect the whole system and not just a single tab.

I have some follow-up comments and questions on this which I will post before our VF2F is over, but overall we are happy with what is being proposed.

I have some follow-up comments and questions on this which I will post before our VF2F is over, but overall we are happy with what is being proposed.

Thank you, looking forward to your comments!

what is the mitigation in place to make sure this doesn't negatively affect other GPU intensive apps, like the browser itself or the host OS?

Preemption of GPU workloads is not a ubiquitous feature and even GPU that support preemption have it for different levels of granularity. So it's impossible to completely prevent denial of service of the GPU. However OSes have mechanisms to reset the GPU if it is unresponsive for a while, like Windows' TDR mechanism. From applications point of view they "lose" the GPU. While a rare event, it is not exceptional and other applications should handle it correctly (external GPUs can be unplugged for example).

Browsers can also detect when the GPU is occupied for too long. Chromium has a "watchdog" mechanism that triggers when GPU execution takes too long, and will restart the GPU process in that case as an attempt to free resources. It will also give a "strike" to the responsible origin. After some strikes the origin can be blocklisted from using the GPU.

Note that denial of service of the GPU is not something unique to WebGPU. It is trivial to do so with a while(true){} in a WebGL shader and also possible by creating massive GPU workloads with <canvas> or the DOM (with lots of overdraw of filtered layers for example).

@cynthia you mentioned you'd post questions after the VF2F is over, do you have a list that the WebGPU group can look at?

Sorry to ping again, but this review has been open for 9 month already. TAG review is the most important of the horizontal reviews for WebGPU (PING comes close, others are mostly N/A). Implementations are well under way so getting feedback soon would help reduce the risk of needing to do late API changes.

Pinging again. This review has been open for 11 months now. We're getting ever closer to a shippable API and really need your review. We're supposed to wait for TAG review to move WebGPU to candidate recommendation but it can't be blocked on TAG review forever considering the lead time, reminders and detailed explainers.

So please, give us some feedback, or let's figure out a way to help you review WebGPU (via more explainers, walkthroughs with group members, etc).

Sorry for the delayed turnaround. We had this scheduled for our F2F but looking at the minutes it looks like we didn't have enough time to look into that during the breakout where it was supposed to happen. Will discuss within the group and try to provide some closure on this before the F2F finishes.

It is now the one year birthday of this request for a TAG review, and there is still no official feedback that has been provided.

• Some TAG members did look at the API and provided feedback out of band, but it doesn't replace the official review.
• WebGPU is a large and complex API, but the CG/WG members provided detailed explainers and have always been available to write more or answer questions directly.
• We were told the TAG review queue could be month long and that the group should be patient, but it's been a year, multiple reminders after the 6th month and WebGPU is still getting moved from milestone to milestone.

We're trying to finish the first version of the WebGPU API and go to CR. We're supposed to wait for horizontal reviews but blocking indefinitely on the TAG is not okay. If feedback from the TAG comes before CR then we'll try to address it, but if it doesn't, then we'll have to do without.

My suggestion for handling large APIs like WebGPU in the TAG is to ask the groups which parts of the API are most "at risk" of receiving feedback and do partial reviews for each of these parts. Trying to make one full review for the full API can be too high a commitment for TAG members, and might not be a good use of their time. Especially when some details (in the case of WebGPU) are purely technical and internal, without any interaction with the user or the rest of the Web platform.

Ping again :)

Apologies for the delay. The review itself is complete on our end, but got delayed due to other internal discussions. The TL:DR; summary is that while we have not been able to deeply investigate the detailed utility/risks due to the size of the spec, the overall impression is that we think this work shows a lot of promise and is a definite improvement over the status quo (WebGL).

Here are some comments that came up during the review:

• 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: USVString vs DOMString - 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.

Thank you for posting this! I'm glad that the TAG is overall satisfied with the current spec. Copied this feedback in a new issue (https://github.com/gpuweb/gpuweb/issues/2927) so that the WebGPU group can discuss it and come back to the TAG.

Thanks for bringing the feedback to the group, and apologies this took so long.