Re: [PATCH v7 08/10] accel/rocket: add RK3576 NPU (RKNN) support

[Jiaxing Hu]

Hi Igor,

SIZE_E_1 stays at 0 and the diff stays as it is. Your reason is better than the
one I would have given: a register built from the trace with one field swapped
to upstream's value is a configuration nothing has ever run.

I crossed SIZE_E_1 with the channel count, seven values, with the control beside
each one in the same boot:

    N                      16   24   32   40   48   56   64
    SIZE_E_1 = 1  written  16   24   32   40   48   56   64
                  correct  16   24   32   40   48   56   64
    SIZE_E_1 = 0  written   8   24   32   40   48   56   64
                  correct   8   24   32   40   48   56   64

Six of the seven are identical. At N = 16 they are not: upstream's 0 asks for
sixteen channels and delivers eight, in both the words written and the count
that comes out correct.

So your conservative choice is right, and one shape in seven is what two shapes
could never have found.

Two corrections I owe you. The first version of this reply said I had not run
the cross sweep, and I had; the round is named after you. And I nearly handed
you an old floor(n/16)*16 shortfall as a possible SIZE_E_1 effect, but the
traced value writes all 24 at N = 24 in this round too, so that one belongs to
the channel count register and not to this field.

Separately, on the int4 path at 64 output channels, SIZE_E_2 moves the words the
block writes but not the channels it computes:

    SIZE_E_2       1    2    3
    words written  32   36   40

and the correct count stayed at 32 in all three. Additive in fours, not in
sixteens, which does not sit well with the semantics I sent you on the 17th. It
is a different register value on a different precision, so it does not refute
the reading for the path it was read from, and I am not going to pretend it
supports it either.

The re-run offer is noted and I will take it when v9 goes. Glad the trip was
fine, and I hope the countryside is treating the board well.

Regards,
Jiaxing