Intent to Ship: WebGPU: Clip Distances

[Shao, Jiawei]

Contact emails

jiawe...@intel.com

Explainer

The “clip-distances” GPU feature adds the WGSL built-in variable @builtin(clip_distances) to allow a vertex shader to output user-defined clip distances. https://github.com/gpuweb/gpuweb/pull/4588

Specification

https://gpuweb.github.io/gpuweb/#dom-gpufeaturename-clip-distances

Summary

Adds the optional GPU feature "clip-distances" that allows setting user-defined clip distances in vertex shader outputs. This technique is particularly useful for the applications that need to clip all vertices in a scene that are beyond a user-defined plane, such as many CAD applications.

Blink component

Blink>WebGPU

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

This feature has been approved in W3C GPU for the Web WG meetings including participants from Safari and Firefox. Related meeting minutes: https://github.com/gpuweb/gpuweb/wiki/GPU-Web-2024-05-29#add-optional-feature-clip-distances-if-there-are-new-questions-4588

Gecko: No signal (Mozilla members have approved https://github.com/gpuweb/gpuweb/pull/4588 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/390)

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

Goals for experimentation

Ongoing technical constraints

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, where hardware support is available. 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?

Yes

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. While the CTS can be embedded in WPT, the WebGPU team opted to keep it separate in Chromium testing to use a customized harness for robustness and performance. All the tests about this feature in WebGPU CTS can be found through the below link: https://github.com/gpuweb/cts/issues/3773

Flag name on chrome://flags

None

Finch feature name

WebGPU.Enabled:UnsafeFeatures

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/358408571

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5141929256550400

This intent message was generated by Chrome Platform Status.

 

[Vladimir Levin]

Hey,

Do you mind filing the reviews for other chips:

Thanks!

Vlad

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM4PR11MB623701939A127A3BA2309335ED682%40DM4PR11MB6237.namprd11.prod.outlook.com.

[Jiawei Shao]

Done

[Alex Russell]

Hey Jiawei,

Thanks for filing this intent. It would be good if you opened explicit requests for position from Mozilla. We try not to impute stances based on WG conversations for a lot of reasons, but primarily because other engines have asked us not to.

On TAG review, I agree that this is a small feature that doesn't need additional oversight and alignment, and I'll stand in on this one to say it looks OK.

That said, it would be good to see an Explainer that outlines the value of the feature and how this will be used in real code to solve an important problem. Particularly if there were other alternatives considered.

Also, asking for the TAG to look over something should come well before something lands in spec text, which is why our process recommends you begin that at Intent to Prototype phase. In this case, if you'd reached out when clipping was proposed, you would probably have already produced an explainer and gotten the TAG to indicate that they don't feel they need to review it, saving you time at this step.

Best,

Alex

[Ken Russell]

Hi Alex,

I don't want to speak for Jiawei but would like to provide a little more background. This exposes a GPU hardware feature which allows the application to specify additional clipping planes (in the form of distances from the current vertex to each of those implicitly-specified planes) which apply to geometry being drawn. The WebGPU API abstracts over this hardware functionality, which is exposed by the underlying graphics APIs such as Direct3D, Metal and Vulkan, on top of which WebGPU is implemented.

I have not personally used this functionality, but https://github.com/KhronosGroup/WebGL/issues/3109 captures a discussion which motivated adding a similar extension to WebGL. The hardware feature is faster, and provides higher quality visual results, than attempting to emulate its behavior at the user level, which would generally be done by discarding individual pixels in the fragment shader. https://github.com/gpuweb/gpuweb/issues/390 contains the public discussion adding the feature to WebGPU.

It would be a fair amount of work to write up an explainer for every GPU hardware feature that the WebGPU working group collectively agrees to add either to the core specification or as an optional feature. In this and many other cases there is no alternative to be considered; it's basically either expose the hardware feature, or not.

-Ken

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e10c833-c870-4070-939a-b53b4c764c6an%40chromium.org.

[Alex Russell]

Thanks, Ken. I suspected most of this, but thanks for filling in the background and detail.

Again, I'm happy to let this go forward, just wanted to clarify how this can go more smoothly in the future, particularly re: putting this kind of thing in an Explainer and filing early w/ the TAG.

Best,

Alex

[Yoav Weiss (@Shopify)]

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

LGTM2

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e10c833-c870-4070-939a-b53b4c764c6an%40chromium.org.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4be99bff-1fdb-4778-907d-bc5acb5a07f9n%40chromium.org.

[Alex Russell]

LGTM3, but with some reservations on how the evidence we're using to judge the risk of this has been presented. Because the API OWNERS grok the utility of this feature, we're pulling threads together from GH threads, the intent mail, follow-ups, and the like to get a complete picture. That sort of thing slowed down this I2S, and a small explainer would have gone a long way speeding things along.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e10c833-c870-4070-939a-b53b4c764c6an%40chromium.org.

--
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+unsubscribe@chromium.org.