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 <mailto: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
<https://github.com/gpuweb/gpuweb/pull/4783>
Specification
https://gpuweb.github.io/gpuweb/#dom-supported-limits-maxinterstageshadervariables
<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
<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
<https://chromestatus.com/metrics/feature/timeline/popularity/5110>and
https://chromestatus.com/metrics/feature/timeline/popularity/5111
<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
<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
<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
<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
<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/84204df2-b4f7-4727-b18f-c335e546ed09%40gmail.com.
