qcom_htp

The reusable recipe for putting ANY new hand-written HTP kernel onto the unified, trustworthy QNN-standard measurement (P2 tooling). Use BEFORE/AFTER timing a new GDN-solve-class kernel (bare-metal FastRPC, custom QNN op, dspqueue kernel) — it pins the build-flag convention, the reps2-N median + clock self-check anchors, the ONE canonical timeline tool (scripts/htp_timeline.py), the ONE perf-report generator (scripts/htp_perf_report.py, honest-tail serial floor §3 + §4 stats[] dictionary), and the gated PMU真值 utilization (GP_PMU_UTIL, §6 tier-1) that does NOT pollute the wall口径. Authoritative SPEC = docs/cycle_metric_alignment.md § "HTP Kernel Measurement Standard" (§1 anchors / §2 4-questions→QNN field / §3 honest-tail / §4 stats[] dict / §5 timeline stage spec / §6 utilization tiers / §7 report template). This skill is the HOW; that section is the WHAT.

The single home for how to COUNT and REPORT HTP cycles unambiguously. ONE vocabulary only — the QNN optrace fields (num_dominant_path_cycles, per-unit cycles_used, graph-wall span); all self-invented口径 names (op-latency/unit-busy/per-call-wall/domain/feed-inclusive/①②③④) are DELETED as meaningless. Use whenever you make a cycle/perf claim or an "ours vs QNN is Nx" comparison. Pins: QNN cycles == C15:14 PCYCLE (no conversion, bare-metal maps onto the same fields); THE rule = compare same field + same shape + same scenario; why num_dominant_path ≠ cycles_used (same op, two values: 370 vs 1388 on native 64³); the traps that give 2–6× wrong numbers (incl. regression-intercept-inflation — use the honest-tail for the serial floor, not a constant-K wall=K/P+b fit); and the 64³-custom-op-under-optrace recipe. Authoritative measurement standard + full manual: docs/cycle_metric_alignment.md § "HTP Kernel Measurement Standard".

Measure QNN HTP op/graph PERFORMANCE correctly via optrace in qcom_htp. Use this BEFORE making ANY HTP perf claim (op cycles, graph latency, "faster/slower", parallelism/threads). It pins the one metric that matters (WALL µs + per-op Dominant Path Cycles) and the exact ctxgen→net-run→decode flow, so you never again misread qnn-profile-viewer aggregate "Duration (cycles)" as wall.

The MANDATORY way to run ANY command on the test device (`ssh oneplus`, a termux sshd on the phone) — exec, upload, download, or probe. Use whenever ANYTHING touches the device: a one-off `echo`, deploying/running a bare-metal or QNN binary, pushing libs/inputs, pulling outputs, or a benchmark loop; and whenever a device run "hangs"/times out. The rule is one line: `source scripts/dssh.sh` once near the top of the script — that exports an `ssh()`/`scp()` override so EVERY `ssh`/`scp` (existing call sites included) plus the explicit `dssh`/`dssh_put`/`dssh_get` helpers all ride ONE persistent ControlMaster mux. What is banned is reaching the device from a shell that has NOT sourced it. Pins the proven root cause (per-connection ssh to the termux sshd intermittently fails to return ~5-15% — NOT a DSP/FastRPC/app deadlock; the remote command actually completes), the fix, large-file retry, how to localize a real hang (device-side log, not ssh stdout), and how to tell link-flakiness from an app bug.

How to hand-write EFFICIENT Hexagon HTP kernels by orchestrating the hardware units (DMA engine, HVX, HMX) and VTCM into an overlapped pipeline. Use this BEFORE designing/optimizing any hand-written DSP op in qcom_htp — bare-metal FastRPC HAPs, dspqueue kernels, custom QNN ops doing their own VTCM/HMX work, or any "make this op faster / why is my op data-movement-bound" task. It pins the methodology (NOT a specific op or dtype): the 3 non-negotiable principles (one RPC = whole graph never per-op; if it fits put ALL data resident in VTCM; hide every byte move under compute), the 4 scheduling layers, the DMA double-buffer that hides data movement (17×), the bottleneck hierarchy (DDR I/O ≫ readback ≫ HMX compute), and the HMX-vs-HVX decision rule. The point is the FLOW, not fp16/int8.

Generate fixed-layout SVG diagrams from QNN HTP optrace artifacts in qcom_htp. Use when you need to visualize chrometrace_htp.json node-flow graphs together with chrometrace.json timing, especially W4A16/QNN Native/custom-op HTP op graphs, without relying on Mermaid auto-layout.

Build or review QNN native op generation flows in qcom_htp. Use when creating float ONNX native Conv/MatMul references, quantization_overrides, QAIRT converter/quantizer/context commands, native raw input/output runs, or when checking that scale/zero-point/bias handling is in the right QNN layer rather than runtime tensors.

Recover, rewrite, and verify Qualcomm Hexagon HMX/QNN kernel byte replicas as readable inline asm. Use when working on qcom_htp files such as v73deep_conv1x1_kernel.inc, libQnnHtp*Skel.so slices, Agent/qnn_re disassembly, unknown HMX objdump packets, or byte-exact conversion from .byte directives to hand-written Hexagon inline asm.