Add export for Gemm and MatMul operators

This is required to advance on compile export.

added Missing PriorityHigh labels

Thanks for entering the issue, it will be useful for testing known workloads with MatMul for compilation experiments. Also, I have seen some final layers of graphs implemented with Gemm (even if it is actually just a 1xN dot product), it will be useful for testing either graph simplification at the node level, or optimization at the compilation level. I mentioned the two at the same time as I suppose that for the default export CPP template one can be simply implemented from the other.

Gemm is imported in Aidge has a fully connected (FC) and is supported in this export : https://gitlab.eclipse.org/eclipse/aidge/aidge_export_cpp/-/blob/dev/aidge_export_cpp/kernels/fullyconnected.hpp?ref_type=heads

So only the MatMul remains

For Gemm, I see that there are limitations in the attributes support for Gemm when importing:

• transA, transB for inputs transpose must be 0, 1
• alpha, beta scalars must be 1.0, 1.0 Actually I'm interested to see how transposition and coefficient should be handled from your perspective. Add a Transpose nodes and mul nodes?

In fact, sorry for the possible confusion, actually I expected to be able to create a aidge_core.Gemm operator, and have it exported, but I understand now that the transformation is done at import onnx time. Perhaps it may be possible to factor out the recipes that transform the onnx.Gemm (and others) into the aidge_core subgraphs, and use them at onnx import time. But also make these recipes available if the user wants to create a aidge_core.Generic "onnx.Gemm" operators when constructing directly a aidge model. This would probably be mainly targeting testers and developers of the platform though.

By the way I created a simple pull request for the export_onnx() of MatMul on aidge_onnx project. It actually helps me going back and forth on the different formats.

I see no assignee for this export of MatMul. I can contribute it if you want, tell me. In this case what is your advice? Should I reuse the FC implementation?

Hello Christophe,

Yes you can assigne yourself to this issue, we gladly appreciate contributions

Indeed, you can fully reuse the FC implementationand remove the bias !

Cheers,

Cyril

Assigning myself (note that I can't actually change the Assignee of the issue as I'm not a project contributor), you may do it for the record.

@cmoineau, I pushed MR !18 (merged) for the implementation of CPP export of MatMul. I let you comment/merge.

assigned to @cguillon

Hi @olivierbichler @cmoineau , actually I would like to have more clarifications for the import of Gemm in aidge_onnx as a FC operator (ref to https://onnx.ai/onnx/operators/onnx__Gemm.html for the Gemm definition):

• For the case of the C (i.e. bias in FC), it should be unidirectional broadcasted to (M,N) (i.e. (batch_size, output_features) in FC), but:
  • FC does not implement broadcast on bias
  • I haven't found a broadcast operator for instance to generate: FC(A, B, broadcast(C))
    • even if I would, in this case I do not think that dimension forwarding would work as basically inferring dims for the broadcast would require knowledge of the downstream dimensions of FC itself inferred from A and B
  • related to this last point, can you confirm or not that the onnx importer should support import of onnx graphs with non forwarded shape information? I think it is the intent, but of course it means that at onnx import time I cannot force the broadcast dimension in this case as I do not know shapes for A and B. Looking at the onnx operator, they have been designed to have forwarded dims fully defined from inputs even in case of implicit broadcast. This means that for aidge we should be able to at least do so, in which case Gemm can't be converted to FC, unless we improve FC to do implicit broadcast of bias.

I would like to have the broadcast working for Gemm, could you advise?

closed