From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B2943FA5FE for ; Mon, 17 Aug 2026 11:06:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786964789; cv=none; b=aahPJhpjG9MAUn06yNc2uPuNKP1dIoTjOTZ/05TRYg3wuvUfXqoIoKo1T7b87leLVcTB7ajd6D6W1rQWaOLHHrF6VWSU4bGKfDHxgiTp1bdKTfU+wMDraWfkVTxBp5oVToWu/NNIqEPRBY9KVajgsGNafhlfEtSEMqvJrlXnyPA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786964789; c=relaxed/simple; bh=SDklBHd1DC/bye3ts5+TutouqVHdeYGmMcE4K3luVRM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DeD9XS8GGnQyF0aySCtjvMRO++OTnN20B/JXWoubxwXbtd4n/7yzWTcakIW9swAI0Owe1+NTlLmyLItaxNDE7YF+A2pRshr5Xgfta+ef0jZDs2/NsG++hmLmjr+x1ti3PpF1c+P1SqnkVOutboLgif1A3KSHt4/he2+nq2xl+IY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PDRnd9rI; arc=none smtp.client-ip=209.85.221.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PDRnd9rI" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-4706f016316so178422f8f.3 for ; Mon, 17 Aug 2026 04:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786964783; x=1787569583; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=6OwP5HDWaliFgti3Iscv9ilvEY9jqmGVYGbAyk7tFDg=; b=PDRnd9rI+hpliWTCM/lT6lGB/o+Zrw7SDV9YaXoz4D7oW4QMCxyNEVhPxuWYhuVDCl uj2bCSbgzs/FLcdWhfluGMWNbF8j5aEX1yaKg2yOYbzqomMLdh4x4fxl9VDi+gJ4tsdF kN80vCm761v2b6K4YDIiuDNymqhFjM90SYJQSO+pL9GLGLT1WO6XIIoOpl0z6nHkMXnu pqXkmgSe4tzA4PiQHHF0W5t48refjCF8xPr8C+l8EEKcf+1wbEvaJf0CupZA97lF3+jw ThuARZ46eugGSI8/wd0CgMIo0vlawhzC4OPO1amaWhs3FvC2ohhTHaM8fUDapiZ744KY uSXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786964783; x=1787569583; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=6OwP5HDWaliFgti3Iscv9ilvEY9jqmGVYGbAyk7tFDg=; b=USMjM/aCiUxQk1rtmFjNHO247RCTHsV4jOyBPPNsFDDAL9x4WMRgVAFbLjKdB0YRjC ihXUuFWAIPrrRGf4QYFhgGawhQ3EB0Q1JCtJw8xrBvAMRxSEK736775rSAZGPZUVaVDJ V2igOLcfyq5le+TQcm3sP6vAKDAZjF2fF7LwWW+FQPxmZdY14Wg4FjGx8TvzjX5Iyfxn SAG/2YTacrA4tpSSReSAF/qURwX+OSG2fxEgsETWvduhwcpI0O3RtAKk3KdVDmtH8Azr 6712QHIiT+N/bsbSQtp4IGCwk8zS/xJ1AgVXYvUhDaFZcTNxJBWzP3gfnMEzvJwyQDdT cNBw== X-Forwarded-Encrypted: i=1; AHgh+Rq5ZXZnBWFDO8ma+SivtjjTJ024AcpP+hZmxR0rg7i6z6WQTP9BQdT7CKG8U0NoLcN7Embon3AhQm5a/RM=@vger.kernel.org X-Gm-Message-State: AOJu0YxnAld1kjcGEvOeZvNcuavl5aPq6pm9/gO2x6rNOWIQX6FZpfJG c/gOD3rnTpvA2OsN1kcs+ojb3vTdV1ELNhCuqtbglP6RuFO71MlGANDQ X-Gm-Gg: AR+sD119J/rb0ls9sqI37m7s0UgCFCXRQSclKsHU8I/7H+Y0Gpuwf3ibOpY9606UpNB zWJSB/w+vgivp/r6PH4np4XnMNbrgyNBVW5mzOoGgqbtHu5QX7DZg6jFGF+fjYJGt+9tIfcsHoo Sy3PmGuIexwnU4ChRQZ2dtYEkZfVua+9qWx1Z52ZCY0N3NHfmuxkxO59dwJIIyhG/3dypmMk9Zp KIaup78p96F7qkb8cKG4cVGSTIzP83oJzbVf8OUsBRUtO9Q7mghlGeMju7acISWa+qqe2D8y608 d1bo3bjB6J2ljUSS/hr+A8Q++wzf8z47dTE14r9NLa34pG6l5ZwE9jHKT2kXv8QmiqvCBk4cEkV XrXxSw4mhBCQ2o1UR1baecRSuDJQ+3AsoEtmFcjnaGQI9mUJsgRE1L1tZl+lMZW7ymWiVKV3k92 DXUMOeuBzBJKrORMHOc+Hbf2id8EReDQ4QTL6MauRp1RLbeYvgTC9B2ZIpBQvvDaB+BMV2zucnW WP2rD7MTILZYOBdyKznFEvtKAI47TZ2s3HO9ZCo2X0CBkPErEf8jlMlzvmzCEiXJyhoIA== X-Received: by 2002:a05:6000:2585:b0:46f:7d90:8124 with SMTP id ffacd0b85a97d-481607738d1mr17922081f8f.2.1786964783101; Mon, 17 Aug 2026 04:06:23 -0700 (PDT) Received: from OrangePi5-Plus.BB-HOME (20014C4E1B8FC50027494B64639367E4.dsl.pool.telekom.hu. [2001:4c4e:1b8f:c500:2749:4b64:6393:67e4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-482a5a3b43dsm2982833f8f.12.2026.08.17.04.06.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Aug 2026 04:06:22 -0700 (PDT) From: Igor Paunovic To: Jiaxing Hu Cc: Igor Paunovic , Tomeu Vizoso , Heiko Stuebner , Chaoyi Chen , Alexey Charkov , 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 13:05:53 +0200 Message-ID: <20260817110556.31613-1-royalnet026@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260817102021.1226525-1-gahing@gahingwoo.com> References: <20260817094544.1159366-1-gahing@gahingwoo.com> <20260817100046.24872-1-royalnet026@gmail.com> <20260817102021.1226525-1-gahing@gahingwoo.com> 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 Jiaxing, Thank you for withdrawing 40 and 72 before I built anything on them, and for the field table. I checked the table against registers.xml and it is right in all eighteen cells, including RESERVED_0 = 34, which is bits 12 and 16 and is not obvious. I also confirmed the part of your reasoning that matters most: your two words XOR to 0x100, and 0x124 against 0x80011111 and 0x024 against 0x80011011 both XOR to 0x80011035. The five-field offset really is common mode across the two arms and cancels in an A against B. One thing I cannot resolve on my own before I write code. You wrote: "Use your own constant with bit 8 cleared instead, 0x124 where the predicate is true and 0x024 where it is false." The merge request line you told me to take instead of your branch reads R_DPU(0x4050, (DIV_ROUND_UP(output_channels, FEATURE_ATOMIC_SIZE) & 1) ? 0x80011011 : 0x80011111); which puts the SIZE_E_2 = 0 word on the true arm. Read with that predicate your sentence gives me 0x024 at oc = 64, where your merge request emits 0x80011111 and current upstream emits 0x124, both SIZE_E_2 = 1. Read with "the predicate" meaning output_channels % 32 == 0, your sentence is exactly your modulo form at every count. Both readings agree at every count with oc mod 32 in 17..31, so your five discriminating counts are unaffected either way. They disagree only at oc mod 32 == 0 and 1..16 - and oc = 64 is the count you said you most want. So, concretely, so that I do not guess: at oc = 64, do you want SIZE_E_2 = 1 or SIZE_E_2 = 0? And if you meant your own form rather than the merge request's, send me the expression. I would rather we name the arms by value and by count than by the word predicate, since it now refers to two different things in this thread. Now the part I think is worth more than the A against B. I went looking for what SIZE_E means rather than which value works, and I think it falls out of the padding. In upstream rkt_task.c the output channel count is padded to a multiple of 32 for the normal case (line 87, align(MAX2(oc, 32), 32)) and to 64 for depthwise (lines 88-91), and FEATURE_ATOMIC_SIZE is 16 (rkt_ml.h:18). So the padded bank is 2 atoms of 16 in the normal case and 4 in the depthwise case. Upstream writes SIZE_E = 1 and SIZE_E = 3 respectively. That is 2 - 1 and 4 - 1. SIZE_E_n + 1 = the number of 16-channel atoms in the final output channel bank If that reading is right, your parity predicate is not a fit at all, it is this same statement: I checked over oc = 1..512 with no exceptions that DIV_ROUND_UP(oc, 16) being odd is exactly the condition that the final 32-channel bank holds one atom rather than two. Odd atom count means a half-populated last bank means SIZE_E_2 should be 0. That is the reason you said on 16 August you wanted for the field, and it is arithmetically identical to what you already wrote. It also explains why my eight counts said nothing, which had been bothering me. Upstream hands the padded count to the write path, not the real one - rkt_regcmd.c lines 201, 226 and 247 all take task->output_channels, and only ORIG_CHANNEL at line 225 takes output_channels_real. So on RK3588 the final bank is always declared full, the atom count is always 2, and SIZE_E_2 = 1 is simply correct at every remainder. My five new counts could not have discriminated anything; they were confirming that upstream never under-declares the last bank. And it predicts your losses arithmetically rather than describing them. An under-declared last bank keeps floor(oc/32) * 32 channels, which is 32, 64 and 96 at oc = 56, 88 and 120 - your three numbers, including the lost ranges 32-55, 64-87 and 96-119. Please treat that as a hypothesis. I derived it from the encoder's arithmetic, not from a TRM or a vendor document, and it assumes the three SIZE_E fields are independent, which is the same assumption you flagged. It also does not touch the timeout, and I agree with you that the timeout is unexplained. What I will run, once the polarity above is settled: - oc = 64 both ways with the constant forced, no predicate in the build at all, so the ambiguity cannot reach it. I will patch only the non-depthwise branch at rkt_regcmd.c:239-241; clearing bit 8 in the depthwise arm would be 0x36c -> 0x26c, SIZE_E 3 -> 2, a different move. I will verify the emitted word from the submitted register stream rather than the source, because at oc = 64 real and padded are equal and a build that read the wrong one would be invisible. - oc = 20 and oc = 60 on stock upstream as the reference arm. Those need no patch and no answer from you, so I can send them whenever. They also add residues 20 and 28 to the table, which so far only has 1, 4, 8, 16 and 24. Generator and scorer are on the way in a separate mail. Two small things. Your sentence "modulo true implies parity true and never the reverse" is the wrong way round - parity true is residues 1..16, which is a subset of not-a-multiple-of-32, so the implication runs the other way. Nothing downstream of it changes. And your five are a sample rather than the set: below 128 there are sixty counts with oc mod 32 in 17..31, and odd ones are fine since 33 already ran, so 17, 25, 51, 83 and 117 would do just as well as 20 and 50. Regards, Igor