Intent to Ship: WebGPU: `buffer_view` feature

[Chromestatus]

Contact emails

alan...@google.com

Explainer

https://github.com/gpuweb/gpuweb/blob/main/proposals/buffer-view.md
https://github.com/webgpu/webgpu-samples/pull/568

Specification

https://github.com/gpuweb/gpuweb/pull/6291

Summary

WGSL language feature for reinterpreting data in variables. The feature allows developers to divide a single uniform, storage, or workgroup variable into multiple logical variables. It also allows the type of the data in the variable to be interpreted as multiple types within the program.

Blink component

Blink>WebGPU

Web Feature ID

webgpu

Motivation

This features adds a new opaque type for use with storage and uniform buffers and workgroup variables. It allows the data in those variables to be reinterpreted as other types. This is useful for both type-punning data and logically sub-dividing a variable into multiple parts. For ease-of-use and safety, the opaque type can only be operated on by new built-in functions. The reinterpretation can only occur on the opaque type. This maintains flexibility, but reduces implementation complexity.

Initial public proposal

https://github.com/gpuweb/gpuweb/issues/5338

TAG review

No information provided

TAG review status

Pending

Goals for experimentation

None

Risks

Interoperability and Compatibility

No information provided

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1205#issuecomment-3312534193)

WebKit: Closed Without a Position (https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933)

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?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

Yes
https://github.com/gpuweb/cts/pull/4652

Flag name on about://flags

Enable Unsafe WebGPU

Finch feature name

No information provided

Non-finch justification

No information provided

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://crbug.com/tint/506523198

Estimated milestones

Shipping on desktop	152
Shipping on Android	152
Shipping on WebView	152

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).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5094091886034944?gate=6498100941291520

This intent message was generated by Chrome Platform Status.

[Vladimir Levin]

LGTM1

[Chris Harrelson]

LGTM2

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/451921f7-f54f-4322-a13b-b82b5172603bn%40chromium.org.

[Alex Russell]

Sorry for the slow reply here; thought I'd sent questions earlier in the week. Apologies.

This feature feels useful, particularly if you've been following along with the prior set of launches in this area, but it isn't at all clear from the Explainer what problem we're solving. The example code signature is written in Rust (not JS), whereas you have to find an example code PR to walk through the benefits of smaller alignment windows:

  https://github.com/webgpu/webgpu-samples/pull/568/changes#diff-7cc23df7ee1165e19cd7f79cc96335f9597b6fa0602b151e7e7543a6a1d9a011R84

Even from that, though, the sizeable memory savings aren't obvious or clearly described in either document, and their value to developers and users is a bit opaque.

Particularly when we're the first to ship a feature, we're always trying to answer the question "does this feature solve an important problem well?", and it's difficult to say we've made that case, even if this is the ideal API.

Best,

Alex

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

[Alan Baker]

The feature provides two major benefits:
1. Data reinterpretation

2. Splitting a buffer into multiple logical buffers

The second falls out from the first. What this feature allows is viewing the contents of a buffer as multiple different types. This has a bunch of uses from straight data reinterpretation like type punning in other languages to more easily expressing packing in a buffer. So I wouldn't really say the major benefit is memory savings. That is a definite possible use case that is highlighted in the sample code, but I wouldn't want to focus solely on that. The sample is interesting because it would be difficult to express the single buffer in standard WGSL because each geometry has a different size and host-visible structures without this feature can only contain a single runtime-sized portion that has a single layout (it could be a composite data type).

Is the request here to flesh out the feature description in more detail to discuss possible use cases? If so, would you prefer the proposal is updated or the chromestatus entry?

Hopefully I've understood your concerns,

Alan

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