Hey Alex, Thank you for your answer and the example of where TAG was able to bring alignment to various APIs.
I think what makes the situation difficult here is that WebGPU is a very active specification that gains new minor features or developer visible improvements monthly, if not more often (we have two lined up for M131 already). At the same time WebGPU is to use an "eternal CR" (living spec) model which means that snapshots are done ~yearly (or twice a year). Browsers will want to enable features faster than that cadence which will make CR snapshots less malleable than I think you'd like if the TAG comes back with substantial feedback on the snapshot. I hope Jeff will find a low-friction way to send FYIs to the TAG. Even looking at the early-review template, it seems like it will be a lot of overhead for contributors (need for a TAG-readable explainer, privacy and security, impl status, and more). We could set them up with templates on how to file the issue, but it would be more boilerplate-y than actually useful for the TAG, so it's not a great solution either. It seems that there is a risk-effort curve for the interactions with the TAG but no process for the very low risk/effort part of it yet. Cheers, Corentin On Wed, Sep 4, 2024 at 6:04 PM Alex Russell <slightly...@chromium.org> wrote: > Hey Corentin, > > Thanks for the thoughtful note on TAG engagement. > > The idea here isn't that the TAG will provide deep guidance about your > design regarding GPU features -- y'all are the GPU experts! -- the general > pattern here is the TAG helps to nudge groups to align with patterns it is > seeing across web APIs to the extent that they make sense for your domain. > A good example of this is the broad retrofitting of the platform we've > accomplished to enable Promises in async DOM APIs. There is admittedly a > big difference in our preference for TAG review in areas that are working > well vs. those that have a history of unforced API design errors, but > that's hard to codify in the API OWNERS process. I do agree that your hoped > for work mode is ideal, but it depends on the snapshots still being > malleable at the moment you get design feedback, which seems unlikely if > we're talking about CRs. > > If we aren't getting good or valuable feedback, or if the TAG isn't doing > what we assume they're doing (reaching out to discuss proposed designs when > you file early reviews and providing detailed design feedback to help > improve your APIs and layering), then we should have a larger conversation > at BlinkOn about how and why we're making everyone engage here. > > Jeff is going to reach out to the rest of the TAG to clarify FYI filings, > but the general pattern has been to just file an issue with a note at the > top that something *is* being sent for their visibility. If they come back > to us and would prefer we didn't, I promise to stop nagging ;-) > > Thanks again for raising this friction point. We know it's work, and the > juice needs to be worth the squeeze. Let's keep discussing. > > Best, > > Alex > > > > On Monday, September 2, 2024 at 5:37:27 AM UTC-7 Corentin Wallez wrote: > >> Hey all, >> >> Thank you for the LGTMs. >> >> >> *Finch flag* >> I think there is a misunderstanding about this Finch flag: the flag is >> meant to contain a list of comma-separated GPUFeatureNames that are >> disabled on the GPU process side (which is then reflected in Blink). So it >> is a general mechanism to disable any optional WebGPU feature, including, >> but not limited to dual source blending. >> >> For the flag's name, we can easily rename it as no Finch config uses it >> at the moment. The WebGPU team called it "Unsafe" as it is meant to >> remotely disable features that we discover are unsafe for a reason or >> another after shipping. (think of a terrible in the wild exploit that we >> want to prevent immediately, or random crashes on end user machines). >> >> >> *TAG* >> We already had a discussion >> <https://docs.google.com/document/d/1i3w92xOKblwv-bzCIMW7OlEnps5fIKMzy1uRlYLea8c> >> about reviews for minor WebGPU features, though it doesn't seem to mention >> the TAG (I misremembered earlier this thread) so I think we should discuss >> it now! >> >> What do we expect the benefits of adding the TAG to the process of >> launching minor WebGPU features? The TAG review for WebGPU >> <https://github.com/w3ctag/design-reviews/issues/626> was excessively >> long and didn't give much actionable feedback. This is understandable given >> how large and how domain-specific WebGPU is, but likewise for 95% of WebGPU >> features we expect no actionable feedback, so we'd just be adding noise to >> the TAG's queue and wasting their time. >> >> The WebGPU group (composed of Apple, Google, and Mozilla folks) is aiming >> to reach CR by the end of the year, and to pursue a living spec with >> regular (1-2 per year) CR snapshots afterwards. The process for CR triggers >> horizontal reviews which I assume would include the TAG? This way they >> would get a general FYI each CR snapshot. As noted earlier in the thread, >> we would proactively look for a TAG review on features that aren't trivial >> or completely domain-specific, where we believe there is a chance of >> actionable feedback. The vast majority of features are minor in this way, >> but as mentioned earlier we have several future features that we believe >> might be of interest to TAG. >> >> Judging by the Github templates, the TAG has no mechanism for sending >> FYIs, only early (which this is not) and full reviews. A full TAG is a >> disproportionate amount of effort for minor features even if we made >> helpful templates for contributors for all the documents required. Any >> additional process involving the TAG would be gratuitous effort and >> friction for WebGPU contributors, but full reviews extremely so. >> >> For the WebGPU team and contributors, adding the TAG to the launch >> process for every feature would add significant friction, when many >> contributors are already shying away from doing the I2S process due to the >> perceived amount of bureaucracy required (for example Francois filed this >> I2S on behalf of Jiawei). >> >> In summary, WebGPU rolling CR snapshots, and proactive reviews with the >> TAG on the few topics that matter should be sufficient while keeping the >> process relatively lightweight. >> >> Cheers, >> >> Corentin >> >> On Wed, Aug 28, 2024 at 6:08 PM Daniel Bratell <bratel...@gmail.com> >> wrote: >> >>> LGTM3 (after two LGTM1s from Alex and Yoav). >>> >>> The finch flag is just a followup on Domenic's question. It seems the >>> issue is that the documented flag doesn't actually correspond to the on-off >>> switch for this feature so please update the finch flag documentation to >>> reflect the correct switch. Just in case this will need emergency surgery. >>> >>> There is a discussion to be had about TAG reviews for minor WebGPU >>> features. By the book this should probably have had one, but I'm not sure >>> anyone would have benefited from such a request so it's probably the book >>> that needs updating. Also see Alex' comment below. >>> >>> /Daniel >>> >>> On 2024-08-28 18:00, Alex Russell wrote: >>> >>> Hey folks, >>> >>> LGTM1 with nits. First, it would be good for y'all to FYI this to the >>> TAG, even if you don't block on review. I agree it's small and would wave >>> it through. I know Daniel has questions about the Finch flag name, so would >>> be good to have those sorted before this goes out too. >>> >>> Thanks, >>> >>> Alex >>> >>> On Wednesday, August 28, 2024 at 5:02:13 AM UTC-7 Corentin Wallez wrote: >>> >>>> On Wed, Aug 28, 2024 at 12:36 PM Yoav Weiss (@Shopify) < >>>> yoavwe...@chromium.org> wrote: >>>> >>>>> LGTM1 >>>>> >>>>> On Fri, Aug 23, 2024 at 2:46 PM 'François Beaufort' via blink-dev < >>>>> blink-dev@chromium.org> wrote: >>>>> >>>>>> Adding +Corentin Wallez <cwal...@google.com> to the thread >>>>>> >>>>>> On Fri, Aug 23, 2024 at 2:29 PM François Beaufort < >>>>>> fbeauf...@google.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 23, 2024 at 7:01 AM Domenic Denicola < >>>>>>> dome...@chromium.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Aug 22, 2024 at 9:13 PM 'François Beaufort' via blink-dev < >>>>>>>> blink-dev@chromium.org> wrote: >>>>>>>> >>>>>>>>> Contact emails >>>>>>>>> >>>>>>>>> fbeauf...@google.com >>>>>>>>> >>>>>>>>> Explainer >>>>>>>>> >>>>>>>>> The “dual-source-blending” GPU feature adds additional blend >>>>>>>>> factors and the WGSL @blend_src attribute to allow a fragment shader >>>>>>>>> to >>>>>>>>> blend two color outputs into a single output buffer. >>>>>>>>> https://github.com/gpuweb/gpuweb/pull/4621 >>>>>>>>> >>>>>>>>> Specification >>>>>>>>> >>>>>>>>> >>>>>>>>> https://gpuweb.github.io/gpuweb/#dom-gpufeaturename-dual-source-blending >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> Functionality added to the WebGPU spec after its first shipment in >>>>>>>>> a browser. >>>>>>>>> >>>>>>>>> Adds the optional GPU feature “dual-source-blending” that enables >>>>>>>>> combining two fragment shader outputs into a single framebuffer. This >>>>>>>>> technique is particularly useful for applications that require complex >>>>>>>>> blending operations, such as those based on Porter-Duff blend modes. >>>>>>>>> By >>>>>>>>> reducing the need for frequent pipeline state object changes, dual >>>>>>>>> source >>>>>>>>> blending can enhance performance and flexibility. >>>>>>>>> >>>>>>>>> Blink component >>>>>>>>> >>>>>>>>> Blink>WebGPU >>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebGPU> >>>>>>>>> >>>>>>>>> TAG review >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> TAG review status >>>>>>>>> >>>>>>>>> Not applicable >>>>>>>>> >>>>>>>> >>>>>>>> I can't figure out which exception >>>>>>>> <https://www.chromium.org/blink/guidelines/api-owners/process-exceptions/> >>>>>>>> this would fall under. Can you help explain why TAG review is not >>>>>>>> applicable here? >>>>>>>> >>>>>>> >>>>>>> Back in October 2023, Corentin Wallez, the WebGPU Tech Lead, met >>>>>>> with the Blink API owners to address the process for releasing WebGPU >>>>>>> features following their inclusion in Chromium. It was mutually agreed >>>>>>> that >>>>>>> requesting TAG reviews for minor features would be unnecessary. This >>>>>>> policy >>>>>>> applied to all features added at the time. See >>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/search?q=%22tag%20review%22%20subject%3Awebgpu >>>>>>> >>>>>> >>>>> I may misremember, but I thought we discussed adding a "levels" >>>>> designation to WebGPU additions that would enable us to create such >>>>> bypasses for vendor signals and TAG reviews. Did that actually happen? If >>>>> so, did we make any progress on that? >>>>> >>>>> In any case, I agree this is a small addition in which I wouldn't >>>>> expect the TAG to have meaningful feedback over the one already provided >>>>> by >>>>> the domain experts at the WebGPU group. >>>>> >>>>> We discussed that some larger additions to WebGPU would still request >>>> a TAG review, one of which would be the addition of a compatibility >>>> mode >>>> <https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md> >>>> or >>>> feature level mechanism for WebGPU (whichever the WebGPU group gets to >>>> consensus on). We are still making progress on that one, and don't have >>>> other large features being developed yet (only smaller, GPU-specific >>>> additions for now). Other features that could warrant TAG review would be >>>> bindless / ray tracing (though it's mostly GPU specific), multithreading >>>> support, and maybe interoperation with other Web APIs like canvas >>>> <https://github.com/fserb/canvas2D/blob/master/spec/webgpu.md> (and canvas >>>> shaders <https://github.com/fserb/canvas2D/blob/master/spec/shaders.md>), >>>> or WebNN <https://github.com/webmachinelearning/webnn/issues/688>. >>>> >>>> >>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> This feature has not yet been implemented in any browser. It has >>>>>>>>> been approved by the GPU for the Web Community Group, with >>>>>>>>> representatives >>>>>>>>> from Chrome, Firefox, and Safari. See minutes at >>>>>>>>> https://github.com/gpuweb/gpuweb/wiki/GPU-Web-2024-05-29#add-optional-feature-dual_source_blending-4621 >>>>>>>>> >>>>>>>>> Gecko: No signal (Mozilla members have approved >>>>>>>>> https://github.com/gpuweb/gpuweb/pull/4621 and requested during >>>>>>>>> weekly standardization meetings that we postpone filing standard >>>>>>>>> positions >>>>>>>>> until we reach Candidate Recommendation (CR) status in Q4.) >>>>>>>>> >>>>>>>>> WebKit: Positive ( >>>>>>>>> https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933 >>>>>>>>> ) >>>>>>>>> >>>>>>>>> Web developers: Positive ( >>>>>>>>> https://github.com/gpuweb/gpuweb/issues/4283) >>>>>>>>> >>>>>>>>> Other signals: >>>>>>>>> >>>>>>>>> WebView application risks >>>>>>>>> >>>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>> applications? >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> >>>>>>>>> Debuggability >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> >>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>>>>> >>>>>>>>> No >>>>>>>>> >>>>>>>>> All platforms will eventually have support. Will immediately be >>>>>>>>> available on Android, Android WebView, ChromeOS, Mac, and Windows, >>>>>>>>> since >>>>>>>>> those platforms already support WebGPU. Linux is planned to have >>>>>>>>> WebGPU >>>>>>>>> support in the future, so this feature will become available when >>>>>>>>> WebGPU >>>>>>>>> does. >>>>>>>>> >>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> Yes. See https://github.com/gpuweb/cts/issues/3810 >>>>>>>>> >>>>>>>>> WebGPU/WGSL have a conformance test suite ( >>>>>>>>> https://github.com/gpuweb/cts) that is regularly pulled into >>>>>>>>> Chromium and part of the testing of Dawn/Tint in Chromium. >>>>>>>>> >>>>>>>> >>>>>>>> But, it is not tested by web platform tests themselves, right? >>>>>>>> https://github.com/web-platform-tests/wpt/tree/master/webgpu seems >>>>>>>> to not contain any tests for this feature. >>>>>>>> >>>>>>>> (This does not block shipping, but rather is just a request to >>>>>>>> improve the accuracy of your Chrome Platform Status entry.) >>>>>>>> >>>>>>> >>>>>>> As you can see in >>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/search?q=cts%20web-platform-tests%20subject%3Awebgpu, >>>>>>> we’ve always replied “Yes” to this question. The WebGPU/WGSL conformance >>>>>>> test suite (https://github.com/gpuweb/cts) is not used only by >>>>>>> Chromium. Other engines, like WebKit and Gecko, also rely on this test >>>>>>> suite to ensure their implementation aligns with the WebGPU >>>>>>> specification. >>>>>>> This test suite can be exported to WPT and we use that export for a >>>>>>> subset of tests in Chromium for reftests: >>>>>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/webgpu/ >>>>>>> The rest of the tests are executed with a different harness in >>>>>>> Chromium for better speed and test result granularity. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Flag name on chrome://flags >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> Finch feature name >>>>>>>>> >>>>>>>>> WebGPU.Enabled:UnsafeFeatures >>>>>>>>> >>>>>>>> >>>>>>>> This Finch feature name is a bit scary. Does it actually allow >>>>>>>> unshipping only this new feature? It sounds rather general. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> It does allow disabling specific GPU features such as >>>>>>> FeatureName::DualSourceBlending, but also FeatureName::Subgroups, etc. >>>>>>> See >>>>>>> https://source.chromium.org/chromium/chromium/src/+/main:gpu/config/gpu_finch_features.cc;l=275;drc=168a59b6bada5b30a6f2390c22a6177216b17e4d >>>>>>> . >>>>>>> If it really matters, we could rename the Finch feature name to >>>>>>> WebGPU.Enabled:BlocklistFeatures to better reflect the meaning. >>>>>>> >>>>>>> >>>>>>>>> Requires code in //chrome? >>>>>>>>> >>>>>>>>> False >>>>>>>>> >>>>>>>>> Tracking bug >>>>>>>>> >>>>>>>>> https://issues.chromium.org/issues/341973423 >>>>>>>>> >>>>>>>>> Estimated milestones >>>>>>>>> >>>>>>>>> DevTrial on desktop >>>>>>>>> >>>>>>>>> 129 >>>>>>>>> >>>>>>>>> DevTrial on Android >>>>>>>>> >>>>>>>>> 129 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Anticipated spec changes >>>>>>>>> >>>>>>>>> Open questions about a feature may be a source of future web >>>>>>>>> compat or interop issues. Please list open issues (e.g. links to known >>>>>>>>> github issues in the project for the feature specification) whose >>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing to >>>>>>>>> naming >>>>>>>>> or structure of the API in a non-backward-compatible way). >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> >>>>>>>>> https://chromestatus.com/feature/5167711051841536 >>>>>>>>> >>>>>>>>> >>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>> <https://chromestatus.com/>. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "blink-dev" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to blink-dev+unsubscr...@chromium.org. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5LYcjs9iaFmzLZ%2BtorNvAQ0no4SSxGAm6ZJ62NONiASNA%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5LYcjs9iaFmzLZ%2BtorNvAQ0no4SSxGAm6ZJ62NONiASNA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "blink-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to blink-dev+unsubscr...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5L5XPV4Z9amhPMP8819GR_WtDOS2pwN2iph_bLOKoCZoQ%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5L5XPV4Z9amhPMP8819GR_WtDOS2pwN2iph_bLOKoCZoQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ad26c92d-a28a-4ed2-9f95-17b02439f276n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ad26c92d-a28a-4ed2-9f95-17b02439f276n%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGdfWNPwFZ5O6q%2BHKtBT%3DK09bRqeGiwzyUhU-MkVREo7jo3u%3Dg%40mail.gmail.com.
