-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transfer the input and output views for asynchronous execution #323
Conversation
@domenic, as the author of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for delay. I was sick the last few days.
index.bs
Outdated
|
||
<script type=idl> | ||
dictionary ComputeResult { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be naming-consistent with the rest of the API, should we also prefix this type with ML
e.g. MLComputeResult
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we should. Fixed in the latest commit.
index.bs
Outdated
const result = await context.compute(graph, inputs, outputs); | ||
// The computed result of [[1, 1], [1, 1]] is in the buffer associated with | ||
// the output operand. | ||
console.log('Output value: ' + result.C); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be result.outputs.C
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, my typo. Fixed in the latest commit.
|
||
console.log('Output value: ' + outputBuffer); | ||
console.log('Output value: ' + result.output); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
result.ouputs.output
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching this bug! fixed in the latest commit.
No worries. Hope you are feeling better now. Thanks for your review and comments. I uploaded a new commit to address your comments. Please take another look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor suggestions on how to better use Web IDL wrapper algorithms, which are in general preferable to directly using JS spec primitives.
However, it appears we haven't added sufficient wrapper algorithms to Web IDL to replace the Construct() step. So directly using JS spec primitives there is fine, if a bit unfortunate.
There is a more dramatic change I would suggest, if possible. It would be better if your spec algorithms operated on byte sequences instead of ArrayBufferViews. That is, you would:
- Accept
MLNamedArrayBufferViews
s. - Transfer the underlying buffers.
- Get a copy of the bytes of that buffer. (In a real implementation, this would not make a copy, but in the spec, it's a convenient way to extract the byte sequences and get away from the IDL types. Since the copy is unobservable, this is fine.)
- Modify those byte sequences.
- Eventually, create ArrayBufferViews from those byte sequences. (Again, the algorithm here is a copy, but an unobservable one that implementations will thus elide.)
- Then stuff those into new
MLNamedArrayBufferViews
s to resolve your promise with.
However, I'm not sure how well this would work for your case exactly. It seems like you care about the view types and such, and tracking that separately might be a pain.
Note that pretty much all of this advice is about how to do things better than the Streams Standard currently does them. Streams was written before we added appropriate helpers to Web IDL, and we haven't taken the time to update Streams yet. That also means people haven't really battle-tested the Web IDL helpers, so they might not work perfectly :). But the above is how I think it should work...
index.bs
Outdated
To <dfn for="MLNamedArrayBufferViews">transfer</dfn> an {{MLNamedArrayBufferViews}} |views|: | ||
1. Let |transferredViews| be a new {{MLNamedArrayBufferViews}}. | ||
1. For each |key| -> |value| of |views|: | ||
1. Let |transferredBuffer| be the result of [=transfer array buffer|transferring=] {{ArrayBuffer}} |value|.\[[ViewedArrayBuffer]]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use https://webidl.spec.whatwg.org/#buffersource-underlying-buffer instead of consulting [[ViewedArrayBuffer]]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the pointer. Fixed by the latest commit.
index.bs
Outdated
urlPrefix: https://webidl.spec.whatwg.org/; spec: WEBIDL | ||
type: interface | ||
text: Promise; url: idl-promise | ||
text: nullable; url: idl-nullable-type | ||
type: dfn | ||
text: transfer array buffer; url: arraybuffer-transfer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not be necessary if you use [=ArrayBuffer/transfer=]
syntax.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. Fixed it in the latest commit.
index.bs
Outdated
1. For each |key| -> |value| of |views|: | ||
1. Let |transferredBuffer| be the result of [=transfer array buffer|transferring=] {{ArrayBuffer}} |value|.\[[ViewedArrayBuffer]]. | ||
1. Let |constructor| be the appropriate [=view constructor=] for the type of {{ArrayBufferView}} |value|. | ||
1. Let |elementsNumber| be the result of |value|.\[[ByteLength]] ÷ [=element size=] of |value|. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use https://webidl.spec.whatwg.org/#buffersource-byte-length instead of accessing [[ByteLength]] directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the pointer. Fixed it in the latest commit.
@domenic much thanks for your detailed advice on behalf of the whole WG! |
@domenic , I'd like to echo @anssiko and thank you for the detailed feedback! It is very helpful.
I pushed a new commit that uses the Web IDL wrapper algorithms as you suggested.
Thanks for this proposal! I feel the byte sequences algorithm would help improve the graph execution steps that @zolkis is working on by #319. Because this PR mainly focuses on fixing #318 by transferring the input/output buffers, we probably can file a separate issue to track this proposal and fix it by a follow-up PR or Zoltan's PR #319. WDYT? |
From my part I am fine with that. Please finish what you wanted in this PR and I will rework (not only rebase) my PR based on that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@huningxin thanks! Approved with one suggestion and with an assumption @zolkis' upcoming update address the byte sequences algorithm bits.
@wchao1115 PTAL As discussed yesterday, we'd like to get this PR landed soon so @zolkis can rework his PR #319 on top of this. Thanks! |
Thank you everyone! This PR has received adequate review and we're now ready to merge to unblock related work. I'm especially pleased to see how the cross-group collaboration helped improve the design. |
SHA: 019a1f6 Reason: push, by anssiko Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
To align with latest spec: webmachinelearning/webnn#323 This fixed: webmachinelearning#158
To align with latest spec: webmachinelearning/webnn#323 This fixed: #158
…rning#323 Squashed from the following commits: Add link to asserts Clarify the graph execution steps Address review comments for graph execution Factor out buffer validation vs descriptor Remove note about execution Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
* Rework the sync and async execution algorithms based on #323 Squashed from the following commits: Add link to asserts Clarify the graph execution steps Address review comments for graph execution Factor out buffer validation vs descriptor Remove note about execution Remove extra copy of the 'validate buffer with descriptor' steps Signed-off-by: Zoltan Kis <zoltan.kis@intel.com>
fix #318
@wchao1115 @anssiko @wacky6 @RafaelCintron , please take a look. Thanks!
Preview | Diff