Repository navigation
Conversation
|
A POC based on the current explainer is WIP. And it has been validated against some real-world Transformer, LLM and image generation models. |
fdwr
left a comment
fdwr
left a comment
There was a problem hiding this comment.
👍 I have some thoughts, but it's 95% 👌.
|
anssiko marked as non substantive for IPR from ash-nazg. |
|
I cleared the automatic IPR check for this PR, since explainer documents are consider non-substantive from the W3C Patent Policy point of view. DetailsThis IPR check is to ensure normative portions of the specification come from organizations who participate the WG. Furthermore, in this case, I can attest the authors of this PR are affiliated with Intel, and as such, any normative portions are reusable in the spec PR, as appropriate. |
|
@reillyeon you had good questions comments on our last call for this. Do you have some other Googlers in mind who should review this explainer PR? When this PR lands, the team will start landing the implementation in smaller chunks for further validation of this approach. |
reillyeon
left a comment
reillyeon
left a comment
There was a problem hiding this comment.
Overall I think this approach is reasonable. My main concern is that by making shapes dynamic there are more opportunities for memory safety issues in the implementation.
|
With two approvals, editors are welcome to merge this explainer PR at will. Thank you @miaobin for this contribution and Reilly, Dwayne, everyone for your review. |
|
@huningxin The latest Patchset of the dynamic shape POC runs dynamic shape inference and validation in Blink at dispatch time and also makes |
| ```js | ||
| // After: 'sequence_length' is a named dynamic dimension. | ||
| const input = builder.input('attention_mask', {dataType: 'float32', shape: [1, 'sequence_length']}); | ||
| const graph = await builder.build({output}); |
There was a problem hiding this comment.
the post-compilation on dispatch might be finger printable (below discussion suggest computeShapes is the natural place for post-compilation and shape specialization). Also, the implementation hitting an very unfortunate shape might have a finger printable cost that allows guesses about the used HW and implementation.
|
Hi @theHamsta, thank you for the depth of this review; it changed the document in several places. I'd like to check whether the current state is one you'd be comfortable approving. |
|
Last call for comments. Editors will merge this by our next meeting this Thu. |
fdwr
left a comment
fdwr
left a comment
There was a problem hiding this comment.
Some of the newly added sentences need polish for our human readers. Otherwise the latest iteration seems fine to me.
@fdwr I've pushed two commits: |
|
Resolved as #883 (comment) |
Rephrase sentences for clarity and conciseness (no functional changes).
fdwr
left a comment
fdwr
left a comment
There was a problem hiding this comment.
👍 Thanks Bin, humans happy 😁.
|
@fdwr @huningxin feel free to merge this per https://www.w3.org/2026/09/24-webmachinelearning-minutes.html#f51e at your earliest opportunity. @miaobin thank you for your work on this and the subsequent iteration. As usual, also this explainer is expected to receive updates as we learn more from the implementation experience, from Chromium and from other environments such as #945 (comment) |
This branch has not been deployed
8 participants
This is the initial draft to summarize the discussion on dynamic shapes #883 .
The explainer covers named/unnamed dynamic dimensions, deferred (dispatch-time) shape validation,
computeShapes()API, and a new family of shape-as-data (*Dynamic) operators.Open questions and considered alternatives are called out explicitly in the explainer and feedback on this doc would be very welcome.