Content: Define build() steps more rigorously

[inexorabletash]

• 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. (Don't transfer input ArrayBuffers #566)

• The impact of MLGraphBuilder re-use (Can an MLGraphBuilder be reused? #567) is called out, since it could allow for removing the graph traversal.

• Populates graph's [[outputDescriptors]], which was previously just missing. (Add traversal algorithm to buildSync() #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 #448, fixes #457, fixes #552.

---

Preview | Diff

[fdwr]

I'll look at this tomorrow, but I wonder if we expect an empty graph to behave like an empty memmove - a nop? e.g. I'd expect this would function as identity:

    // Build empty graph.
    const input = graphBuilder.input("input", {dataType: "float32", dimensions: [4]});
    const output = input;
    const graph = await graphBuilder.build({"output": output});

    // Bind inputs to the graph and execute for the result.
    const inputBuffer = new Float32Array([0,1,2,3]);
    const outputBuffer = new Float32Array(4).fill(0);
    var inputs = {"input": inputBuffer};
    var outputs = {"output": outputBuffer};
    const results = await mlContext.compute(graph, inputs, outputs);

[inexorabletash]

I wonder if we expect an empty graph to behave like an empty memmove

Yeah, we were discussing that too. The Chromium impl seems to reject this (https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/ml/webnn/ml_graph.cc;l=159) but maybe it's fine?

[huningxin]

LGTM

[fdwr]

👍

[fdwr]

It's an interesting idea to consider what it would mean for a graph to have inputs but no outputs. I have seen some custom operators in models which emitted no outputs because they existed purely for other side effects, or they might exist for debugging (to print out or dump results). Within WebNN though there is no such thing anyway, and so this check makes sense 👍. The reverse is certainly true though that a graph can have outputs with no inputs. e.g. A graph with the fillSequence operator (renamed to a constant overload later) which fills a tensor with a sequence and has no input. The same would apply to random number generator operators too. (resolve me)

[fdwr]

Ah, so here is the check that would nullify the possibility of a nop graph (say one with just a constant and output), which conceptually seems valid to me, as one scenario is where you have a chained sequence of models with one step that can be an action or a nop, and it may be easier to express by always passing a valid (but empty) graph to that component which executes them all. Though, I'm not too worried about it either, since a caller can always insert a dummy identity node to satisfy this constraint. (resolve me)