From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-a4-smtp.messagingengine.com (flow-a4-smtp.messagingengine.com [103.168.172.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D27B93E0750 for ; Mon, 17 Aug 2026 09:45:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.139 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786959956; cv=none; b=QO3t/qaDMQpfX0fCXfZGhhJZto2IpfSoDTpsVqcoWze8d94cJwnpkcmb2FQqEPbp0379tDhodlJP6jNsThzcJa7JpwjlrmGvDU0cBfpvCqlWG0iRspX3KZ12HLzYnOEJ3dp2MfaBE12+qKdRxx307ZnkVDFrTZYx7DyV6TYonuo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786959956; c=relaxed/simple; bh=QMc25AD9FI0xx6FoYVwdwblU/h6U7Gdh/1plFCeQMTQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Y0QZSc9E89HL1iXgTCENNRnF0qwZmA5uIA/xfMa4W4xNNpmDqk3hnNhmOe9fyK9g4laPkMpw6MIG6pb++xxWK6/c/3HXBMXDyxisSgrTCn0dflrZsMMwDRGy9dis5wm9I1XUjekHPSlcIeJpQ7NSolcJCDFzWHJTBpukv3/UZPQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com; spf=pass smtp.mailfrom=gahingwoo.com; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b=sAR/TxMF; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=Fr6roOJR; arc=none smtp.client-ip=103.168.172.139 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gahingwoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gahingwoo.com header.i=@gahingwoo.com header.b="sAR/TxMF"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Fr6roOJR" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailflow.phl.internal (Postfix) with ESMTP id CD2C713802AE; Mon, 17 Aug 2026 05:45:53 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Mon, 17 Aug 2026 05:45:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gahingwoo.com; h=cc:cc:content-transfer-encoding:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1786959953; x= 1786963553; bh=KMiX0lpuCdiMpiwzWoB9LVEm9l7oTA1Ip8S52pJKwGo=; b=s AR/TxMFWmNopDZS4zzIHNdMQ8KhExf9auUe0Ix6oOyiM/iOBqDLSLS7mAOtEnlbB +iXHjnasYcL+ChYyPJitlj1KiHOTkuSdhrii4G48/RzfxkOT+E996zdoSeZqkRYv 2TLu8UgerFSFgiMaui8rz1W2RuaM5p6euodXKZc9mzScAm9DPmPEq/EWa1Rgjt7o +EHJdnxE7rlWgN6xNaVfTkETyb/Knf5rCG85OK4RUo8EkWZCN1e7H9YjzVtkPSlr wnbbLfbfxXYc/MFoCRah96QS+2LfIid1A34d5/xaQEAvu+pc41ONxMYBjz8umjpY eFUBFgPdttO757nyu6qGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1786959953; x=1786963553; bh=K MiX0lpuCdiMpiwzWoB9LVEm9l7oTA1Ip8S52pJKwGo=; b=Fr6roOJRV4MVuiai+ R/Q1cw5k8imuJY83GFFZvG8oz8A0H/aq99jt286HGIHzKMXAzab3Ia4Hro49fAAa LoAappbPzQF4Nd8/XMKdc22irHCZLw4DH5OcpYilqAPj9ogjJJGeLPi9A8tNljc8 pb1wzV1UFmRBXri8xcZ2H2mi3zz8oLddg6vSX1bTLk9buKrtg72Yawc6RvG4EjTX ONwQJr9HLsSS1icjc06fn0AhKNYzRF1B9dtAJkGKDH0TiJvzNCU1KwxTAWVLoyi0 jMbwhtFZvMyqr0L3mdG+xoFx2U2qKl2ljZdjGCVhSU+ZDL7UKhlkNGoUdvDKbdkz /r8Pw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEW/5JOkdI3iXwa6dLGZb2VIfdQ9j3pTYauZ3twR3nWWZHun4Wug0NVbCvnVLGFzF qLCeelooNbSVomgngrCbN2qyOwXWXWTPuLsmf8+i+1vXwulmrRcfcDlFRvuzUIYM7gogH0 fEqlCuYDu2h38EKc6+PeMHzjIX5Koyql5vFR6fLjqDdLAFYpYRe0JBMB7Ii3Axa2BcPleq TUUyYnZFPRz3CxWeWhgopvJCgcH3QiMljuEhIrisY+1cotyf30xbcGRC59KJZaAFy4fOtk G4z7rcGaXdOcfa4iidylBWK+jpPPzpwesm0xHDYJF85xyGbTzN0kLKDQ1HSzYwnnyQa/Ku WPa8Wj2WsuAA6qbnYat/CASXOerAXUMLyjexRJ2HMK/VUiew61buK8OOa46/BiO1Y7yZSE oyvUe1sYppRSj6DTAHQtbXyoEWYeOKLmnb2jWLMCKFNiHuXbiDzS/UbQGPtj2MRzY9Fm2T PDauUqNnNHBzpqf6dXzG98RWEK5ECC9vXMQnWtXppYxHQQajRpLNQRLEdMSwCMrs2u9uGw xs8xKwdvfaQWWMq6Wgr2ikw1GMnqf0Y0L4p1Buwmln6xTUN7vlq27PDJ/yRv70UV7eM8hn x27IRKDNuEPYelcNoMzTC18SIVsoI87JmO/TT6VHqBNz1yalCs40HSJfTxiA X-ME-Proxy: Feedback-ID: i7a5e4b5f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Aug 2026 05:45:47 -0400 (EDT) From: Jiaxing Hu To: royalnet026@gmail.com Cc: tomeu@tomeuvizoso.net, heiko@sntech.de, chaoyi.chen@rock-chips.com, 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: Mon, 17 Aug 2026 21:45:44 +1200 Message-ID: <20260817094544.1159366-1-gahing@gahingwoo.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Igor, Here are 88 and 120 on RK3576, with the 56 from earlier in this thread as a third point. A channel counts as matching when its maxdiff against the reference is at most 1, which is how perch.py scores. oc parity form modulo form, ROCKET_DPU4050_MOD32=1 56 56 of 56 32 of 56, timed out, lost 32 to 55 88 88 of 88 64 of 88, timed out, lost 64 to 87 120 120 of 120 96 of 120, timed out, lost 96 to 119 Under the modulo form each count keeps whole groups of 32 output channels and drops the remainder, and all three of those runs also raise the driver's job timeout. Under the parity form all three compute the whole output at a maxdiff of 1. What the three points cannot tell you. 56, 88 and 120 are all 24 modulo 32, so the twenty four lost channels are forced by the arithmetic and are not corroboration, and the rule is untested at every other remainder. A count of 40 or 72 would say more than a fourth one at 24. The modulo numbers are read back from a job the driver declared timed out, so the obvious alternative is that the job died before writing the tail of the output. The log argues against it. At 120, nine of the twenty four wrong channels carry enough varying output to fit a line against the reference, and the surface reports 45 constant channels of 120 with 37 of those pinned at the output zero point, so the lost region was written rather than left untouched. ROCKET_DPU4050_MOD32 occurs once in the whole Mesa tree, inside the value expression for 0x4050, so at a given count the two register streams differ in that word and nothing else. That is an argument from the source, not a measurement. I meant to measure it at 64 output channels, where the two forms emit the same value by construction, and only got one side of it. Without the knob it was 64 of 64. The run with the knob did not complete, the entry hung after the 88 run had timed out. One confound to disclose. 88 both ways and 120 under the parity form are one boot. 120 under the modulo form is the next boot, on a kernel that also carries an unrelated power domain change, and the NPU rail reads enabled in the first and disabled in the second. The Mesa build is byte identical across the two and the modulo form times out under either kernel, but the 120 row is not a single variable comparison and should be read as two. If you still want the RK3588 side, ROCKET_DPU4050_MOD32=1 against your own build is the comparison. Jiaxing