feat(cli): show attribute values encountered in the model in 'nnx info'

[pixelspark]

This changes the CLI's info command to show not only the ops and attributes that are used by a model, but also which distinct values these attributes take. This allows me to more easily see if wonnx will support a model (some ops are implemented, but not all attributes or attribute values are supported; e.g. the #58 implementation of 'Gather' only supports the common case with axis=0 but not other values).

Example output:

+------------------+---------------------------------------------------+
| Model version    | 1                                                 |
+------------------+---------------------------------------------------+
| IR version       | 3                                                 |
+------------------+---------------------------------------------------+
| Producer name    | CNTK                                              |
+------------------+---------------------------------------------------+
| Producer version | 2.5.1                                             |
+------------------+---------------------------------------------------+
| Opsets           | 8                                                 |
+------------------+---------------------------------------------------+
| Inputs           | +--------+-------------+-----------+------+       |
|                  | | Name   | Description | Shape     | Type |       |
|                  | +--------+-------------+-----------+------+       |
|                  | | Input3 |             | 1x1x28x28 | f32  |       |
|                  | +--------+-------------+-----------+------+       |
+------------------+---------------------------------------------------+
| Outputs          | +------------------+-------------+-------+------+ |
|                  | | Name             | Description | Shape | Type | |
|                  | +------------------+-------------+-------+------+ |
|                  | | Plus214_Output_0 |             | 1x10  | f32  | |
|                  | +------------------+-------------+-------+------+ |
+------------------+---------------------------------------------------+
| Ops used         | +---------+---------------------+                 |
|                  | | Op      | Attributes          |                 |
|                  | +---------+---------------------+                 |
|                  | | Reshape |                     |                 |
|                  | +---------+---------------------+                 |
|                  | | Gemm    | transA=0            |                 |
|                  | |         | transB=0            |                 |
|                  | |         | beta=1              |                 |
|                  | |         | alpha=1             |                 |
|                  | +---------+---------------------+                 |
|                  | | Relu    |                     |                 |
|                  | +---------+---------------------+                 |
|                  | | Conv    | auto_pad=SAME_UPPER |                 |
|                  | |         | group=1             |                 |
|                  | |         | strides=<INTS>      |                 |
|                  | |         | dilations=<INTS>    |                 |
|                  | |         | kernel_shape=<INTS> |                 |
|                  | +---------+---------------------+                 |
|                  | | MaxPool | strides=<INTS>      |                 |
|                  | |         | kernel_shape=<INTS> |                 |
|                  | |         | auto_pad=NOTSET     |                 |
|                  | |         | pads=<INTS>         |                 |
|                  | +---------+---------------------+                 |
+------------------+---------------------------------------------------+

[haixuanTao]

So, if one Op Type is repeated several time within a graph, the attribute that is going to be outputed are only referencing the last Op of its type.

Shouldn't we maybe try to output: A) the different configuration of each existing attribute within an op type B) the different configuration of op type that are present within a graph

[pixelspark]

So, if one Op Type is repeated several time within a graph, the attribute that is going to be outputed are only referencing the last Op of its type.

It will actually output all diferent values used for the attribute of each op. If there are e.g. two Split ops in a model, one with axis=1 and one with axis=2, the table will list Split: axis=1, axis=2 (however, this only works for simple attributes; something like Transpose has perm=<tensor> which will show up only once as perm=<tensor> even if different instances of the op use different tensors. This prevents the table from flooding with large attribute values.)

Shouldn't we maybe try to output: A) the different configuration of each existing attribute within an op type B) the different configuration of op type that are present within a graph

Yes, that would technically be better, as in some cases the attributes interact and you'd want to know which combination is used (e.g. Gemm has transA and transB booleans, so already four combinations and it might be the case that one combination is not implemented while the other is).

This is however a bit trickier to implement, because we would also need to take into account default values (e.g. transA is false by default, but if one op instance explicitly specifies transA=false and another just omits it, the CLI would show it twice, once without attributes and once with transA=false, unless it somehow 'knew' what the default was).

[haixuanTao]

Ok make sense. I was saying that because I knew that for conv the strides values are not always the same,

Ok in that case I don't see any issue with this PR.

[pixelspark]

Ok make sense. I was saying that because I knew that for conv the strides values are not always the same,

Ok in that case I don't see any issue with this PR.

I see. Well, we can always expand the info provided by the CLI command. For now it serves as a quick way to check ops used by a model (you can always open e.g. Netron to see it in more detail, or just run it and wait for the UnimplementedVariant errors the compiler will throw at you :-)). So, let's merge then!

[haixuanTao]

Yep. Exactly! Feel free to merge both PR in the order you see fit. 🍻