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.
