Graph initialization is an important step in optimizing an MLGraph for execution on the GPU using DirectML (see #303 (comment)). This is another piece of build() which should be better specified (see #457).

However, the spec currently refers to graph initialization in two different ways:

• The specification of MLCommandEncoder includes a definition of graph initialization, which consists of a non-normative note but no formal algorithm
  • Note: MLCommandEncoder was never implemented and is being removed from the spec: Remove MLCommandEncoder #546
• The MLGraph.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 constants

The 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:

• Validating inputs
  • That being said, ideally this validation (or as much as possible) is done while adding to MLGraphBuilder, rather than on the build() step. I think there is more work to be done with regards to Validate op arguments early to better support eager execution #234
• Checking the uniqueness of MLOperand names
  • Again, this seems like something we could do while adding to MLGraphBuilder?
• What does "Register operand.[[operator]] to graphImpl." mean?
• etc...

Should these steps be part of "graph initialization"? Or should we use some other term?