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

Hi Igor,

Nothing gates v9 on your side, so please do not reorder anything. It is held so
v8 can collect more review, not to wait on a measurement, and ten days of travel
beats my patch queue.

You offered to set up the vendor runtime once you are back, to read what it
programs into A. Please skip it entirely. Reading that on RK3588 cannot separate
my two explanations, because your run has just shown there is no floor on RK3588
with L of 0. There is nothing for that A to be compensating, so whatever it holds
says nothing about which of the two is true on my SoC. Saving you that setup is
the most use I can make of your result.

The measurement that does separate them is on RK3576 and it is mine. The
vendor's coefficient buffer is built at load time and is not in the .rknn, but
it can be dumped from a live run and I have done that. Doing it for a model
whose output actually falls below its zero point, and asking whether the
vendor's A carries a lift, answers it. If it does, the compensation was hiding
in A. If it does not, there is an enable I have not found. Either way it is a
board round here.

Your result changed the shape of the question. I had two explanations and no
reason to prefer either. You have removed the one that was doing the most work,
that the floor is a family trait and the compensation therefore has to be hiding
on every SoC. It is not a family trait. So on RK3576 the difference between the
vendor stack and mine is something in my configuration, on silicon where the
same 0x40ac expression demonstrably does not floor the vendor. That is a much
smaller place to look and all of it is on my side.

Thank you for building the model to the case and not to the shape. Bias centered
so the outputs straddle the zero point, 59 percent of the raw reference below
it, and mesa main so nothing in software could be compensating. It answers the
question I asked. And the collapse to 0 of 56 against max(cpu, zp) is the
control that says the comparison was live.

One precision on the counts. Of the thirteen you have covered, eight
discriminate, and those eight land on five distinct remainders modulo 32, which
are 18, 20, 24, 26 and 28. Ten remainders in the range still have no data on
either SoC. That is far past where 56, 88 and 120 left it, when the three were
one data point repeated, and it is short of the whole space. What it establishes
is that the upstream constant computes whole on RK3588 at every count anybody
has proposed, with no channel pinned at the zero point in any of them.

Regards,
Jiaxing

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip