Skip to content
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

Option/Mode to Build Onnx Runtime with Full Onnx Support #1122

Closed
GuanLuo opened this issue May 28, 2019 · 6 comments
Closed

Option/Mode to Build Onnx Runtime with Full Onnx Support #1122

GuanLuo opened this issue May 28, 2019 · 6 comments
Labels
feature request request for unsupported feature or enhancement

Comments

@GuanLuo
Copy link

GuanLuo commented May 28, 2019

Is your feature request related to a problem? Please describe.
I am using Onnx Runtime library and expecting it to have full Onnx support as it promises. But some data types for some operators are turned off as discussed in #1080. Right now it is inconvenient to ensure that the Onnx Runtime library has all Onnx operators enabled, as I need to do something similar to 31cbb5d and then rebuild to support some data types.

System information

  • ONNX Runtime version (you are using): 0.4.0

Describe the solution you'd like
I am looking for a build option/mode so that I can build the library with full Onnx support. If the option/mode is not set, then the library will fall back to the current setting.

@faxu
Copy link
Contributor

faxu commented May 29, 2019

Hi, are there some common types you've found are needed but not currently supported? We're looking into ways to support types more fully, though it's a balance between minimizing binary size and breadth of support. If there are specific things you've commonly found missing, this will be useful for the assessment.

@faxu faxu added the feature request request for unsupported feature or enhancement label May 29, 2019
@GuanLuo
Copy link
Author

GuanLuo commented May 30, 2019

Hi, I haven't encountered actual use cases that required unsupported data types, I was just expanding our application's test cases to cover some custom models and noticed some data types are unsupported.

That being said, our application allows users to provide their own Onnx models which may come with various operators and types. That is why I wish there is a build option to build the library with Onnx support that matches the version matrix. Perhaps if that build option is not set, the library will be built with minimized setting to meet the balance between size and breadth of support as you mentioned.

I understand that it will be a long process to add such build option (or other equivalent), so at the meantime, it will be helpful if there is a table about what types in operators are currently disabled in Onnx Runtime. So that in the case similar to #1080, I can refer to the table and know if the error is due to incorrect usage of the APIs.

@linkerzhang
Copy link
Contributor

Thank you @GuanLuo for the constructive feedback!

Let's do it this way, as you suggested, to firstly come out of the table containing not supported types for each op in ONNX, secondly, add type support drive by demand (as there's no missing common data type list right now, and it's not that good to just add all types). Make sense please?

@GuanLuo
Copy link
Author

GuanLuo commented Jun 3, 2019

@linkerzhang Sure, and do you mind to point me to the table once it is available? Thanks.

@shahasad
Copy link
Contributor

@linkerzhang, @GuanLuo:
Here is a table of currently implemented ops and the supported types. Hope this helps -
https://github.com/microsoft/onnxruntime/blob/master/docs/OperatorKernels.md

@faxu faxu added the wontfix label Mar 10, 2020
@faxu
Copy link
Contributor

faxu commented Mar 10, 2020

At this time, there is no plan for ORT to support all data types due to binary size considerations and utility of such support.

@faxu faxu closed this as completed Mar 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request request for unsupported feature or enhancement
Projects
None yet
Development

No branches or pull requests

4 participants