-
Notifications
You must be signed in to change notification settings - Fork 55
add minimum data types and rank range for operations #910
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General wording looks good. I have not validated the specific operator limits specified.
fdwr
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👀 Thanks for the updates Bruce - I'm sure they were tedious :b.
| <tr> | ||
| <td>{{input}}</td> | ||
| <td>[=/any data type|any=]</td> | ||
| <td>{{MLOperandDataType/"float32"}}, {{MLOperandDataType/"float16"}}, {{MLOperandDataType/"int32"}}, {{MLOperandDataType/"int8"}}, {{MLOperandDataType/"uint8"}}</td> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gatherElements includes int8/uint8, but its symmetric counterpart scatterElements does not 😳 I don't know which API has this surprising inconsistency, but I'd rather restrict gatherElements's required data types to exclude int8/uint8 than introduce this asymmetry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know which API has this surprising inconsistency
index.bs
Outdated
| <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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ORT doesn't support int32
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 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
|
Thanks @huningxin and @fdwr for review and identifications. 👍 |
93d1bc9 to
949a42f
Compare
949a42f to
b6b300f
Compare
This PR is to fix #896.
@huningxin @fdwr @reillyeon PTAL, thanks!
Preview | Diff