@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/languages/tilelang/tilelang-ascendc-api-mapping.md

@@ -1,143 +0,0 @@
----
-id: skill-tilelang-ascendc-api-mapping
-title: "TileLang to AscendC API Mapping"
-type: skill
-vendor: ascend
-tags:
-- tilelang
-- ascendc
-evidence_level: spec
-applies_to:
-- ascend910b
-source:
-- path: local
-  anchor: AscendOpGenAgent/skills
-architectures:
-- ascend910b
-languages:
-- tilelang
-- ascendc
----
-# TileLang-Ascend API Mapping
-
-本文整理 TileLang Ascend 编程中常见 API 与最终落到的 AscendC API 的对应关系。
-
-说明：
-- 对于部分 API，tensor-tensor 和 tensor-scalar 的 lowering 不同，分别列出。
-
-## 数据搬运
-
-| TileLang API | AscendC API | 备注 |
-| --- | --- | --- |
-| `T.copy(src, dst)` (`GM -> L1`) | `AscendC::DataCopy(...)` | 常见为 `DataCopy(..., Nd2NzParams)`；若目标是 `TQue`，配合 `AllocTensor` 和 `EnQue`。 |
-| `T.copy(src, dst)` (`L1 -> L0A`) | `AscendC::LoadData(...)` / `AscendC::LoadDataWithTranspose(...)` | 是否转置取决于 layout。 |
-| `T.copy(src, dst)` (`L1 -> L0B`) | `AscendC::LoadData(...)` / `AscendC::LoadDataWithTranspose(...)` | 是否转置取决于 layout。 |
-| `T.copy(src, dst)` (`L0C -> GM`) | `AscendC::Fixpipe(...)` |  |
-| `T.copy(src, dst)` (`GM -> UB`) | `AscendC::DataCopyPad(local, global, copyParams, padParams)` | 若目标是 `TQue`，配合 `AllocTensor` 和 `EnQue`；如果是矩阵的二维子 tile，常改用 `DataCopy` + `DataCopyParams`。 |
-| `T.copy(src, dst)` (`UB -> GM`) | `AscendC::DataCopyPad(global, local, copyParams)` | 若来源是 `TQue`，配合 `DeQue` 和 `FreeTensor`；如果是写回矩阵的二维子 tile，常改用 `DataCopy` + `DataCopyParams`。 |
-| `T.copy(src, dst)` (`UB -> UB`, same dtype) | `AscendC::DataCopy(...)` |  |
-| `T.copy(src, dst)` (`UB -> UB`, cast dtype) | `AscendC::Cast(...)` |  |
-
-### DataCopy / DataCopyPad 注意事项
-
-- `DataCopyPad` 的 `GM -> UB` 和 `UB -> GM` 参数个数不同：
-  - `GM -> UB`：`DataCopyPad(local, global, copyParams, padParams)`，需要 4 参数，并传入 `DataCopyPadExtParams<T>`。
-  - `UB -> GM`：`DataCopyPad(global, local, copyParams)`，只需要 3 参数，不传 `padParams`。
-- `DataCopyExtParams` 常用字段为 `blockCount, blockLen, srcStride, dstStride, rsv`；其中 `blockLen` 单位是字节，`srcStride`/`dstStride` 的单位随 GM 或 Local 位置变化。
-- `DataCopyPadExtParams<T>` 常用字段为 `isPad, leftPadding, rightPadding, padValue`；`isPad` 属于 `DataCopyPadExtParams<T>`，不要写进 `DataCopyExtParams`。
-- 参与 `GM <-> UB` 搬运的 UB buffer 优先映射为 `TQue` 分配的 `LocalTensor`，并按方向配合 `AllocTensor`/`EnQue` 或 `DeQue`/`FreeTensor`；不要把直接参与 `DataCopy` / `DataCopyPad` 的 buffer 映射为普通 `TBuf`。
-- 连续且 32B 对齐的搬运优先用 `DataCopy`；非对齐、尾块或需要补齐时再用 `DataCopyPad`。
-- 矩阵二维子 tile 或带 stride 的搬运应显式构造 `DataCopyParams` / `DataCopyExtParams`。
-- 普通 `UB -> UB` 搬运优先用 `DataCopy`；`Local -> Local` 的 `DataCopyPad + Nd2NzParams` 属于特殊格式转换路径，不按普通 `T.copy(UB -> UB)` 套用。
-
-## 向量与逐元素计算
-
-| TileLang API | AscendC API | 备注 |
-| --- | --- | --- |
-| `T.tile.add(dst, src0, src1)` | `AscendC::Add(...)` | `src1` 为 tensor / buffer。 |
-| `T.tile.add(dst, src0, scalar)` | `AscendC::Adds(...)` | `src1` 为 scalar 或 `BufferLoad`。 |
-| `T.tile.sub(dst, src0, src1)` | `AscendC::Sub(...)` | `src1` 为 tensor / buffer。 |
-| `T.tile.sub(dst, src0, scalar)` | `AscendC::Adds(...)` | 通过对标量取负实现。 |
-| `T.tile.mul(dst, src0, src1)` | `AscendC::Mul(...)` | `src1` 为 tensor / buffer。 |
-| `T.tile.mul(dst, src0, scalar)` | `AscendC::Muls(...)` | `src1` 为 scalar 或 `BufferLoad`。 |
-| `T.tile.div(dst, src0, src1)` | `AscendC::Div(...)` | `src1` 为 tensor / buffer。 |
-| `T.tile.div(dst, src0, scalar)` | `AscendC::Muls(...)` | 通过乘以倒数实现。 |
-| `T.tile.max(dst, src0, src1)` | `AscendC::Max(...)` | `src1` 为 tensor / buffer。 |
-| `T.tile.max(dst, src0, scalar)` | `AscendC::Maxs(...)` | `src1` 为 scalar 或 `BufferLoad`。 |
-| `T.tile.min(dst, src0, src1)` | `AscendC::Min(...)` | `src1` 为 tensor / buffer。 |
-| `T.tile.min(dst, src0, scalar)` | `AscendC::Mins(...)` | `src1` 为 scalar 或 `BufferLoad`。 |
-| `T.tile.exp(dst, src0)` | `AscendC::Exp(...)` |  |
-| `T.tile.sigmoid(dst, src, tmp)` | `AscendC::Sigmoid(...)` |  |
-| `T.tile.ln(dst, src0)` | `AscendC::Ln(...)` |  |
-| `T.tile.abs(dst, src0)` | `AscendC::Abs(...)` |  |
-| `T.tile.pow(dst, src0, src1, tmp)` | `AscendC::Power(...)` |  |
-| `T.tile.reciprocal(dst, src0)` | `AscendC::Reciprocal(...)` |  |
-| `T.tile.sqrt(dst, src0)` | `AscendC::Sqrt(...)` |  |
-| `T.tile.rsqrt(dst, src0)` | `AscendC::Rsqrt(...)` |  |
-| `T.tile.relu(dst, src0)` | `AscendC::Relu(...)` |  |
-| `T.tile.leaky_relu(dst, src0, scalar)` | `AscendC::LeakyRelu(...)` |  |
-| `T.tile.axpy(dst, src0, scalar)` | `AscendC::Axpy(...)` |  |
-| `T.tile.sin(dst, src0, tmp)` | `AscendC::Sin(...)` |  |
-| `T.tile.cos(dst, src0, tmp)` | `AscendC::Cos(...)` |  |
-| `T.tile.bitwise_and(dst, src0, src1)` | `AscendC::And(...)` |  |
-| `T.tile.bitwise_or(dst, src0, src1)` | `AscendC::Or(...)` |  |
-| `T.tile.bitwise_not(dst, src0)` | `AscendC::Not(...)` |  |
-| `T.tile.bitwise_xor(dst, src0, src1)` | `AscendC::Xor(...)` |  |
-| `T.tile.bitwise_lshift(dst, src0, scalar)` | `AscendC::ShiftLeft(...)` |  |
-| `T.tile.bitwise_rshift(dst, src0, scalar)` | `AscendC::ShiftRight(...)` |  |
-| `T.tile.compare(dst, src0, src1, mode)` | `AscendC::Compare(...)` | tensor-tensor compare。 |
-| `T.tile.compare(dst, src0, scalar, mode)` | `AscendC::CompareScalar(...)` | tensor-scalar compare。 |
-| `T.tile.select(dst, selMask, src0, src1, selMode)` | `AscendC::Select(...)` |  |
-| `T.tile.cast(dst, src, mode, count)` | `AscendC::Cast(...)` |  |
-| `T.tile.round(dst, src, tmp, count)` | `AscendC::Round(...)` |  |
-| `T.tile.transpose(dst, src)` | `AscendC::Transpose(...)` |  |
-| `T.tile.broadcast(dst, src, tmp)` | `AscendC::Broadcast<...>(...)` | broadcast axis 由 shape 自动推断。 |
-| `T.tile.createvecindex(dst, first_value)` | `AscendC::CreateVecIndex(...)` |  |
-| `T.tile.fill(dst, value)` | `AscendC::Duplicate(...)` |  |
-| `T.tile.arith_progression(dst, first_value, diff_value, count)` | `AscendC::ArithProgression(...)` |  |
-| `T.tile.clamp_max(dst, src, tmp, scalar, count)` | `AscendC::ClampMax(...)` |  |
-| `T.tile.clamp_min(dst, src, tmp, scalar, count)` | `AscendC::ClampMin(...)` |  |
-| `T.tile.clamp(dst, src, tmp, min_scalar, max_scalar, count)` | `AscendC::ClampMin(...)` + `AscendC::ClampMax(...)` | 先 clamp min，再 clamp max。 |
-| `T.tile.bilinear_interpolation(dst, src0, src0_offset, src1, mask, h_repeat, repeat_mode, dst_blk_stride, v_r_offset, v_repeat, shared_tmp_buffer)` | `AscendC::BilinearInterpolation(...)` |  |
-| `T.tile.brcb(dst, src0, repeat_time, dst_blk_stride, dst_rep_stride)` | `AscendC::Brcb(...)` |  |
-
-## 排序、Gather 与索引相关
-
-| TileLang API | AscendC API | 备注 |
-| --- | --- | --- |
-| `T.tile.sort(dst, src, indices, tmp_buffer, repeat_time)` | `AscendC::Sort(...)` |  |
-| `T.tile.sort32(dst, src0, src1)` | `AscendC::Sort32(...)` |  |
-| `T.tile.init_sort_buf(src, ele_num, rsv=0)` | `AscendC::Duplicate(...)` | 用若干次 `Duplicate` 初始化排序缓冲区。 |
-| `T.tile.merge_sort(dst, src, block_size, block_num, is_copy)` | `AscendC::MrgSort(...)` |  |
-| `T.tile.merge_sort(dst, src, block_size, block_num, 1)` | `AscendC::MrgSort(...)` + `AscendC::DataCopy(...)` | `is_copy = 1` 时会追加 copy。 |
-| `T.tile.topk(dst, src, tmp_buffer, block_size)` | `AscendC::MrgSort(...)` + `AscendC::DataCopy(...)` |  |
-| `T.tile.gather(dst, src, src_offset, src_base_addr)` | `AscendC::Gather(...)` |  |
-| `T.tile.gatherb(dst, src0, offset, repeat_time, dst_blk_stride, dst_rep_stride)` | `AscendC::Gatherb(...)` |  |
-| `T.tile.gather_mask(dst, src, "P0101"/...)` | `GatherMask(...)` | 固定 pattern 模式，走封装实现，不是直接打印成 `AscendC::GatherMask` 字符串。 |
-| `T.tile.gather_mask(dst, src, pattern_buf)` | `AscendC::Muls(...)` + `AscendC::Gather(...)` | 自定义 pattern 会先把索引乘元素字节数，再做 gather。 |
-
-## Reduce
-
-| TileLang API | AscendC API | 备注 |
-| --- | --- | --- |
-| `T.reduce.sum(...)` / Tile reduce sum | `AscendC::ReduceSum<T, AscendC::Pattern::Reduce::AR>(...)` / `AscendC::ReduceSum<T, AscendC::Pattern::Reduce::RA>(...)` | 按 `dim` 选择 AR/RA。 |
-| `T.reduce.max(...)` / Tile reduce max | `AscendC::ReduceMax<T, AscendC::Pattern::Reduce::AR>(...)` / `AscendC::ReduceMax<T, AscendC::Pattern::Reduce::RA>(...)` | 按 `dim` 选择 AR/RA。 |
-| `T.reduce.min(...)` / Tile reduce min | `AscendC::ReduceMin<T, AscendC::Pattern::Reduce::AR>(...)` / `AscendC::ReduceMin<T, AscendC::Pattern::Reduce::RA>(...)` | 按 `dim` 选择 AR/RA。 |
-| `T.tile.block_reduce_sum(dst, src, ...)` | `AscendC::BlockReduceSum(...)` |  |
-| `T.tile.block_reduce_max(dst, src, ...)` | `AscendC::BlockReduceMax(...)` |  |
-| `T.tile.block_reduce_min(dst, src, ...)` | `AscendC::BlockReduceMin(...)` |  |
-| `T.tile.wholereducesum(dst, src, ...)` | `AscendC::WholeReduceSum(...)` |  |
-| `T.tile.wholereducemax(dst, src, ...)` | `AscendC::WholeReduceMax(...)` |  |
-| `T.tile.wholereducemin(dst, src, ...)` | `AscendC::WholeReduceMin(...)` |  |
-
-## MMA / GEMM
-
-| TileLang API | AscendC API | 备注 |
-| --- | --- | --- |
-| `tl::ascend_mma(...)` | `AscendC::Mmad(...)` |  |
-## 补充说明
-
-| TileLang API | AscendC API | 备注 |
-| --- | --- | --- |
-| `T.copy(...)` | 不是单一 API | 会根据 scope 选择 `DataCopy` / `LoadData` / `Fixpipe` / `DataCopyPad` / `Cast`。 |
-| `T.tile.add/sub/mul/div/max/min(...)` | 可能是向量版或标量版 | tensor-tensor 常对应 `Add/Sub/Mul/Div/Max/Min`；scalar 常对应 `Adds/Muls/Maxs/Mins`。 |

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/languages/triton-ascend/fp16-native-chain-parity.md

@@ -1,87 +0,0 @@
----
-id: skill-triton-ascend-fp16-native-chain-parity
-title: "Triton Ascend fp16 Native Chain Parity"
-type: skill
-vendor: ascend
-tags:
-- triton-ascend
-evidence_level: measured
-applies_to:
-- ascend910b
-source:
-- path: local
-  anchor: fp16 native lowprecision rounding parity precision probe
-architectures:
-- ascend910b
-languages:
-- triton-ascend
-kernel_types:
-- elementwise
-- reduction
-- attention
-aliases:
-- fp16 native chain
-- float16 native chain
-- half native math
-- fp16 transcendental
-- fp16 exp
-- fp16 tanh
-- fp16 rsqrt
-- do not upcast fp16
-- fp16 per op materialization
-- fp16 barrier invariant
-- fp16 NaN Inf parity
-- torch_npu fp16 native
-cann_version: "unknown"
----
-# Triton Ascend fp16 Native Chain Parity
-
-## Search Keywords
-
-Simple search terms: fp16 native chain, float16 native chain, half native math, fp16 transcendental, fp16 exp, fp16 tanh, fp16 rsqrt, do not upcast fp16, fp16 per-op materialization, fp16 barrier invariant, fp16 NaN Inf parity, torch_npu fp16 native.
-
-## 1. Key rule
-
-Do not copy the bf16 recipe of “fp32 intrinsic + bit-round” to fp16. torch_npu fp16 transcendental behavior is closer to a **native fp16 op chain**, so Triton-Ascend should keep the computation chain in fp16:
-
-```python
-xh = x.to(tl.float16)
-z  = (input_scale_h * xh).to(tl.float16)
-e  = tl.exp(z).to(tl.float16)
-m1 = (e - 1.0).to(tl.float16)
-out = (alpha_scale_h * m1).to(tl.float16)
-```
-
-For fp16, upcasting to fp32 and rounding back can diverge from torch_npu fp16 intrinsics by a few ULPs, enough to cross a `1e-2` gate.
-
-## 2. Difference from bf16
-
-| dtype | Empirical reference model | Triton-Ascend parity strategy |
-|---|---|---|
-| bf16 | fp32 intrinsic followed by bf16 rounding | fp32 op + explicit bf16 RTNE bit-round at each edge |
-| fp16 | native fp16 intrinsic / op chain | keep the chain native fp16; do not upcast first |
-
-Match the reference’s **compute precision**, not just its rounding mode.
-
-## 3. NaN/Inf also depend on fp16 materialization
-
-The native fp16 chain affects not only finite values but also NaN/Inf masks. For example, `x ** -3` or `1 / tiny` may overflow to `inf` in fp16 and propagate to `NaN` downstream. If the Triton kernel computes the same intermediate in fp32, it may remain finite and fail the verifier’s NaN/Inf mask.
-
-If Triton-Ascend saturates fp16 overflow to `65504` instead of producing `inf`, see [fp16 overflow semantics](fp16-overflow-semantics.md).
-
-## 4. When to use
-
-Use this rule when:
-
-- fp16 fails against torch_npu while fp32 passes;
-- the expression contains `exp`, `tanh`, `rsqrt`, pow, reciprocal, or similar operations;
-- the reference is a decomposed op graph with per-op materialization;
-- NaN/Inf positions must match, not only finite allclose values.
-
-## 5. Checklist
-
-1. Do not assume fp32 intermediates are better for verification; the evaluator wants reference parity.
-2. Run fp16 transcendentals on fp16 operands when the reference does so.
-3. Materialize each reference fp16 boundary with `.to(tl.float16)`.
-4. If NaN/Inf masks differ, combine this with [fp16 overflow semantics](fp16-overflow-semantics.md).
-5. For bf16, use the generic [low-precision materialization pitfall](../../../generic/pitfalls/triton-low-precision-materialization.md) guidance instead.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/languages/triton-ascend/fp16-overflow-semantics.md

@@ -1,130 +0,0 @@
----
-id: skill-triton-ascend-fp16-overflow-semantics
-title: "Triton Ascend fp16 Overflow Semantics"
-type: skill
-vendor: ascend
-tags:
-- triton-ascend
-evidence_level: measured
-applies_to:
-- ascend910b
-source:
-- path: local
-  anchor: fp16-overflow-semantics precision probe
-architectures:
-- ascend910b
-languages:
-- triton-ascend
-kernel_types:
-- elementwise
-- reduction
-- attention
-aliases:
-- fp16 overflow
-- half overflow
-- float16 overflow
-- NaN mask mismatch
-- Inf mask mismatch
-- NaN/Inf mask
-- saturate to 65504
-- clamp to 65504
-- fp16 saturate
-- overflow to inf
-- 65504
-- 65520
-- std**-3
-- reciprocal overflow
-- pow negative overflow
-- torch_npu fp16
-- Triton-Ascend fp16
-- materialize fp16 overflow
-- Inf sign mismatch
-cann_version: "unknown"
----
-# Triton Ascend fp16 Overflow Semantics
-
-## Search Keywords
-
-Simple search terms: fp16 overflow, half overflow, float16 overflow, NaN mask mismatch, Inf mask mismatch, NaN/Inf mask, saturate to 65504, clamp to 65504, overflow to inf, 65504, 65520, reciprocal overflow, pow negative overflow, std**-3, materialize fp16 overflow, torch_npu fp16, Triton-Ascend fp16.
-
-## 1. Problem
-
-torch_npu fp16 ops usually follow fp16 overflow semantics: when the true result magnitude exceeds the largest finite fp16 value (`65504`), the result becomes `+inf` or `-inf`. These infinities then propagate into downstream `NaN`s through expressions such as `inf * 0`, `inf - inf`, or `inf + (-inf)`.
-
-A common Triton-Ascend path differs: fp16 arithmetic may be kept in fp32 registers, and the final `fp32 -> fp16` cast can **saturate** to `65504` instead of producing `inf`. Finite allclose may therefore look fine, but the verifier fails first because NaN/Inf positions or Inf signs do not match.
-
-## 2. When to use this page
-
-Check this rule first when:
-
-- an fp16 kernel against a torch_npu reference reports `NaN mask mismatch` or `Inf mask mismatch`;
-- the reference contains division by a tiny value or a negative power, such as `1/x`, `x**-1`, `std**-3`, or `rsqrt(tiny)`;
-- fp32/bf16 paths pass, but fp16 NaN/Inf positions differ;
-- the mismatch appears in normalization backward, attention scaling, or elementwise reciprocal/pow code.
-
-If only finite values exceed the tolerance and NaN/Inf masks match, look at low-precision rounding parity instead.
-
-## 3. Core technique: overflow-aware materialization
-
-When a fp32 intermediate must emulate torch_npu fp16 materialization, do not rely only on `.to(tl.float16)`. Explicitly map values that would round to fp16 infinity to signed `inf`; otherwise use the normal fp16 round:
-
-```python
-@triton.jit
-def materialize_fp16_overflow(v):  # v: fp32 value, returns fp16-semantics value kept as fp32
-    zero = tl.full((), 0.0, tl.float32)
-    pinf = 1.0 / zero
-    ninf = -1.0 / zero
-    BIG = 65520.0  # fp16 round-to-inf boundary; max finite fp16 is 65504
-    return tl.where(v >= BIG, pinf,
-           tl.where(v <= -BIG, ninf,
-                    v.to(tl.float16).to(tl.float32)))
-```
-
-Example:
-
-```python
-# The reference materializes this reciprocal-cube boundary in fp16.
-cube = materialize_fp16_overflow(std * std * std)
-inv_cube = materialize_fp16_overflow(1.0 / cube)
-```
-
-Notes:
-
-- `65520.0` is the fp16 round-to-nearest-even overflow boundary above max finite `65504`.
-- `1.0 / 0.0` is a reliable way to construct `+inf` on Ascend; the negative case is analogous.
-- Inf sign must match the true fp32 value because the verifier checks Inf signs.
-- bf16 usually does not need this overflow patch because its exponent range is close to fp32; bf16 mainly needs rounding parity.
-
-## 4. This is not a universal patch
-
-For graphs with multiple overflow sites, inserting this helper everywhere does not guarantee a better result. The NaN/Inf mask depends on:
-
-- dtype at every intermediate node;
-- op execution order;
-- reduction/accumulation order;
-- where combinations such as `inf + (-inf)` or `inf * 0` occur.
-
-If the Triton kernel structure differs substantially from the reference, for example a two-pass reduction or a long fp32 fused chain replacing a per-op fp16 graph, NaN/Inf positions may still differ. Exact matching requires mirroring the torch_npu fp16 op graph node-by-node and materializing the same boundaries.
-
-## 5. Diagnostic flow
-
-1. If the failure is a NaN/Inf mask mismatch, use this flow. If it is finite allclose only, use rounding parity first.
-2. Locate overflow sources: `1/x`, negative `pow`, `rsqrt`, `std**-3`, softmax/exp, and similar expressions.
-3. Add `materialize_fp16_overflow` at the most suspicious boundary first and check whether ref/impl NaN/Inf counts move closer.
-4. If multiple boundaries are needed, extend in reference op-graph order; do not blindly patch every edge at once.
-5. Apply only to fp16. bf16 and fp32 should use their own parity rules.
-
-## 6. Common mistakes
-
-| Mistake | Problem | Recommended fix |
-|---|---|---|
-| Direct `v.to(tl.float16)` | Triton-Ascend may saturate to `65504` and never produce `inf` | Use `materialize_fp16_overflow` at the required boundary |
-| Compute everything in fp32 and cast once | Skips the reference fp16 overflow point | Materialize at the same fp16 op boundaries as the reference |
-| Patch every possible site blindly | Multi-term NaN/Inf interactions may move to the wrong positions | Validate one site first, then extend in op-graph order |
-| Apply the same logic to bf16 | bf16 normally has enough exponent range | Use bf16 round-half-to-even parity instead |
-
-## 7. Related pages
-
-- Finite low-precision mismatch: [low-precision rounding parity](lowprecision-rounding-parity.md).
-- fp16 compute precision mismatch: [fp16 native chain parity](fp16-native-chain-parity.md).
-- Math intrinsic behavior: check the libdevice usage page when the overflow source is `exp`, `tanh`, or `pow`.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/languages/triton-ascend/hint-mode.md

@@ -1,58 +0,0 @@
----
-id: skill-triton-ascend-hint-mode
-title: "Triton Ascend Hint Mode: Parameter Space Configuration"
-type: skill
-vendor: ascend
-tags:
-- triton-ascend
-- autotune
-evidence_level: spec
-applies_to:
-- ascend910b
-source:
-- path: local
-  anchor: AscendOpGenAgent/skills
-architectures:
-- ascend910b
-languages:
-- triton-ascend
-techniques:
-- autotune
----
-# Hint Mode: Parameter Space Configuration Guide
-
-## Hint Syntax
-
-```python
-# @hint: param in [val1, val2, ...]         -> type='choice'
-# @hint: param in range(min, max, step=N)   -> type='range'
-# @hint: param = value                      -> type='fixed'
-# @hint: param in pow2(min_pow, max_pow)    -> type='power_of_2'
-# @hint: param in pow of 2                  -> type='power_of_2'
-```
-
-Compatible formats:
-```python
-# @range_hint("param", start=min, end=max)
-# @elemwise_hint("param", [val1, val2])
-```
-
-## SPACE_CONFIG Template
-
-```python
-SPACE_CONFIG = {
-    'param1': {'type': 'choice', 'values': [val1, val2, ...]},
-    'param2': {'type': 'range', 'min': min_val, 'max': max_val, 'step': step_val},
-    'param3': {'type': 'power_of_2', 'min_pow': min_exp, 'max_pow': max_exp},
-}
-```
-
-## BLOCK_SIZE Selection
-
-- Small param range (e.g. M in [128, 256]): use [32, 64, 128]
-- Large param range (e.g. M in range(128, 8192)): use [64, 128, 256, 512] with autotune
-
-## Boundary Handling
-
-- **Option A (mask)**: supports arbitrary shapes
-- **Option B (no mask)**: requires shape divisible by BLOCK_SIZE, better performance

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/languages/triton-ascend/int8-quant-rounding-parity.md

@@ -1,134 +0,0 @@
----
-id: skill-triton-ascend-int8-quant-rounding-parity
-title: "Triton Ascend int8 Quantization Rounding Parity"
-type: skill
-vendor: ascend
-tags:
-- triton-ascend
-- quantization
-evidence_level: measured
-applies_to:
-- ascend910b
-source:
-- path: local
-  anchor: int8 dynamic quant rounding parity precision probe
-architectures:
-- ascend910b
-languages:
-- triton-ascend
-kernel_types:
-- quantization
-aliases:
-- int8 quant rounding
-- dynamic quant parity
-- per-token quant
-- per-row quant
-- DequantSwigluQuant
-- divide by scale
-- do not multiply reciprocal
-- absmax divided by 127
-- round half to even int8
-- rint int8
-- nearbyint int8
-- half to even quant
-- scalar vector division
-- BLOCK_SIZE 1 scalar lowering
-- vector division path
-- int8 off by one
-- golden -1 actual -2
-cann_version: "unknown"
----
-# Triton Ascend int8 Quantization Rounding Parity
-
-## Search Keywords
-
-Simple search terms: int8 quant rounding, dynamic quant parity, per-token quant, per-row quant, DequantSwigluQuant, divide by scale, do not multiply reciprocal, absmax divided by 127, round half to even int8, rint, nearbyint, scalar vector division, BLOCK_SIZE 1 scalar lowering, vector division path, int8 off by one, golden -1 actual -2.
-
-## 1. Problem
-
-Per-row / per-token dynamic int8 quantization is highly sensitive at 1-ULP boundaries. The reference is usually:
-
-```python
-absmax = s.abs().amax(-1)
-scale = absmax / 127
-q = (s / scale).round().clamp(-128, 127)
-```
-
-If a Triton-Ascend kernel rewrites this as:
-
-```python
-q = (s * (127 / absmax)).round()
-```
-
-the math is equivalent, but the fp32 rounding path is different. Values near a `.5` quantization boundary can flip from `-1` to `-2`, producing int8 off-by-one mismatches.
-
-## 2. Rule 1: divide by scale; do not multiply by reciprocal
-
-Correct order:
-
-```python
-scale = absmax / 127.0
-qf = s / scale
-q = rint(qf)
-q = clamp(q, -128, 127)
-```
-
-Do not rewrite it as:
-
-```python
-qf = s * (127.0 / absmax)
-```
-
-`x / (absmax / 127)` and `x * (127 / absmax)` can differ by around 1 ULP in fp32, enough to flip a `.5` rounding boundary.
-
-## 3. Rule 2: use half-to-even rounding
-
-PyTorch `torch.round` is round-half-to-even. In Triton-Ascend, use a half-to-even `rint` / `nearbyint` path. Avoid:
-
-```python
-floor(x + 0.5)       # half-up
-trunc/away-from-zero # half-away
-```
-
-After rounding, clamp:
-
-```python
-q = clamp(q, -128, 127)
-```
-
-If `absmax == 0`, force the entire row to zero to avoid division-by-zero artifacts.
-
-## 4. Rule 3: avoid scalar division codegen
-
-Even with the correct `s / scale` order, Triton-Ascend may generate different code for scalar and vector float division, causing 1–2 ULP differences. A common sensitive step is:
-
-```python
-scale = max_abs / 127.0
-```
-
-If this lowers to the scalar path, the later `round(x / scale)` can flip an int8 boundary.
-
-Recommendations:
-
-- Compute scale division on a vector path with `tl.arange(0, BLOCK_SIZE)` and `BLOCK_SIZE >= 2`.
-- Avoid `BLOCK_SIZE == 1`; the compiler can re-scalarize it.
-- If scale is one value per row, a separate `compute_scale_kernel` over the row-max vector is often clean.
-- Vectorize the entire quantization chain, including `max/127` and `x/scale + round`.
-
-## 5. Evaluation gate matters
-
-Different verifiers lead to different conclusions:
-
-- Mean-error gate: a few off-by-one values are averaged out; the scale-division fix may be sufficient.
-- Strict per-element gate: any int8 off-by-one fails, so the whole quantization chain must match as closely as possible.
-
-Check the metric before promising a complete pass.
-
-## 6. Checklist
-
-1. If int8 passes almost all cases but has small off-by-one failures, check division order first.
-2. Write `scale = absmax / 127`, then `s / scale`.
-3. Use half-to-even `rint` / `nearbyint`.
-4. Avoid `floor(x + 0.5)` and half-away-from-zero.
-5. Use `BLOCK_SIZE >= 2` to avoid scalar lowering.
-6. Vectorize both scale division and `x / scale + round`.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/languages/triton-ascend/lowprecision-rounding-parity.md

@@ -1,66 +0,0 @@
----
-id: skill-triton-ascend-lowprecision-rounding-parity
-title: "Triton Ascend Low-Precision Rounding Parity Overview"
-type: skill
-vendor: ascend
-tags:
-- triton-ascend
-evidence_level: measured
-applies_to:
-- ascend910b
-source:
-- path: local
-  anchor: lowprecision rounding parity overview
-architectures:
-- ascend910b
-languages:
-- triton-ascend
-kernel_types:
-- elementwise
-- reduction
-- attention
-- quantization
-aliases:
-- low precision rounding parity
-- torch_npu precision mismatch
-- Triton-Ascend precision mismatch
-- bf16 fp16 parity
-- rounding boundary mismatch
-- low dtype materialization
-- per op materialization
-- allclose fail low precision
-cann_version: "unknown"
----
-# Triton Ascend Low-Precision Rounding Parity Overview
-
-## Search Keywords
-
-Simple search terms: low precision rounding parity, torch_npu precision mismatch, Triton-Ascend precision mismatch, bf16 fp16 parity, rounding boundary mismatch, low dtype materialization, per-op materialization, allclose fail low precision.
-
-## 1. Triage
-
-When the reference is torch_npu and the candidate is a fused Triton-Ascend kernel, low-precision failures often come from missing reference materialization boundaries rather than from an incorrect algorithm.
-
-Route by dtype and symptom:
-
-| Symptom | First page to check |
-|---|---|
-| bf16 finite allclose fails while fp32 passes | [low-precision materialization pitfall](../../../generic/pitfalls/triton-low-precision-materialization.md) |
-| fp16 finite values or intrinsic behavior differ | [fp16 native chain parity](fp16-native-chain-parity.md) |
-| fp16 NaN/Inf mask differs | [fp16 overflow semantics](fp16-overflow-semantics.md) |
-| Scalar parameters participate in low-precision expressions | pre-round scalar parameters explicitly |
-| int8 dynamic quantization has off-by-one values | [int8 quant rounding parity](int8-quant-rounding-parity.md) |
-
-## 2. Core principles
-
-- Do not blindly promote every intermediate to fp32; the evaluator wants parity with the reference, not maximum mathematical accuracy.
-- bf16 and fp16 require different strategies: bf16 often needs fp32 op + explicit RTNE bit-round; fp16 often needs a native fp16 op chain.
-- Scalars may have been materialized to a low dtype in the reference; pre-round them on the host when needed.
-- int8 quantization `.5` boundaries are sensitive to division order, rounding mode, and scalar-vs-vector codegen.
-- If the reference is an opaque fused vendor op, a per-op rounding recipe may not apply; first confirm that a decomposed op graph exists.
-
-## 3. Related non-precision traps
-
-- Duplicate scatter with undefined reference behavior is not a precision issue; see [scatter duplicate semantics](scatter-duplicate-semantics.md).
-- Wrong N-D gather addressing is not a precision issue; see [N-D index addressing](nd-index-addressing.md).
-- fp16 overflow belongs to NaN/Inf mask parity; see [fp16 overflow semantics](fp16-overflow-semantics.md).