From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 76A383F58C4 for ; Mon, 17 Aug 2026 10:01:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786960867; cv=none; b=kuajz22uKYeyt+Ry7M/zqpolukPqJB9AhhubcQocH662KNYOwkiVCaVI1/+17O4I++zvzU0hURKUX5icOUF247FpVQ16sy7kQvovVPJHXgc4DIB7vb9j0SRvn1RIH+YPlpy4GcxZ48/K2EtldTiHTafSGTtOSdKQISGPV28yUJM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786960867; c=relaxed/simple; bh=t3nFoVcyMbF/lp2RCPng2x3hQ+Sy3yAcHKMOwteJLNw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Kl75PZDO9Z+qOfR+fDScrWhyJdhw8vBOEpKWAI/SMC4o6hCdWxAd53DNDT0pqOeURaWBegtRP7N+dkZRDFhcam5GmrJR4MxLtCeNXHGz+cMTC63MNuAFTec9Jb1IrycfM0vmHgW3Oa0vUPmOyCuHFm3RGEd76RlejYZPCJqw9/E= 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=U9Ae26+X; arc=none smtp.client-ip=209.85.221.42 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="U9Ae26+X" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-47fe45db360so404087f8f.2 for ; Mon, 17 Aug 2026 03:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786960858; x=1787565658; 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=C5xJAp5EsJh4mtoVRdetKKnVuOabsV+/QbXlIN6U2H4=; b=U9Ae26+XeFpSz9EBrA7ovSRG4yGskZF3F3vP6NYbnuoxlr28l1OD0oByD/vdKym35p lhT+kYSJ+X+xboC17Wjwqbj3U2niC4YQ7Bw2aDZsMsmml8UmupKTf3TauZzJc7ohMRq1 6xDlz3/NHdIT9S4aon2woprnCE231lVY/RFVcqXSWnxj/OWXrcelQcVtqWPiP+yOi+1c +73ZtM35TgODoMlA5xVuk5r9tGEKDvmu5ojH0xYFjTIxYGUWlm1nSIe7eVw6R5icPVN8 H2J9VXSOkTCNdPGKlQXH5OnvSokm0LDFYZWmulTJnSu//Be4T3zPOmnpI9uFhz4i0eO0 dZNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786960858; x=1787565658; 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=C5xJAp5EsJh4mtoVRdetKKnVuOabsV+/QbXlIN6U2H4=; b=A77/TUSS8b3fa/ktG79J49MxSwHKo3Lvfgo7qAnK3VrSecXf32BJgoolybvq7DHefF /4EFA/stKhNx9VqCpUwFcXumumWVnLljrKEiOu2+AG2xWgA8TNjuVobGK8n/WYIN9wzf +9MDgFc50sb/EXkTyMQTkM55QHgCjpGFqlVL70x0specrkS99fn87VQhLP1tLM0h2fdT DtJ9ghxBaxzFdX7zx8qLghXG1i+lSLVUCo8uYw5/4FrmwScMUbl9hhh+uWu715uuiXx6 c91BGZMYVCvswb1A+Cmfzv7xILDiG+e0FjN8nH6ZGzwLAsy2MilCI+/i2gSlLPLpLx9b KGQw== X-Forwarded-Encrypted: i=1; AHgh+Rpd6ocpYNl49n2AfaqeV1ALDT3aEoqLWw9TAC7hrhB4F51s1ZLDeHHDCwW8VzXdqJWDeB9iL71V0nu70qA=@vger.kernel.org X-Gm-Message-State: AOJu0YwKhqL3n/HioB9nlzFwpTCTBW4opU+OqAIu873EUmjeGtpzf76n AWIeJakKRDzW3oamQo5QTDLnik4sYiiLmtDyq8DYS9xUJLQ4ZXdsst6J X-Gm-Gg: AR+sD11qH0zMZ1XsP8xzGUtCL0EB6p5MqpJCjCzATj1QEIH68YPA4IeQEpD9X3Ct0aY yjTW/RWUc549+Tz7kZQG32Td1FxL4K/oUnxKgFosP3zBXF6BUQxnrGNXgDpFFeT47l2k040oXLs ZV6wGSRtveL281I/FSEss59uKl76BlOx8Dp5dIA8qi7gvQaTRXwshXlPImP25aHx7BfXVjA2xe0 VGbCqGmCW6LCG4bBt98EFP4kZz00AuJZCuJSPtnskGpjhPeF3kooDcgxEDVRcCU4NMvtorn73E4 mpAItGbPHs2utz6dutG+jV2xH0JGdkuw/G0L9FAUnzL76dAp3e2EfWr7Wg2FmKtIXFSiHKv9wr+ J03C5qgBYyKBwrxpevS0lJS/uh8TYh6Ap2DRS4P341hA00HlBwu2707bKQXlGMBI4Ww4IBKjBiu rS9oxFfRqFb6kVwNQXBpCWMZhhUVJRORbWJl3287WrY3u4HY7MZF5MROr3FL2GY6jcO4DMQrsUf 8NbxITmx1bjH6YFZsJrgI21H0hOZjATJEIz4n6ACjOJUd+2dzfijxmFjtLc/TB8IF1SBA== X-Received: by 2002:a05:600c:a0d:b0:498:1371:660c with SMTP id 5b1f17b1804b1-499878d5e0dmr175209465e9.0.1786960858323; Mon, 17 Aug 2026 03:00:58 -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 5b1f17b1804b1-49996109652sm167889155e9.4.2026.08.17.03.00.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Aug 2026 03:00:57 -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 12:00:43 +0200 Message-ID: <20260817100046.24872-1-royalnet026@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260817094544.1159366-1-gahing@gahingwoo.com> References: <20260817094544.1159366-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, You asked for a count that is not 24 modulo 32, so here are five, on RK3588 with upstream Mesa. Same generator and same scoring as the 56, 88 and 120 rows earlier in this thread: 1x1 conv, 64 input channels, uint8, output zero point 0, scored against the raw CPU reference with a channel counting as matching at maxdiff 1 or less. oc oc mod 32 matching bit exact 33 1 33 of 33 31 40 8 40 of 40 34 48 16 48 of 48 40 56 24 56 of 56 47 (16 Aug) 72 8 72 of 72 62 88 24 88 of 88 81 (16 Aug) 100 4 100 of 100 86 120 24 120 of 120 106 (16 Aug) Eight counts across five distinct remainders. The upstream constant computes the whole output at every one of them, and the global maxdiff is 1 in all eight runs. So on this SoC BS_OW_CFG needs no term in the output channel count at any remainder, not just at 24. Controls, same as before. No channel of the reference is constant in any of the eight models - the generator refuses to emit a model where one is, since a constant reference makes a trivial match. No NPU channel is pinned at the output zero point. The NPU interrupt counters went from zero to five across the three cores over the five new models, one job per model, so each of them reached the hardware. And the counts that are not bit exact are off by exactly 1, which as you noted is not something a delegate falling back to the CPU produces. What this does not say: it measures the upstream form only. It is not a statement about how the modulo form would behave on RK3588, and it does not touch your timeout observation. Which brings me to your last line. I cannot run ROCKET_DPU4050_MOD32=1 against my build, because the knob is not there. Upstream Mesa has no occurrence of it anywhere in the tree, and src/gallium/drivers/rocket/rkt_regcmd.c emits BS_OW_CFG from the depthwise flag alone: if (operation->depthwise) { EMIT(REG_DPU_BS_OW_CFG, DPU_BS_OW_CFG_SIZE_E_2(3) | DPU_BS_OW_CFG_SIZE_E_1(3) | DPU_BS_OW_CFG_SIZE_E_0(3)); } else { EMIT(REG_DPU_BS_OW_CFG, DPU_BS_OW_CFG_SIZE_E_2(1) | DPU_BS_OW_CFG_SIZE_E_1(1) | DPU_BS_OW_CFG_SIZE_E_0(1)); } which is 0x36c and 0x124, with no output channel term in either. Setting the variable on my build would be silently ignored, and I would have reported a null result as if it meant something. So: send me the value expression your knob selects at 0x4050 and I will patch it into my tree locally and run the RK3588 side of the comparison. I would want to run your oc=64 control at the same time, both ways, since that is the one where the two forms emit the same value by construction and it is the cleanest discriminator you have. You got one side of it and the other hung. I can run both here, and I can also give you 40 and 72 under the modulo form, where the remainder is 8 rather than 24. Two things I want to acknowledge rather than skip past. You flagged the mod-32 confound yourself before anyone asked, and you were right to, the twenty four lost channels at 56, 88 and 120 really are forced by the arithmetic and are not three independent confirmations. And you disclosed that the 120 modulo row is a different boot with an unrelated power domain change and a different NPU rail state. Reading that row as two points rather than one is the correct call, and saying so in the mail rather than after being asked is worth more than the row. If it is useful to anyone, I can send the generator and the scorer. The generator builds the flatbuffer by hand and self-checks against the CPU interpreter before emitting a model, and the scorer is your perch.py logic reduced to this one case. Regards, Igor