Would the libraries using maxInterStageShaderComponents (from Mike's github link) "break" when accessed? I'm guessing since nobody seems to be calling them, it should be fine and 2 milestones should be enough to find deprecation warnings.
LGTM3 On Thu, Nov 21, 2024 at 12:16 PM Mike Taylor <miketa...@chromium.org> wrote: > LGTM2 > On 11/21/24 2:02 AM, François Beaufort wrote: > > Oh! I've set the appropriate status Thank you! > > On Wed, Nov 20, 2024 at 5:46 PM Daniel Bratell <bratel...@gmail.com> > wrote: > >> There is an API Owner dashboard in Chromestatus showing everything that >> has an "intent to ship" but is not yet approved (or rejected), and this one >> doesn't show up there which also means that I cannot record the LGTM1 >> >> I'm not absolutely sure how to get it there since I'm on the other end, >> but it should be the steps listed on >> https://www.chromium.org/blink/launching-features/ under "Feature >> Deprecations" -> "Step 6: Prepare to Ship". >> >> /Daniel >> On 2024-11-20 17:22, François Beaufort wrote: >> >> I can see it in the "Chrome 133" column from >> https://chromestatus.com/roadmap >> What do you see? >> >> On Wed, Nov 20, 2024 at 4:12 PM Daniel Bratell <bratel...@gmail.com> >> wrote: >> >>> Note, this doesn't show up as "intent to ship (deprecate/remove)" in >>> chromestatus so there is probably some buttons you need to press there. >>> >>> /Daniel >>> On 2024-11-20 15:58, Daniel Bratell wrote: >>> >>> LGTM1 to deprecate now with full removal in M135. The amount of >>> fingerprinting/tracking scripts that access this is scarily high but I >>> trust those to be suitably robust. >>> >>> /Daniel >>> On 2024-11-20 08:13, 'François Beaufort' via blink-dev wrote: >>> >>> >>> >>> >>> On Wed, Nov 20, 2024 at 4:07 AM Mike Taylor <miketa...@chromium.org> >>> wrote: >>> >>>> >>>> On 11/19/24 11:55 AM, François Beaufort wrote: >>>> >>>> Thanks for the review Mike! >>>> >>>> On Tue, Nov 19, 2024 at 5:30 PM Mike Taylor <miketa...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> On 11/19/24 5:21 AM, 'François Beaufort' via blink-dev wrote: >>>>> >>>>> Contact emails >>>>> >>>>> fbeauf...@google.com >>>>> >>>>> Explainer >>>>> >>>>> The maxInterStageShaderComponents limit is being removed due to a >>>>> combination of factors: >>>>> >>>>> - Redundancy with maxInterStageShaderVariables: This limit already >>>>> serves a similar purpose, controlling the amount of data passed between >>>>> shader stages. >>>>> >>>>> - Minor discrepancies: While there are slight differences in how the >>>>> two limits are calculated, these differences are minor and can be >>>>> effectively managed within the maxInterStageShaderVariables limit. >>>>> >>>>> - Simplification: Removing maxInterStageShaderComponents streamlines >>>>> the shader interface and reduces complexity for developers. Instead of >>>>> managing two separate limits with subtle differences, they can focus on >>>>> the >>>>> more appropriately named and comprehensive maxInterStageShaderVariables. >>>>> >>>>> https://github.com/gpuweb/gpuweb/pull/4783 >>>>> >>>>> Specification >>>>> >>>>> >>>>> https://gpuweb.github.io/gpuweb/#dom-supported-limits-maxinterstageshadervariables >>>>> >>>>> Summary >>>>> >>>>> Removes the maxInterStageShaderComponents limit from WebGPU, which has >>>>> been deemed to be unnecessary. This removal is a minor breaking change. >>>>> >>>>> Blink component >>>>> >>>>> Blink>WebGPU >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebGPU> >>>>> >>>>> Motivation >>>>> >>>>> Removing maxInterStageShaderComponents eliminates unnecessary >>>>> complexity and potential confusion by consolidating the functionality >>>>> within the existing maxInterStageShaderVariables limit. This change >>>>> promotes cleaner code and a more intuitive development experience. >>>>> >>>>> To clarify, are you requesting to deprecate this for some period of >>>>> time (if so, I don't see a deprecation plan), and then come back to >>>>> remove? >>>>> Or just remove it in M133? >>>>> >>>> >>>> This intent is for deprecating this limit for some period of time to >>>> give developers enough time to migrate and eventually remove it. >>>> >>>> Thanks François - so what is the plan? If we send a deprecation message >>>> - how long do you think doing so would be effective? >>>> >>> >>> Regarding the deprecation plan, I suggest the following timeline as >>> we're anticipating Safari and Firefox to soon support WebGPU : >>> - 133: Deprecation warnings begin, recommending the use of the >>> maxInterStageShaderVariables limit instead. >>> - 135: Effective removal of the maxInterStageShaderComponents limit. >>> >>>> >>>>> A search for the string "maxInterStageShaderComponents" in HTTPArchive >>>>> yielded no results. >>>>> >>>>> There does seem to be non-test code calling this when poking around >>>>> https://github.com/search?q=maxInterStageShaderComponents+language%3AJavaScript&type=code&l=JavaScript. >>>>> Have you looked at that yet? >>>>> >>>> >>>> Yes. Those are mostly libraries that handle getting >>>> the maxInterStageShaderComponents limit, but not "real" apps actually >>>> requiring the limit when the limit is not high enough for their use case. >>>> >>>>> >>>>> As of November 16th, 2024, usage of the maxInterStageShaderComponents >>>>> limit within GPUAdapter and GPUDevice reached a peak of 0.3163% of page >>>>> loads. Additionally, its usage in requiredLimits when called through >>>>> requestDevice reached 0.0004% on the same day. These metrics are tracked >>>>> in >>>>> the ChromeStatus dashboard through >>>>> https://chromestatus.com/metrics/feature/timeline/popularity/5110 and >>>>> https://chromestatus.com/metrics/feature/timeline/popularity/5111. >>>>> >>>>> Can you help a non-expert understand the difference between these two >>>>> metrics? ~0.32% is quite high. >>>>> >>>> >>>> The first one happens when a web app calls the GPUSupportedLimits >>>> attribute getter adapter.limits.maxInterStageShaderComponents for instance. >>>> The high usage is due to scripts using this for analytics/bot >>>> protection/fingerprinting. >>>> The second one is the one we care the most. It is web apps that >>>> actually require a maxInterStageShaderComponents GPU limit when requesting >>>> a GPU device. We don't want to break those, and that's why we'll add >>>> deprecation warnings so that they can use the maxInterStageShaderVariables >>>> limit instead. >>>> >>>> Also, what about https://github.com/gpuweb/gpuweb/pull/4781 - do we >>>>> ship this behavior in Chromium? >>>>> >>>> I'm actually working on this as we speak. It's not in Chromium yet. >>>> >>>>> >>>>> >>>>> Initial public proposal >>>>> >>>>> None >>>>> >>>>> TAG review >>>>> >>>>> None >>>>> >>>>> TAG review status >>>>> >>>>> Not applicable as we're simply removing a WebGPU limit. >>>>> >>>>> Risks >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> When WebGPU eventually launches in Safari and Firefox, websites will >>>>> use exclusively the maxInterStageShaderVariables limit. >>>>> >>>>> We anticipate Safari and Firefox will soon support WebGPU, but won't >>>>> include the non-standard maxInterStageShaderComponents limit. Therefore, >>>>> the sooner Chromium implements the Deprecate and Remove process, the less >>>>> likely it is that content will work in Chromium but not in other browsers. >>>>> >>>>> Gecko: No signal - Firefox representative agreed during team meeting >>>>> to remove the limit from the spec: >>>>> https://github.com/gpuweb/gpuweb/wiki/GPU-Web-2024-08-28#added-late-ok-to-defer-if-necessary-maxinterstageshadercomponents-seems-to-overlap-with-maxinterstageshadervariables-4688 >>>>> >>>>> WebKit: No signal Apple representative strongly suggested removing >>>>> the limit from the spec: >>>>> https://github.com/gpuweb/gpuweb/issues/4688#issuecomment-2218446444 >>>>> >>>>> Web developers: No signals >>>>> >>>>> 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 >>>>> >>>>> Flag name on chrome://flags >>>>> >>>>> None >>>>> >>>>> Finch feature name >>>>> >>>>> WebGPUMaxInterStageShaderComponentsLimit >>>>> >>>>> Non-finch justification >>>>> >>>>> None >>>>> >>>>> Requires code in //chrome? >>>>> >>>>> False >>>>> >>>>> Tracking bug >>>>> >>>>> https://issues.chromium.org/issues/364338810 >>>>> >>>>> Estimated milestones >>>>> >>>>> Shipping on desktop >>>>> >>>>> 133 >>>>> >>>>> Shipping on Android >>>>> >>>>> 133 >>>>> >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/4853767735083008?gate=5110989125844992 >>>>> >>>>> 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 visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5Kmb-sNm70ox0xRp5raXxAVBb%2BtJ_AanGJYv47Ysobt9Q%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5Kmb-sNm70ox0xRp5raXxAVBb%2BtJ_AanGJYv47Ysobt9Q%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 visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5LiZYCFsstHg%2BAvmd9o8paF_7nLVD_kFb45Hf4QOxauCA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5LiZYCFsstHg%2BAvmd9o8paF_7nLVD_kFb45Hf4QOxauCA%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 visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/07aa7ef6-83ba-49a2-abd8-607e5bd33c7a%40gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/07aa7ef6-83ba-49a2-abd8-607e5bd33c7a%40gmail.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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/36461972-9e22-42e1-bc14-2a0698eab83e%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/36461972-9e22-42e1-bc14-2a0698eab83e%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P2hrVdC9JsR%2B8YDPwZpoxU_sheRE8FEjv7xWjFY0ELhA%40mail.gmail.com.
