-
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
Decide how to specify graph initialization #552
Comments
a-sully
added a commit
to a-sully/webnn
that referenced
this issue
Feb 4, 2024
Merged
Looks like @inexorabletash is one step ahead of me :) #549 (comment) |
a-sully
added a commit
to a-sully/webnn
that referenced
this issue
Feb 8, 2024
This was referenced Feb 15, 2024
inexorabletash
added a commit
to inexorabletash/webnn
that referenced
this issue
Mar 13, 2024
- Adds validation that passed outputs are neither inputs nor constants, matching the Chromium implementation. - Traverses the graph, starting with outputs, to visit all connected operands. - Previously the outputs were iterated over to process inputs and constants, which didn't make any sense. Inputs are hooked up to [[inputsDescriptors]]. Nothing is specifically mentioned about constants, but an issue about transferring is referenced. (webmachinelearning#566) - The impact of MLGraphBuilder re-use (webmachinelearning#567) is called out, since it could allow for removing the graph traversal. - Populates graph's [[outputDescriptors]], which was previously just missing. (webmachinelearning#448) - Makes most of the validation behavior of build() happen synchronously rather than "in parallel". A promise is still returned, of course. - Converting the graph into an implementation-defined format is called out, which remains in "in parallel" steps. Fixes webmachinelearning#448, fixes webmachinelearning#457, fixes webmachinelearning#552.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Graph initialization is an important step in optimizing an
MLGraph
for execution on the GPU using DirectML (see #303 (comment)). This is another piece ofbuild()
which should be better specified (see #457).However, the spec currently refers to graph initialization in two different ways:
MLCommandEncoder
includes a definition of graph initialization, which consists of a non-normative note but no formal algorithmMLCommandEncoder
was never implemented and is being removed from the spec: Remove MLCommandEncoder #546MLGraph.buildSync()
algorithm includes a step to "make a request to the underlying platform to initialize the graph", which includes steps such as validating MLOperands and preprocessing constantsThe former pretty clearly maps to the concept of graph initialization in DirectML. As does "Implementations MAY preprocess and optimize the tensor data of operand for the underlying platform" from the
MLGraph.buildSync()
algorithm. Since this initialization step is context-dependent and may not exist separate from compilation for other backends (see #341 (comment)), I tentatively suggest alluding to this step as an implementation-defined non-normative hint.However, we can't just wave away "graph initialization" as entirely implementation-defined. There are some characteristics of this step (at least how it's currently specified) which still should be specified somehow:
MLGraphBuilder
, rather than on thebuild()
step. I think there is more work to be done with regards to Validate op arguments early to better support eager execution #234MLGraphBuilder
?Should these steps be part of "graph initialization"? Or should we use some other term?
The text was updated successfully, but these errors were encountered: