[FL33TW00D]

Hi Tommy!

I sent you an email a few weeks back - would be great to chat!

WONNX is a seriously impressive project. There is a few reason I didn't just contribute back to WONNX:

1. WONNX does not parse the ONNX model into an IR, which I think is essential to have the freedom to transform the model as required.

2. When I started, WONNX didn't seem focused on symbolic dimensions (but I've seen you shipping the shape inference recently!).

3. The code quality has to be much higher when it's open source! I wanted to hack on this without anyone to please but myself.

[antimora]

I'm presently working on enhancing Burn's (https://burn-rs.github.io/) capabilities by implementing ONNX model importation (https://github.com/burn-rs/burn/issues/204). This will enable users to generate model source code during build time and load weights at runtime.

In my opinion, ONNX is more complex than necessary. Therefore, I opted to convert it to an intermediate representation (IR) first, which is then used to generate source code. A key advantage of this approach is the ease of merging nodes into corresponding operations, since ONNX and Burn don't share the same set of operators.

[misterdata]

Actually WONNX also transforms to an IR first (early versions did not and simply translated the graph 1:1 to GPU shader invocations in topographically sorted order of the graph). In WONNX the IR nodes are (initially) simply (copy-on-write references to) the ONNX nodes. This IR is then optimized in various ways, including the fusion of ONNX ops (e.g. Conv+ReLU->ConvReLU). The newly inserted node still embeds an ONNX node structure to describe it but uses an internal operator.

[FL33TW00D]

Looks great!

ONNX is 100% more complex than necessary. Another format of interest is NNEF: https://www.khronos.org/nnef

[misterdata]

Also see the recently introduced StableHLO and its serialization format: https://github.com/openxla/stablehlo/blob/main/docs/bytecode...