Hey Alan,

You've already got 3 LGTMs, but just wanted to add my thanks for making the 
utility clearer.

Best,

Alex

On Wednesday, July 29, 2026 at 7:18:10 AM UTC-7 Yoav Weiss wrote:

> LGTM3
>
> On Tuesday, July 28, 2026 at 1:19:19 AM UTC+2 Alan Baker wrote:
>
>> I've landed an update to the explainer (proposal on github). If you want 
>> the diff the PR is easiest: https://github.com/gpuweb/gpuweb/pull/6342.
>>
>> Alan
>>
>> On Mon, Jul 27, 2026 at 2:54 PM Alan Baker <[email protected]> wrote:
>>
>>> Hi Alex,
>>>
>>> I'll expand the explainer this week.
>>>
>>> Thanks,
>>> Alan
>>>
>>> On Mon, Jul 27, 2026 at 2:38 PM Alex Russell <[email protected]> 
>>> wrote:
>>>
>>>> Hey Alan,
>>>>
>>>> Thanks for explaining. Can you commit to adding these high-level 
>>>> problems to be solved as goals in the explainer and then show, with 
>>>> JavaScript, how this new API addresses them? That's the usual bar for 
>>>> feature legibility, and without it it's hard to proceed.
>>>>
>>>> Best,
>>>>
>>>> Alex
>>>>
>>>> On Wednesday, July 22, 2026 at 9:33:23 AM UTC-7 Alan Baker wrote:
>>>>
>>>>> 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
>>>>>
>>>>> On Wednesday, July 22, 2026 at 11:33:20 AM UTC-4 Alex Russell wrote:
>>>>>
>>>>>> 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
>>>>>>
>>>>>> On Wednesday, July 22, 2026 at 8:06:17 AM UTC-7 Chris Harrelson wrote:
>>>>>>
>>>>> LGTM2
>>>>>>>
>>>>>>
>>>>>>> On Wed, Jul 22, 2026 at 6:54 AM Vladimir Levin <[email protected]> 
>>>>>>> wrote:
>>>>>>>
>>>>>> LGTM1
>>>>>>>>
>>>>>>>> On Wednesday, July 15, 2026 at 2:23:35 PM UTC-4 Chromestatus wrote:
>>>>>>>>
>>>>>>> *Contact emails*
>>>>>>>>> [email protected]
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> *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 
>>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebGPU%22>
>>>>>>>>>
>>>>>>>>> *Web Feature ID*
>>>>>>>>> webgpu <https://webstatus.dev/features/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 
>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
>>>>>>>>> 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 
>>>>>>>>> <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 [email protected].
>>>>>>>
>>>>>>>
>>>>>>>> To view this discussion visit 
>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/451921f7-f54f-4322-a13b-b82b5172603bn%40chromium.org
>>>>>>>>  
>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/451921f7-f54f-4322-a13b-b82b5172603bn%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 [email protected].
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aa8c78fd-6b3c-41c3-ba04-92d8bc743857n%40chromium.org.

Reply via email to