@kernaut/kernaut-resources 0.1.17-beta.1 → 0.1.18

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/transcendental/pitfalls.md

@@ -1,78 +0,0 @@
----
-id: pitfall-ascendc-transcendental-power
-title: "AscendC::Power Is a Constant ~17× Slow — Never Use It as a Fallback"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  Measured at N = 4194304 on DAV_2201. The constancy across exponents is the load
-  bearing part - the absolute 187 us is that shape's number.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-- elementwise
-hardware_features:
-- ai-core
-- vector-unit
-kernel_types:
-- elementwise
-related:
-- pitfall-ascendc-activation-highlevel-api
-- pitfall-ascendc-fma-half-intermediate
-aliases:
-- "Power 恒定慢"
-- "别用 Power 做兜底"
-- "兜底分支必须单独测"
----
-
-## P1. The cost does not depend on the exponent
-
-Same shape, N = 4194304:
-
-| Path | Time |
-|---|---:|
-| `p = 1` | 11.2 µs |
-| `p = 2` | 11.4 µs |
-| `Power` at `p = 0.5 / 2.25 / 6 / 7` | **187 µs, all four** |
-
-That is **16.8× the `p = 1` path and independent of `p`**. In bandwidth terms it is
-45 GB/s (fp16) / 91 GB/s (fp32) — **slower than the vendor baseline**.
-
-## P2. What to use instead — 6–10× measured
-
-**`p` is a positive integer multiple of 0.5** → binary exponentiation on `|x|^(k/2)`:
-take `Sqrt` first if `k` is odd, then square-and-multiply over the bits of `m = k>>1`.
-Cost is `log2(m) + popcount(m)` passes, the same order as a hand-written
-specialization, and it is **exact**.
-
-**Everything else** → `exp(p·ln|x|)`, three passes (`Ln` + `Muls` + `Exp`).
-
-```cpp
-Ln(t, absX, n);
-Muls(t, t, p, n);
-Exp(y, t, n);        // x = 0: ln 0 = -inf, so p>0 gives 0 and p<0 gives inf
-```
-
-At `x = 0` this matches the reference: `ln 0 = -inf`, so `p > 0` yields 0 and `p < 0`
-yields inf.
-
-## P3. The general lesson — fallback branches need their own test
-
-The shapes you are handed usually exercise only the parameters someone already
-specialized. On the operator measured, every supplied exponent was
-1 / 1.5 / 2 / 2.5 / 3 / 4 / 5 / −1 / inf — **the fallback path was never reached**,
-so it never appeared in any accuracy or timing report. It reached it later, and by
-then the only visible symptom was a low number with no cause attached.
-
-> **Sweep the parameter axis separately, as a cross product, and time it.** Running
-> the case set is not a substitute: the case set is exactly the set where the fallback
-> does not run.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/compute/vector-throughput/techniques.md

@@ -1,99 +0,0 @@
----
-id: technique-ascendc-vector-repeat-granularity
-title: "Ascend C Vector Repeat Granularity — 256 Bytes per Instruction"
-type: technique
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.1.0'
-scope: >-
-  The 256 B figure is a property of the vector unit and holds for every Ascend C
-  operator on this architecture. What does not transfer is the element count: it
-  is 256 B divided by the size of the COMPUTE type, which is not always the type
-  the tensor is stored in.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-- vectorized-loads
-hardware_features:
-- ai-core
-- vector-unit
-techniques:
-- vectorized-loads
-confidence: experimental
-evidence_level: measured
-reproducibility: snippet
-prerequisites:
-- hw-ascend910b2c
-related:
-- pitfall-ascendc-bitwise-16bit-lanes
-- technique-ascendc-datacopypad-burst-cost
-sources:
-- exp-ascend910c-vector-repeat-and-dtype-lanes
-source:
-- path: sources/experience/ascend-campaign/ascend910c-vector-repeat-and-dtype-lanes.md
-  anchor: A. One vector instruction retires 256 bytes
-aliases:
-- "一条向量指令退休 256 字节"
-- "尾部按计算类型对齐"
----
-
-## The unit of work is a repeat, not an element
-
-One Ascend C vector instruction retires **256 bytes** per repeat. In elements:
-
-| Compute type | Elements per repeat |
-|---|---:|
-| fp32 | 64 |
-| fp16 / bf16 | **128** |
-| int8 | 256 |
-
-Two things follow, and the second is the one that bites.
-
-**Sizing.** A rough cost for a vector chain is `ceil(bytes / 256) × chain length`
-repeats. This is what makes "collapse twelve instructions into seven" a real win
-rather than a cosmetic one, and it is why a change that removes instructions but
-not repeats measures as noise.
-
-**Tail masking.** The tail mask must be aligned to the repeat of the **compute
-type**. Storage type and compute type are frequently different — a fp16 tensor
-computed in fp16 is 128 per repeat, and the same tensor computed in fp32 is 64.
-
-```cpp
-// WRONG once the compute type moves to fp16: 64 is the fp32 repeat.
-// Leaves half a repeat unmasked; CompareScalar and Select then disagree
-// about the mask bits inside that half.
-uint32_t aligned = (count + 63) & ~63u;
-
-// RIGHT: derive the repeat from the compute type, not from a literal.
-constexpr uint32_t kElemsPerRepeat = 256 / sizeof(ComputeT);   // 64 fp32, 128 fp16
-uint32_t aligned = (count + kElemsPerRepeat - 1) / kElemsPerRepeat * kElemsPerRepeat;
-```
-
-## Why the wrong version passes review
-
-The defect is **silent, sparse and positional**. Measured on Mish: 632 of
-1,046,000 elements took the wrong branch of a piecewise function — 6 of the 20
-shapes actually being tested, and 48 of 210 shapes in a sweep over the operator's
-declared domain. After the fix, 0 and 0.
-
-The elements were wrong at the **end of each core's range**
-(`index % perBlock >= perBlock - 48`), and had nothing in common by value.
-
-> **Diagnostic that generalizes:** when accuracy fails, ask first whether the wrong
-> elements share a *value* property, then whether they share an *index* property.
-> Value-independent plus position-dependent means tail alignment, and the position
-> tells you which alignment constant is wrong.
-
-## Related bound
-
-Repeat granularity is a throughput unit, not a latency one. A vector instruction
-also carries a fixed issue cost of roughly 50 cycle that is nearly independent of
-element count — recorded as an unsettled hypothesis in the source page, and the
-reason instruction-count reductions can measure as zero while the repeat count is
-unchanged.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/host-plugin/cpack-package-race.md

@@ -1,38 +0,0 @@
----
-id: pitfall-ascendc-cpack-package-race
-title: "AscendC：并行 package 可能把旧 tiling 库装入算子包"
-type: pitfall
-vendor: ascend
-architectures: [ascend910b]
-soc: [ascend910b2c]
-languages: [ascendc]
-tags: [ascendc]
-confidence: inferred
-evidence_level: inferred
-cann_version: "9.0.0"
-sources: []
-knowledge_id: knowledge-serialize-cpack-package-install
-knowledge_id_source: agent-semantic-link
-knowledge_scope: conditional-general
-verified_operators: [na3d_varlen_forward]
-condition_ids: [condition-20ba115afc0698ab]
-scope: "使用 CMake/CPack 构建并安装 Ascend C 自定义算子包的流水线"
----
-
-# AscendC：并行 package 可能把旧 tiling 库装入算子包
-
-## 问题
-
-源码和链接产物已经更新，但运行日志仍显示旧 tiling 参数。新链接的 `libcust_opmaster_rt2.0.so` 与 CPack staging、安装目录中的库摘要不一致。
-
-## 处理方式
-
-先并行完成 binary 构建，再不带并行参数串行执行 package 和安装；测试前比较 build、CPack staging 与安装目录中的库摘要。
-
-## 证据与边界
-
-- 修复前，新链接库与已安装库 MD5 不同。
-- 修复后，CPack staging 和安装库 MD5 均为 `5ba24c8924a7dcf2bf190dd955aaa64d`，新 groups 条件在运行日志中生效。
-- 这是打包安装链路的产物竞态，不是算子运行时性能结论。其他构建系统需要验证自己的依赖和原子替换语义。
-
-证据账本：`ledger-na3d-v28-package-race`。

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/host-plugin/device-side-dtype-cast.md

@@ -1,87 +0,0 @@
----
-id: pitfall-ascend-device-side-dtype-cast
-title: "Tensor::to(dtype) in a Launch Plugin Lowers to npu_dtype_cast — Unavailable on Device in Older Runtimes"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.0.1'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  Host-side plugin code that changes a tensor's dtype before handing it to a
-  kernel. It does NOT apply to a cast performed inside the kernel with the
-  operator's own vector instructions - that path has no host dispatch and is
-  unaffected by the runtime's release.
-tags:
-- ascendc
-related:
-- pitfall-ascend-torch-npu-toolchain-surface
-- technique-ascend-float-to-bf16-round-half-even
-sources:
-- exp-ascend910c-target-env-divergence
-aliases:
-- "npu_dtype_cast NPU function error"
-- "plugin 里做类型转换失败"
-- "设备侧 cast 不可用"
-- "掉分看着像精度回退其实是运行时错误"
----
-
-# `Tensor::to(dtype)` Is a Dispatch, Not a Reinterpretation
-
-## Symptom
-
-Locally every case passes. On the target runtime, some cases fail with:
-
-```
-AI算子执行失败: npu_dtype_cast_impl_op_api:
-build/CMakeFiles/torch_npu.dir/compiler_depend.ts:35 NPU function error
-```
-
-## Mechanism
-
-Writing `x.to(torch::kFloat32)` in a launch plugin — the usual way to promote an
-fp16/bf16 input before calling a kernel — dispatches to `npu_dtype_cast`.
-That is a device operator, and whether it is available on device is a property
-of the torch_npu release. The newer local runtime has it; the older target one
-does not.
-
-This is the same class as
-[pitfall-ascend-torch-npu-toolchain-surface](./toolchain-surface-pitfalls.md),
-one layer later: there the missing surface is caught at build time, here it
-survives the build and fails at run time.
-
-## Why it is easy to misdiagnose
-
-The cases that hit it do not produce a wrong number — they produce **no** number.
-Any score that mixes "did it run" with "was it accurate" moves in the direction
-that looks like an accuracy regression.
-
-> **Reading rule.** When a delivery loses ground on the target, separate
-> "compiled and ran" from "was accurate" *before* looking at the numbers. If
-> anything failed to complete, chase the runtime error first. Accuracy work on a
-> case that never ran is wasted.
-
-## Fix
-
-Cast with the operator's own kernel. Most operators already have one, or need
-only a small vector-cast entry point. Template the kernel by output type rather
-than casting the tensor outside it.
-
-For `float → bf16`, write the rounding explicitly rather than relying on a
-hardware default:
-
-```cpp
-// round-half-to-even from fp32 to bf16
-__aicore__ inline uint16_t FloatToBf16(float f) {
-    union { float f; uint32_t u; } v;
-    v.f = f;
-    uint32_t lsb     = (v.u >> 16) & 1u;
-    uint32_t rounded = v.u + 0x7fffu + lsb;
-    return static_cast<uint16_t>(rounded >> 16);
-}
-```

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/host-plugin/multi-output-tensor-types.md

@@ -1,66 +0,0 @@
----
-id: pitfall-ascend-multi-output-tensor-types
-title: "In a Layered Operator, Each Output Carries Its Own Type — One Template Writes 4 Bytes Into a 2-Byte Slot"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.0.1'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  Operators that write intermediate results back into caller-owned tensors -
-  stacked layers, segmented scans, anything with per-step state. A single-output
-  elementwise kernel cannot hit this.
-tags:
-- ascendc
-related:
-- technique-ascend-float-to-bf16-round-half-even
-sources:
-- exp-ascend910c-target-env-divergence
-aliases:
-- "多输出算子 中间层类型"
-- "NaN 位置不匹配 只有一个输出错"
-- "4 字节写进 2 字节槽位"
----
-
-# One Output Type Template Is Not Enough
-
-## Symptom
-
-A layered operator passes the single-layer cases and fails a multi-layer one.
-**Exactly one output is wrong** — it reports mismatched NaN or Inf positions —
-while every other output of the same kernel is fine.
-
-## Mechanism
-
-The layer-to-layer handoff and the caller-visible state are different tensors
-with different types. Measured instance: in a stacked LSTM, `y` must be fp32
-because the next layer consumes it, while `hn`/`cn` belong to the caller and stay
-in the caller's `T`. Running the intermediate layers under one `<TOut>` template
-writes a 4-byte float into a 2-byte slot.
-
-The corruption is a byte-layout error, not an arithmetic one, so the values that
-survive look plausible and only the special-value positions disagree.
-
-## Fix
-
-Split the template so each output carries its own type:
-
-```cpp
-template <typename TY, typename TState>
-__aicore__ void LstmLayer(GM_ADDR y, GM_ADDR hn, GM_ADDR cn, /* … */);
-```
-
-## What actually catches it
-
-The multi-layer case. This defect is invisible to every single-layer test, and
-a test set that happens to contain only single-layer shapes will report a clean
-run.
-
-> **Run the case that has more than one layer or more than one segment.** For a
-> multi-output operator that is the only shape that exercises the handoff at all.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/host-plugin/synchronize-device-zero.md

@@ -1,71 +0,0 @@
----
-id: pitfall-ascend-synchronize-device-zero
-title: "torch.npu.synchronize() Synchronises Device 0 — Timings on Any Other Card Are Fiction"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.0.1'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  Wall-clock timing from Python on a card other than device 0. Device-side
-  profiler readings are unaffected, and so is any measurement on device 0 - which
-  is why this survives on a single-card desk and appears only on a shared host.
-tags:
-- ascendc
-sources:
-- exp-ascend910c-target-env-divergence
-aliases:
-- "synchronize 只同步 device 0"
-- "非零卡计时恒为 1ms"
-- "墙钟读数不对 多卡"
----
-
-# `torch.npu.synchronize()` Takes No Device Argument
-
-## Symptom
-
-An experiment pinned to `npu:3` reports a wall-clock time of roughly **1 ms**,
-and the number barely moves when the work changes.
-
-## Mechanism
-
-`torch.npu.synchronize()` synchronises the *current* device, and the current
-device is 0 unless it has been set. Placing tensors on `npu:3` does not set it.
-So the timer closes before the work on card 3 has finished, and what gets
-measured is the launch path.
-
-The reading is not noisy — it is **stably wrong**, which is worse. A stable
-number looks like a measurement.
-
-## Fix
-
-Either set the device first:
-
-```python
-torch.npu.set_device(3)
-# … now torch.npu.synchronize() actually waits for card 3
-```
-
-or force the synchronisation through a transfer:
-
-```python
-out = kernel(...)
-out.cpu()          # blocks until card 3 has produced the data
-```
-
-## Why it is worth a page
-
-A timing harness that produces a plausible constant is the failure mode a
-threshold cannot catch. The measured instance nearly established that "the exact
-path is not slower" — a conclusion built entirely on the launch overhead of a
-card nobody was waiting for.
-
-**A timing probe has to be able to show a difference before its readings mean
-anything.** Time a deliberately slower variant first; if the number does not
-move, the probe is broken, not the hypothesis.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/host-plugin/toolchain-surface-pitfalls.md

@@ -1,82 +0,0 @@
----
-id: pitfall-ascend-torch-npu-toolchain-surface
-title: "torch_npu Symbols Present in One Release and Absent in Another Fail at the Target, Not at Your Desk"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.0.1'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  Applies whenever the runtime you build against and the runtime you deliver to
-  are different torch_npu releases. It does NOT apply when both sides are pinned
-  to the same image - there the symbol either exists on both or neither, and a
-  local build failure tells you immediately.
-tags:
-- ascendc
-related:
-- api-ascend-platform-core-count
-- pitfall-ascend-device-side-dtype-cast
-sources:
-- exp-ascend910c-target-env-divergence
-aliases:
-- "本地能编目标环境编不过"
-- "torch_npu 版本 符号缺失"
-- "use of undeclared identifier 编译失败"
-- "工具链 API 面差异"
----
-
-# torch_npu Symbols Are Not a Stable Surface Across Releases
-
-## Symptom
-
-The kernel builds and runs at your desk. On the target runtime the build fails:
-
-```
-error: use of undeclared identifier 'aclrtGetDeviceInfo'
-```
-
-## Mechanism
-
-`torch_npu`'s vendored ACL headers gain and lose declarations between releases.
-A call that resolves against the newer header has nothing to bind to in the
-older one. Nothing about this is visible locally: the local build is the
-evidence that the symbol exists *there*, not that it exists everywhere.
-
-Measured instance: `aclrtGetDeviceInfo(device_id, ACL_DEV_ATTR_VECTOR_CORE_NUM, &n)`
-compiles under torch_npu 2.10.0.post2 and does not exist in the older release the
-target ran.
-
-## Cost
-
-Build failure is the most expensive class of divergence, because it is not scoped
-to the construct that caused it. Where a delivery is compiled as one unit, **one
-undeclared identifier takes the whole delivery down**, including every operator
-that was correct.
-
-## Fix
-
-Take platform facts from CANN's own platform layer rather than from torch_npu's
-vendored ACL headers, and keep the call in an `op_kernel` translation unit — see
-[api-ascend-platform-core-count](../../api-definitions/ascendc/platform-core-count.md).
-
-Do not `#include` torch_npu's `third_party/acl` headers for anything that is not
-strictly necessary. Each such include widens the surface that has to agree
-between two releases you do not control.
-
-## How to catch it before delivery
-
-This is a grep, not a discipline. The set of forbidden constructs is small,
-closed, and machine-checkable:
-
-- torch_npu-proprietary ACL extensions (`aclrtGetDeviceInfo`, …)
-- custom core-count helpers that shadow the platform layer
-- environment-variable branches left over from local sweeps
-
-A checklist that a person has to remember will be forgotten exactly once, which
-is enough. Put it in the build.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/memory/alignment/pitfalls.md

@@ -1,63 +0,0 @@
----
-id: pitfall-ascendc-alignment
-title: "Two Silent Alignment Traps — rightPadding's Ceiling and LocalTensor Byte Offsets"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  32 B is the natural alignment on this part; both rules restate that boundary through
-  different APIs. Neither is silent in the sense of producing wrong data - both raise -
-  but both raise far from the line that caused them.
-tags:
-- ascendc
-- ai-core
-- ub
-hardware_features:
-- ai-core
-- ub
-related:
-- pitfall-ascendc-ub-buffer-hazards
-- technique-ascendc-datacopypad-burst-cost
-aliases:
-- "rightPadding 只能补到 32B"
-- "LocalTensor 偏移 32B 对齐"
-- "静默对齐坑"
----
-
-## P1. `DataCopyPad`'s `rightPadding` only pads to the 32 B boundary
-
-Trying to use it to extend a row out to `padInner` — 37 → 64, say — raises
-`"MTE instruction parameter is invalid"`. Anything beyond the natural alignment has to
-go through `dstStride`, whose unit is **32 B blocks**.
-
-```cpp
-// WRONG — rightPadding cannot reach 64 from 37
-DataCopyPad(ub, gm, {1, 37 * sizeof(T), 0, 0}, {false, 0, 64 - 37, 0});
-
-// RIGHT — pad to the natural boundary, and express the rest as a destination stride
-//         in 32 B blocks
-DataCopyPad(ub, gm, {rows, 37 * sizeof(T), 0, (64 - 40) * sizeof(T) / 32}, padParams);
-```
-
-## P2. A `LocalTensor` byte offset is always 32 B aligned
-
-An offset computed **in elements** — `idxBuf[gN*4]` — goes crooked whenever `gN` is not
-a multiple of 8, and raises
-`"UB address accessed by the VEC instruction is not aligned"`.
-
-This was hit **three times in one round** on three different buffers. The habit that
-fixes it is mechanical:
-
-> **Every time you carve out a new region of UB, round the offset up to 32 B on the
-> spot.** Do not compute it in elements and hope.
-
-Same constraint, a third API: `Duplicate`'s offset — see
-[`pitfall-ascendc-ub-buffer-hazards`](../ub-buffer-hazards/pitfalls.md).

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/memory/broadcast-transpose.md

@@ -1,62 +0,0 @@
----
-id: algo-ascendc-broadcast-transpose
-title: AscendC broadcast collapse, NDDMA and small-channel transpose
-type: algorithm
-vendor: ascend
-architectures:
-- ascend910b
-- ascend950
-languages:
-- ascendc
-tags:
-- ascendc
-confidence: source-reported
-evidence_level: inferred
-scope: Selected cannbot notes at ddea090f28ec863e97a65f71ccc9cc9b956e327a; architecture
-  and implementation conditions are stated per section. No local SDK compilation or
-  device validation.
-sources:
-- blog-cannbot-ascendc-notes
-source:
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/ascendc-tiling-design/references/broadcast/dynamic-ub-broadcast.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/ascendc-tiling-design/references/broadcast/nddma-broadcast.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/ascendc-tiling-design/references/broadcast/patterns.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/ascendc-tiling-design/references/broadcast/ub-broadcast.md
-- path: sources/blogs/cannbot-ascendc-notes.md
-  anchor: ops/ascendc-tiling-design/references/conversion/patterns.md
-related: []
----
-
-# AscendC broadcast collapse, NDDMA and small-channel transpose
-
-Source-reported constraints and adapted algorithms from the [pinned cannbot snapshot](../../../../sources/blogs/cannbot-ascendc-notes.md). These notes are not an SDK specification or a device validation record. Existing versioned API and measured pages remain authoritative for their stated scope.
-
-## Existing mechanisms versus added cases
-
-[Dimension merge](../../techniques/dimension-merge/README.md) already explains contiguous collapse, while [broadcast-max](../compute/broadcast-max/techniques.md) owns measured Gather/Brcb alternatives. This page adds joint multi-input legality and source-specific NDDMA/small-channel cases, without repeating those recipes or their speedups.
-
-## All operands participate in collapse
-
-Left-pad ranks with ones and check broadcasting per axis. Build the vector of broadcast flags for **all** inputs at each axis. Adjacent equal flag vectors are necessary but not sufficient: every input/output physical stride must also permit the collapse. A noncontiguous view is not validated by matching shapes alone.
-
-Broadcast axes have effective source stride zero. Whether to materialize a broadcast still depends on reuse, instruction count and live storage. Grow the contiguous inner tile only while all inputs, casts, intermediates and outputs fit, then distribute or loop over outer axes. Empty dimensions follow the framework rules; max(0,1)=1 is not a valid generic rule for reading a zero-sized input.
-
-## NDDMA only on supported 3510 paths
-
-The [3510 resource page](../../hardware/dav-3510-resource-model.md) owns the maximum dimensions and GM→UB capability. Source-stride zero can express broadcast without a separate UB expansion. If legal collapse leaves more dimensions than the interface supports, loop over outer coordinates rather than dropping axes.
-
-This can avoid intermediate UB broadcast, but may create repeated GM requests. Compare cache reuse of a small tail slab with explicit UB residency. A source threshold based on half the DCache is an observation, not a universal tiling constant. RegBase dynamic UB broadcast is another candidate with its own dtype, mask and distribution constraints.
-
-## Small-C transpose and cast fusion
-
-The source's C<=16 `[C,N]→[N,C]` candidate requires the original permutation to reduce to that adjacent two-dimensional problem. A general ND permutation cannot be made equivalent merely by calling the remaining element count N.
-
-A following cast/quantization may fuse within the tile and remove a GM intermediate, but an FP16 intermediate for FP32 input can lose precision. It is not a lossless transpose unless the numerical contract establishes that equivalence.
-
-One FP32-input/FP16-intermediate/uint8-output `TransDataTo5HD` implementation budgets `tileNA*(16*C+32)` bytes; C=3 gives 80 bytes per tileNA unit. Recompute for a different live set.
-
-If that implementation requires tileNA%32=0 and repeat=tileNA/16 fits uint8 with repeat<=255, the largest legal tileNA is 4064. 4080 fails alignment; 4096 produces repeat=256. These simultaneous constraints, not a single rounded limit, define the candidate.