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

[Igor Paunovic <royalnet026@gmail.com>]

Hi Jiaxing,

Thank you for running the sweep, and for the shape of it - one field at
a time with the other four held, three baselines with no drift, and the
honest reading of RESERVED_0's score printing after its timeout. That
table is worth more than the five lines it occupies.

On SIZE_E_1: I would keep it at 0, and I would not shrink the diff.

My reasoning, for what it is worth from someone without the hardware:
your sweep just demonstrated that the traced value is load-bearing in
four of the five fields, failing in three distinct ways. That gives the
trace as a whole its authority. A register built from the trace with one
field swapped to upstream's value is a configuration that no silicon has
ever run end-to-end - not your RK3576 (which ran 0) and not RK3588
(which runs a different register entirely). Keeping 0 keeps the value
honest to its source, and your comment saying it was measured not to
matter on these two shapes preserves exactly what is known and no more.

One question in the same direction: by the SIZE_E semantics you derived
on the 17th (SIZE_E_n + 1 = the number of 16-channel atoms in the last
bank), would different output channel counts exercise different SIZE_E
fields? If so, two shapes cannot rule out a shape that leans on
SIZE_E_1 specifically, which would make 0-as-traced the conservative
choice as well as the honest one.

And thank you for being exact about the tags - 1/13 carrying, 2/13
dropped because it is no longer the patch I tested. That is the right
call, and saying it on the thread when v9 posts is better than either of
the quiet options. The re-run offer for v9 on RK3588 stands; the harness
is set up and travels well.

The trip went fine, thank you - I am answering from the countryside,
with the same board on the desk.

Best regards,
Igor