Define the algorithm of calculating the effective padding for "same-upper" and "same-lower" option

[huningxin]

WebNN conv2d operation allows to set MLConv2dOptions.autoPad option to "same-upper" or "same-lower" of MLAutoPad enum.

The spec mentions:

With the "same-upper" option, the padding values are automatically computed such that the additional ending padding of the spatial input dimensions would allow all of the input values in the corresponding dimension to be filtered. The "same-lower" option is similar but padding is applied to the beginning padding of the spatial input dimensions instead of the ending one.

The spec should define the algorithm of how the padding values are automatically computed.

This issue was raised in Chromium CL review. Thanks @wacky6 for the feedback.

[wchao1115]

+1

[fdwr]

I agree with this issue's intent to better document padding behavior.

Though, I also wonder whether more of this higher-level policy can be resolved by the caller? I just finished looking through Bin's WebNN: Define convTranspose2d operator in mojo, and it's a lot of complexity to validate and compute the output shapes. Like how we want to simplify matmul's complicated 1D reshaping higher layer policy, is there anything here too we can simplify to reduce the implementation, testing burden, and spec complexity for conv? The calling frameworks (e.g. TF/ORT) already have this logic anyway for their own needs and could resolve some of these aspects like massaging automagic padding into explicit padding (or even to an explicit output shape) before reaching WebNN, and so it shouldn't be an undue burden on them, probably even just a 1 or 2-line function call for them to resolve explicit padding and output shape via their helper functions 🤞.

• ONNX Runtime:
  • Padding resolved here via InitializeKernel()
  • Actually computed here
  • And used with DML here:
• TensorFlow - TODO
• PyTorch - TODO

[huningxin]

is there anything here too we can simplify to reduce the implementation, testing burden, and spec complexity for conv?

Do you propose we should drop the support of MLAutoPad and only support explicit padding? If the frameworks can handle that, that would definitely reduce the implementation complexity.

[Honry]

WebNN EP has implemented the explicit padding to replace the MLAutoPad at microsoft/onnxruntime#18688.

Tensorflow TFLite also supports calculating the padding values via ComputePaddingHeightWidth, and I've implemented that in TFLite WebNN Delegate at huningxin/tensorflow#50.