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

From: Igor Paunovic <royalnet026@gmail.com>
To: Jiaxing Hu <gahing@gahingwoo.com>
Cc: Igor Paunovic <royalnet026@gmail.com>,
	Tomeu Vizoso <tomeu@tomeuvizoso.net>,
	Heiko Stuebner <heiko@sntech.de>,
	Chaoyi Chen <chaoyi.chen@rock-chips.com>,
	Alexey Charkov <alchark@flipper.net>,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 08/10] accel/rocket: add RK3576 NPU (RKNN) support
Date: Wed, 19 Aug 2026 20:48:33 +0200	[thread overview]
Message-ID: <20260819184838.6723-1-royalnet026@gmail.com> (raw)
In-Reply-To: <20260819154634.7584-1-royalnet026@gmail.com>

Hi Jiaxing,

"Coming days" turned into "same evening" - the harness already existed,
it only needed your question. Both halves below; raw npz kept for all.

1) Forcing outputs below the zero point on RK3588.

Model built to your exact case: 1x1 conv, out_zp=128, no fused
activation, bias centered around zero so the outputs fall on both
sides of the zero point (59% of the raw reference material sits below
it at oc=56, 46% at oc=128). Open stack, mesa main (bf70ab68a21),
which ships no lift - the pre-fix state, so nothing in software can
be compensating.

  vs raw CPU reference : 56/56 and 128/128 channels within +/-1
                         (47 and 113 exact), global maxdiff 1
  vs max(cpu, zp)      : collapses (0/56 channels, maxdiff 128)
  NPU values where the raw reference is below zp: min 0 - they pass
  through freely, nothing pins at 128 (0.6-0.8% of values happen to
  equal zp, consistent with the reference)

So on RK3588 the output stage does not floor at the zero point with
L=0. The floor you demonstrated on RK3576 is real there - your
three-run experiment stands - but it is not an unconditional trait of
the family silicon. Which of your two explanations that favors for
the vendor's per-model 0x40ac values on RK3576 is yours to judge; what
it removes from the table is "unconditional in the family, so the
compensation must be hiding somewhere on every SoC". Here there is
nothing to compensate.

Reading what the vendor stack programs into A on RK3588 needs the
vendor runtime, which this bench machine does not carry - if the
below-zp result does not already settle it, I can set that up after
Aug 30 (travelling from tomorrow).

2) The remaining discriminating counts.

oc=50, 60, 90 and 114, same protocol as the 17th (raw CPU reference,
no clamped comparison, zero constant reference channels in all four):

  oc=50 : 50/50 within +/-1 (43 exact), maxdiff 1
  oc=60 : 60/60 within +/-1 (53 exact), maxdiff 1
  oc=90 : 90/90 within +/-1 (78 exact), maxdiff 1
  oc=114: 114/114 within +/-1 (98 exact), maxdiff 1

No channel pinned at the output zero point in any of them. Together
with 56/88/120 from the 17th and the earlier 20/33/40/48/72/100, the
RK3588 side of the discriminating list is now complete.

Regards,
Igor

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip