3 ms·

Looking forward to your WebGPU ML runtime! Also, why not contribute back to WONNX? (https://github.com/webonnx/wonnx https://github.com/webonnx/wonnx)

FL33TW00D 3y ago
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 3y ago
  I'm presently working on enhancing Burn's (https://burn-rs.github.io/ https://burn-rs.github.io/) capabilities by implementing ONNX model importation (https://github.com/burn-rs/burn/issues/204 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.
  - FL33TW00D 3y ago
    Looks great! ONNX is 100% more complex than necessary. Another format of interest is NNEF: https://www.khronos.org/nnef https://www.khronos.org/nnef
    - misterdata 3y ago
      Also see the recently introduced StableHLO and its serialization format: https://github.com/openxla/stablehlo/blob/main/docs/bytecode.md https://github.com/openxla/stablehlo/blob/main/docs/bytecode...
  - misterdata 3y ago
    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 3y ago

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 3y ago
I'm presently working on enhancing Burn's (https://burn-rs.github.io/ https://burn-rs.github.io/) capabilities by implementing ONNX model importation (https://github.com/burn-rs/burn/issues/204 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.
- FL33TW00D 3y ago
  Looks great! ONNX is 100% more complex than necessary. Another format of interest is NNEF: https://www.khronos.org/nnef https://www.khronos.org/nnef
  - misterdata 3y ago
    Also see the recently introduced StableHLO and its serialization format: https://github.com/openxla/stablehlo/blob/main/docs/bytecode.md https://github.com/openxla/stablehlo/blob/main/docs/bytecode...
- misterdata 3y ago
  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.