Make tract/onnx/src/ops/nn/instance_norm public

[alexander-camuto]

Hello all :)

Am trying to access tract_onnx::ops::nn::instance_norm::InstanceNorm to process an onnx graph that contains InstanceNorm nodes (i.e by downcasting node.op() to an InstanceNorm struct and then extracting parameters from there). However tract/onnx/src/ops/nn/ is currently private and I don't see any other way to downcast the op to such a struct.

Was wondering if it would be possible to make this module public or at least expose the InstanceNorm in some other way :)

[kali]

Do you realize InstanceNorm contains just an "epsilon" value ?

[alexander-camuto]

yeah for sure ! its more about making the node loading interface consistent across operations -- if that makes sense. If I'm downcasting to load MaxPool or Conv it would be great to be able to do the same for InstanceNorm if possible.

[kali]

TBH, I was never super focused on visibility of struct fields. Is InstanceNorm an exception here ? Are other Expansion implementations consistently using public fields ?
I think you're doing something that I had not planned for: in my mind, the expansions are just meant to bridge the gap between ONNX definitions and tract-core operators. I never though somebody would be interested in using them as an API. Can you tell us a bit more about your use case ?

[alexander-camuto]

yeah for sure ! I'm currently building out EZKL which is a library for converting ONNX graphs into zero-knowledge SNARKS. More broadly:

“Zero-knowledge” proofs allow one party (the prover) to prove to another (the verifier) that a statement is true, without revealing any information beyond the validity of the statement itself. For example, in the case of an ONNX model, the prover can prove that they correctly ran a publicly available model on their data -- without ever revealing their data !

In our case we don't match the ONNX definitions to tract-core operators, we have to match them to polynomial constraints instead -- so our operations differ from the tract-core operators; but we still need access to the inner values of structs to be able to construct the operations accordingly :) Hope that makes sense

[kali]

Feel free to submit a PR making private fields from Expansion public if you want. That said, I would recommend you look into an alternate scenario: instead of "branching" out of the ONNX InferenceModel, consider branching out a TypedModel made of tract-core operators. You will find a much smaller operators set, take advantage of tract model simplification, and gain compatibility with NNEF (and a tiny subset of tensorflow). A couple of other teams are branching out of the TypedModel.

[alexander-camuto]

Awesome. Will take a look. Is there a doc anywhere to peruse on how to create a TypedModel rather than a InferenceModel ?

[kali]

Doc is not tract's forte... But calling into_typed() or even better into_decluttered on an InferenceModel should do the trick.

[alexander-camuto]

awesome -- switched over to TypedModel and it has simplified our code quite a bit :) thank you for the tip