onnx / sigs

Repository for ONNX SIG artifacts

SIGs - Special Interest Groups

As described in the ONNX governance, Special Interest Groups (SIGs) are persistent groups responsible for specific parts of the project. SIGs have open and transparent proceedings to develop goals and implement code contributions. SIGs are also responsible for ongoing maintenance of the code in their areas.

SIG artifacts, including membership list and meeting notes, are stored in this repository.

Participating

If you are interested in participating, please join the discussion in the respective slack channel.

You can find the schedule of SIG meetings on the LF AI & Data calendar

SIG members

The current list of Contributors and Approvers in the SIGs are listed in the CONTRIBUTORS file. The file also describes the process for updating the list.

Current SIGs

Contact e-mail addresses of SIG leads can be found here.

Name	Responsibilities
Architecture & Infra	Defining and maintaining the core ONNX format, the build and CI/CD systems for ONNX repositories, publishing release packages for ONNX, the onnx-docker repository, and creating tools to help integrate with and test against the ONNX standard. This SIG is also the defacto owner of files in the main ONNX repository unless explicitly owned by another SIG.
Compilers	Developing and maintaining core compiler technology for optimizing and lowering ONNX format.
Converters	Developing and maintaining the various converter repositories under ONNX.
Models and tutorials	Providing a comprehensive collection of state of the art ONNX models from a variety of sources and making it easy for users to get started with ONNX and the ecosystem around it.
Optimizations	Developing and maintaining solutions to optimize ONNX models, including model compression techniques (e.g. quantization, pruning, distillation, etc.)
Operators	Determining the operators that are part of the ONNX spec (ONNX and ONNX-ML domains), ensuring high quality operator definitions and documentation, establishing criteria for adding new operators, managing ops domains and compliance tiers, and enforcing versioning mechanisms.

sigs's Issues

Gitter -> Slack

The readme mentions:

If you are interested in participating, please join the discussion in the respective Gitter room.

=> Should be a link to slack?

How to support different system configuration or backend framework versions between the conversion and execution servers

The system configuration or backend framework versions between the conversion and execution servers can be different in practice. One might use a CPU machine to convert the model and a GPU machine to run the converted model. Do we want to suggest certain general mechanism to support this scenario?

How to handle unsupported data types in converters?

We often need to handle unsupported data types in converters, because for the same operator, input, and attribute, the framework API has a different list of supported data types.

There are a few options:

1. throw exception
2. auto cast everything
3. selective/safe auto cast
4. user agreed auto cast

We would like to seek and document a common approach so most, if not all, converters would handle unsupported data types in a similar fashion.

How to handle deprecated operators?

For both frontend and backend converters, how deprecated operators should be handled? We would like to have some guidelines. Since a deprecated operator is still in the ONNX operator list, it could potentially appear in the onnx graph. What the expected results if a backend converter encounters such a node?

Evaluate ONNX training proposal

We would like to evaluate the feasibility of the ONNX training proposal, onnx/onnx#2038, and share our results with the Training WG and converter SIG.

The goal of this issue/task is to identify the proposed ONNX training spec can be practically generated and used in Tensorflow and other frameworks for training by

1. Investigate and provide prototype code for conversion from ONNX training IR to Tensorflow (and others if possible) trainable model format

2. Investigate and provide prototype code for conversion from Tensorflow (and others if possible) trainable model format to ONNX training IR

Clearly define Converter and provide list of converters

What is a "Converter" in ONNX? We would like to have a clear definition to make sure the entire ONNX community uses the same interpretation. Then we will provide a complete list of ONNX converters. Later we will update the list with additional details.

Analytics for github repo / model download usage

Github has 2 weeks worth of traffic data for model zoo + tutorials.

What solutions exist so that we can track usage over a longer period?

Linear Algebra Operators

Hello. I am working on a project where we are building Pytorch Gaussian Process Models and converting them into ONNX format. (https://gpytorch.ai/). At runtime, some of these models need to perform linear algebra operations such as a Cholesky decomposition or a triangular matrix solve. So, we would like to add operators to support these linear algebra methods. I see that there has been periodic interest in this idea here before. Would the group be open to the idea of adding a new domain to support linear algebra operations?

I'm thinking of creating an operator domain like ai.onnx.linalg and starting to add key operations modeled after the numpy.linalg library (https://numpy.org/doc/stable/reference/routines.linalg.html).
I realize that these operations are not core to neural networks, but many other kinds of models do make use of linear algebra routines.
Is there interest in this idea?
Has this already been done somewhere?

How to support and verify dynamic shape and rank in inputs?

ONNX allows a tensor-type to have no shape (which means that even the rank is unknown). A tensor type may have a shape, in which case its rank is known. Each dimension may itself be a statically known constant or unknown. This causes Tensorflow backend converter issues when the conversion logic is based on the input rank or shape. Not sure if this applies to other converters. Would be nice to come up with common solutions.

Model Zoo CI Proposal updates

As showcased in onnx/models#168, the model zoo CI is a strong request from the converter SIG and the ONNX community at large.

There is an original proposal from the OpenLab team: https://github.com/onnx/sigs/blob/master/models-tutorials/docs/ci_proposal/ONNX_model_zoo_ci_proposal.md

However, with the addition of Git LFS, we can simplify this proposal further and remove the necessity of parsing READMEs, etc.

Base Requirement: running ONNX checker on each model
Further Requirements: testing models with included test data

How to handle and test onnx-ml operators?

Currently there is no unit test for onnx-ml operators. We would like to identify how converters can verify and claim support of onnx-ml operators. Also figure out how to report and configure the onnx-ml opset version.

Where/how to see current state (coverage, versioning, etc) for all converters

ONNX users need to conveniently see the most recent state for all converters to ensure smooth conversion between frameworks/backends. We certainly don't intend to add much development work to individual converter communities. Therefore, we would like to investigate and propose some simple mechanism to make sure our end users have the best experience with ONNX converters as possible.

Maintaining versioning for ONNX models

In the model zoo, a contributor normally submits a model and also maintains opset versions of each model.

Because of difference in contribution levels between contributors, some models have a lot more models at different versions than others.

1. Can we take advantage of the version converters to automate this process?
2. What role should the Model Zoo SIG play in the maintenance of these models for new ONNX / ONNX Runtime releases?

Signup down?

I attended the ONNX Community Day sessions and they were interesting. I tried to sign up but I get this error message.

Going to https://slack.lfai.foundation/ hits this issue with Chrome...

Error: error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:71:19)
at Object.createHash (node:crypto:133:10)
at weakhash (/usr/local/lib/node_modules/slackin/node_modules/etag/index.js:168:6)
at etag (/usr/local/lib/node_modules/slackin/node_modules/etag/index.js:59:7)
at wetag (/usr/local/lib/node_modules/slackin/node_modules/express/lib/utils.js:46:10)
at ServerResponse.send (/usr/local/lib/node_modules/slackin/node_modules/express/lib/response.js:169:14)
at /usr/local/lib/node_modules/slackin/dist/index.js:128:9
at Layer.handle [as handle_request] (/usr/local/lib/node_modules/slackin/node_modules/express/lib/router/layer.js:82:5)
at next (/usr/local/lib/node_modules/slackin/node_modules/express/lib/router/route.js:110:13)
at Route.dispatch (/usr/local/lib/node_modules/slackin/node_modules/express/lib/router/route.js:91:3)