Apologies, I made an error in the I2S, this is in an attribute in GPUSupportedLimits (an interface), not GPUSupportedFeatures (a set). Hence considering it a breaking change.
We have been considering a request to merge back to M113 but given we can't land on main without LGTM on an I2S, and we can't merge without having landed on main, how would we actually do that? Seek pre-approval to merge I suppose? -Kai (he/they) On Wed, Apr 19, 2023 at 7:48 AM Rick Byers <rby...@chromium.org> wrote: > Given how close we are to M113 stable release, it may be too late for a > merge back. If so, I imagine removal should be pretty low risk and easy but > given all the trouble we've had lately I do think we need to follow the > breaking change process, including putting the changes behind a flag > <https://groups.google.com/a/chromium.org/g/blink-dev/c/jhJLN9drXy4/m/RXCJx0-VCAAJ> > and > either adding metrics, or showing existing UMA evidence that usage is low > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.mqfkui78vo5z>. > It looks like overall WebGPU usage > <https://chromestatus.com/metrics/feature/timeline/popularity/3888> > (mostly beta channel) is already above our "small" threshold, so congrats > on having a popular platform feature which we now have to be very careful > with changing :-) > > Removing maxFragmentCombinedOutputResources from the GPUSupportedFeatures > set is really safe (equivalent to any small behavior change, not an API > contract change), right? I'm OK saying that doesn't require an intent or > breaking change process since the API is just indicating what things are > supported. Also adding a warning that the API will stop working seems fine, > can you please also add a UseCounter so we can gather the data to show it's > safe to remove? > > Thanks, > Rick > > On Wed, Apr 19, 2023 at 3:37 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> >> >> On Tue, Apr 18, 2023 at 8:32 PM Kai Ninomiya <kain...@chromium.org> >> wrote: >> >>> (sending from correct email address this time) >>> Due to the nature of this removal I've elected to send this as an Intent >>> to Ship because we are seeking LGTMs. Please let me know if this is >>> inappropriate. >>> Contact emailskain...@chromium.org >>> >>> Explainerhttps://github.com/gpuweb/gpuweb/issues/4018 >>> >>> Specificationhttps://gpuweb.github.io/gpuweb/#limits >>> >>> Summary >>> >>> Removes the maxFragmentCombinedOutputResources limit from WebGPU, which >>> has been deemed to be unnecessary. This limit applies additional >>> restrictions on use of the WebGPU API, but is being removed from the >>> standard. This removal is a minor breaking change. >>> >>> >>> Blink componentBlink>WebGPU >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebGPU> >>> >>> TAG reviewNone >>> >>> TAG review statusNot applicable >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> Minimal but not zero. There are two changes here: - Remove >>> GPUSupportedFeatures.maxFragmentCombinedOutputResources. - Remove >>> "maxFragmentCombinedOutputResources" as an allowed key in >>> GPUDeviceDescriptor.requiredLimits. Due to the way the API is used, it's >>> very unlikely that anyone is using >>> GPUSupportedFeatures.maxFragmentCombinedOutputResources. It's also >>> unlikely, but possible, that anyone is explicitly passing >>> "maxFragmentCombinedOutputResources" in GPUDeviceDescriptor.requiredLimits. >>> - adapter.requestDevice({ requiredLimits: adapter.limits }). Expected to be >>> common. - adapter.requestDevice({ requiredLimits: { >>> maxFragmentCombinedOutputResources: 12 }}). Expected to be rare. - Code >>> using adapter.limits.maxFragmentCombinedOutputResources. Expected to be >>> extremely rare. Hence the proposal is to *just remove* the >>> GPUSupportedFeatures member but *deprecate then remove* the requiredLimits >>> key. Finally, note WebGPU hasn't reached Chrome Stable yet (it's in M113). >>> The faster we remove this the better, because fewer sites will come to rely >>> on it. We could merge a deprecation back to M113, but didn't think it was >>> probably worthwhile. >>> >> >> If you can merge back the removal to M113, I think it won't count as a >> removal at all, and hence no LGTMs would be necessary. >> So I think that may be the best path, if feasible. >> >> >>> >>> >>> *Gecko*: In development ( >>> https://github.com/gpuweb/gpuweb/wiki/Minutes-2023-04-12#remove-validation-of-maxfragmentcombinedoutputresources-4018) >>> Accepted in standardization meeting >>> >>> *WebKit*: In development ( >>> https://github.com/gpuweb/gpuweb/wiki/Minutes-2023-04-12#remove-validation-of-maxfragmentcombinedoutputresources-4018) >>> Accepted in standardization meeting >>> >>> *Web developers*: No signals >>> >>> *Other signals*: >>> >>> Ergonomics >>> >>> None >>> >>> >>> Activation >>> >>> None >>> >>> >>> Security >>> >>> None >>> >>> >>> 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 >>> >>> Warnings/error messages upon use of the removed limit >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, Android, and Android WebView)?Yes >>> >>> Will affect only Windows and Mac because WebGPU has not shipped yet on >>> other platforms. >>> >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ?No >>> >>> Flag name >>> >>> Requires code in //chrome?False >>> >>> Tracking bughttps://crbug.com/dawn/1756 >>> >>> Estimated milestones >>> Shipping on desktop 114 >>> >>> 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/5182904243585024 >>> >>> Links to previous Intent discussions >>> >>> 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/CANxMeyBMuz0SiW8rUzZBC2n34Gfw0ggrLNwQxfzbfMuhOxArGA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANxMeyBMuz0SiW8rUzZBC2n34Gfw0ggrLNwQxfzbfMuhOxArGA%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/CAL5BFfU%2BF6J-vKZiz%3D3zyTc6L3DDRcg0fRGqtT7pM-bbtAUwSQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU%2BF6J-vKZiz%3D3zyTc6L3DDRcg0fRGqtT7pM-bbtAUwSQ%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/CANxMeyDtoHUqZvn%2B1E3-N_CoVGsSfhLS2p1%2B0c21HvH8xmxMZw%40mail.gmail.com.
