add minimum data types and rank range for operations#910
Conversation
@BruceDai : Remerge with main. My PR adds an extra blank line that pacifies the build error (and yes, that line was already correct, and nothing changed there for months, but bikeshed changed). |
reillyeon
left a comment
There was a problem hiding this comment.
General wording looks good. I have not validated the specific operator limits specified.
fdwr
left a comment
There was a problem hiding this comment.
👀 Thanks for the updates Bruce - I'm sure they were tedious :b.
| <td>[=/any data type|any=]</td> | ||
| <td>{{MLOperandDataType/"float32"}}, {{MLOperandDataType/"float16"}}, {{MLOperandDataType/"int32"}}</td> | ||
| <td>[=/any rank|N=]</td> | ||
| <td>0 to 4</td> |
There was a problem hiding this comment.
Which ML API is the outlier for pow being 0 to 4 instead of 0 to 5? It will be problematic for callers if mul/div/pow have inconsistent ranks from each other, as certain substitution operations might expect that they can safely chain these or switch from one to another (e.g. mul(a,a) == pow(a,2)) without surprise. I propose the outlier API fix this in their Chromium backend with flanking reshapes (flatten to 1D if > 4D, pow, then back to the original shape). Then pow can be remerged back with the rest above.
There was a problem hiding this comment.
Which ML API is the outlier for pow being 0 to 4 instead of 0 to 5?
It's limited by TFLite backend.
Please refer to https://source.chromium.org/chromium/chromium/src/+/main:services/webnn/tflite/graph_builder_tflite.cc;l=568
// Limited to 4D when broadcasting is required:
// https://source.chromium.org/chromium/chromium/src/+/main:third_party/tflite/src/tensorflow/lite/kernels/pow.cc
/*pow_input=*/{kFloat16To32AndInt32, SupportedRanks::UpTo(4)},There was a problem hiding this comment.
Can we open a TFLite issue? Alternately we open a Chromium issue to {reshape, expand if needed, pow} until TFLite can address it.
There was a problem hiding this comment.
Filed a Chromium issue - https://issues.chromium.org/issues/471017637.
There was a problem hiding this comment.
Filed a Chromium issue - https://issues.chromium.org/issues/471017637.
@BruceDai , what's your plan for fixing this issue?
There was a problem hiding this comment.
Filed a Chromium issue - https://issues.chromium.org/issues/471017637.
@BruceDai , what's your plan for fixing this issue?
@BruceDai , I guess this issue can be fixed in a similar way of 7848774: webnn: align logical op rank limits at 5 on the TFLite backend?
| <tr> | ||
| <td>{{input}}</td> | ||
| <td>[=/any data type|any=]</td> | ||
| <td>{{MLOperandDataType/"float32"}}, {{MLOperandDataType/"float16"}}, {{MLOperandDataType/"int32"}}</td> |
There was a problem hiding this comment.
ORT doesn't support int32
There was a problem hiding this comment.
🤔 An ONNX BitCast operator could help with cases of pure data movement (since no actual math happens) like this one when the operator supports a different data type of the same bit size (sizeof(int32) == sizeof(uint32) == sizeof(float32)). For example, we could call BitCast(int32input, type=float32) -> Triangular -> BitCast(input, type=int32). I'll comment on that ONNX PR.
(update) BitCast operator is pending: onnx/onnx#7527
There was a problem hiding this comment.
(update) BitCast is in ONNX https://onnx.ai/onnx/operators/onnx__BitCast.html, now enabling callers of the ORT backend to support all data types of the same bit size for data movement operators, so long as the EP supports BitCast and at least one data type of a given bit size (e.g. supporting int16 with Gather also enables uint16, float16, bfloat16...).
|
Thanks @huningxin and @fdwr for review and identifications. 👍 |
949a42f to
b6b300f
Compare
b6b300f to
3f29bff
Compare
mwyrzykowski
left a comment
There was a problem hiding this comment.
Conflict with the WG meeting, but ✅
| <td>[=/any data type|any=]</td> | ||
| <td>{{MLOperandDataType/"float32"}}, {{MLOperandDataType/"float16"}}, {{MLOperandDataType/"int32"}}</td> | ||
| <td>[=/any rank|N=]</td> | ||
| <td>0 to 4</td> |
There was a problem hiding this comment.
Filed a Chromium issue - https://issues.chromium.org/issues/471017637.
@BruceDai , what's your plan for fixing this issue?
@huningxin Thanks for your kindly reminder! Please review the fixing CL-7848774 . |
|
Thanks @reillyeon @huningxin and @fdwr for reviewing and approving CL-7848774, now it has been landed. |
fdwr
left a comment
There was a problem hiding this comment.
👍 Thank you for enabling this.
| <td>[=/any data type|any=]</td> | ||
| <td>{{MLOperandDataType/"float32"}}, {{MLOperandDataType/"float16"}}, {{MLOperandDataType/"int32"}}</td> | ||
| <td>[=/any rank|N=]</td> | ||
| <td>0 to 4</td> |
There was a problem hiding this comment.
Filed a Chromium issue - https://issues.chromium.org/issues/471017637.
@BruceDai , what's your plan for fixing this issue?
@BruceDai , I guess this issue can be fixed in a similar way of 7848774: webnn: align logical op rank limits at 5 on the TFLite backend?
| <td>[=/any data type|any=]</td> | ||
| <td>{{MLOperandDataType/"float32"}}, {{MLOperandDataType/"float16"}}, {{MLOperandDataType/"int32"}}</td> | ||
| <td>[=/any rank|N=]</td> | ||
| <td>0 to 4</td> |
There was a problem hiding this comment.
Should we also generalize them to 0 to 5D? I already see a CL relies on 5D lesser in TFLite backend: webnn: Support >4D indices for gather/gatherND/scatterND
| <td>[=/any data type|any=]</td> | ||
| <td>{{MLOperandDataType/"float32"}}, {{MLOperandDataType/"float16"}}</td> | ||
| <td>[=/any rank|N=]</td> | ||
| <td>0 to 4</td> |
There was a problem hiding this comment.
Do the same? Then we will have all logical operators supporting 0 to 5D.
There was a problem hiding this comment.
Then we will have all logical operators supporting 0 to 5D.
Hmm, I wonder how far we are from all elementwise ops ranging 0 through 5?
There was a problem hiding this comment.
I guess two or three CLs for Chromium TFLite backend?
- pow and logical binary ops
- isNan/isInfinite
7848774: webnn: align logical op rank limits at 5 on the TFLite backend already landed necessary helpers.
This PR is to fix #896.
@huningxin @fdwr @reillyeon PTAL, thanks!
Preview | Diff