Support strides option for `slice` operator

huningxin commented 1 month ago

This is a separate issue of previous discussion https://github.com/webmachinelearning/webnn/issues/369#issuecomment-1487754271 focusing on steps/strides support (proposed by @fdwr, thanks!).

A stride of slice operator indicates how many elements to advance when copying within the input tensor along a dimension. It is widely supported. However, today's WebNN slice operator only support stride 1. We observed there are real models using slice with stride > 1. When targeting those model to WebNN, the slice op has fallback to other execution provider and causes performance drop.

Frameworks' support

TensorFlow's strided_slice supports optional strides.
ONNX's Slice support optional steps.
NumPy's ndarray slicing and striding supports start:stop:step notion.

Native ML API's support

DML DML_SLICE1_OPERATOR_DESC supports optional InputWindowStrides.
CoreML slice_by_index supports optional stride.
TFLite strided_slice optional strides.

Proposal

dictionary MLSliceOptions : MLOperatorOptions {
  sequence<[EnforceRange] unsigned long> strides;
};

MLOperand slice(MLOperand input,
                sequence<[EnforceRange] unsigned long> starts,
                sequence<[EnforceRange] unsigned long> sizes,
                optional MLSliceOptions options = {});

Revision History: 10/29/2004: only support positive strides.

a-sully commented 1 month ago

Seems reasonable to me 👍

huningxin commented 1 month ago

Discussed with @fdwr offline, the negative strides may have ambiguities due to starting index. A separate reverse operator is proposed in #773. I'd update the proposal to support the positive strides as the starter.

fdwr commented 1 month ago

I'd update the proposal to support the positive strides as the starter.

Alrighty. Yeah, I can draw a diagram later illustrating the ambiguities related to negative strides, but positive strides are very clear.

webmachinelearning / webnn