一键导入
triton-ascend-ascend-hardware-constraints
Ascend 硬件约束与编译器限制速查。涵盖 CUBE/VEC 存储层级预算计算方法、bishengIR 编译器已知限制、strided access 性能特征。适用于所有 Triton Ascend 算子生成和调试场景。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Ascend 硬件约束与编译器限制速查。涵盖 CUBE/VEC 存储层级预算计算方法、bishengIR 编译器已知限制、strided access 性能特征。适用于所有 Triton Ascend 算子生成和调试场景。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
矩阵乘法矩阵乘法 A[M, K] @ B[K, N] = C[M, N]中,大K维度矩阵乘法(K>>M,N)优化:针对M/N较小但K极大(如M=N=256,K=131072)的场景,Split-K切分K维度并行化、Workspace+Reduce替代全局同步,实现显著性能提升
Triton Ascend hard API restrictions and forbidden syntax. MUST-follow rules that apply to every kernel: forbidden control flow (return/break/continue/lambda/while), tensor slice/index restrictions, scalar conversion rules, BLOCK_SIZE upper bound. Violating any of these produces a compile or runtime error on Ascend.
Triton Ascend 性能优化通用策略: BLOCK_SIZE 选择 (1024-2048 for elementwise, must be <65536), grid configuration (use VEC_CORE_NUM / CUBE_CORE_NUM, 2D/3D grid for matmul / conv / reduce, 1D grid + inner loop for elementwise / pointwise), 256B alignment for memory transfers, autotune block-size patterns, fp16 / fp32 precision conversion. Bind via keywords like matmul, elementwise, reduce, block_size, grid, autotune, alignment, fp16, fp32, tile, interleaved-loop, cube-core, vec-core.
通过 adaptive_search 或 evolve 搜索式 workflow 生成优化算子。 后台 silent mode 执行,轮询监控进度。
适用于归约(reduce)类算子和含归约子步骤的复合算子(如归一化)的优化指南。典型算子包括:sum, mean, max, min, prod, argmax, argmin, cumsum, cumprod, softmax, logsoftmax, layernorm, rmsnorm, groupnorm, instancenorm, batchnorm, l1norm, l2norm, frobeniusnorm, var, std, average_pooling, sum_pooling 等。特别重要:当归约维度不是最后一维(如 dim=1 归约 shape=[B,F,D1,D2]),需要正确处理多维索引和两阶段归约。包含 PyTorch normalized_shape 多轴归一化语义说明。不适用于纯逐元素运算或矩阵乘法。如果算子是损失函数(先逐元素计算再全局归约),应选择 elementwise-reduce-fused 指南。
CPU C++ 算子核心概念、标准结构模式、KernelBench 代码规范和内嵌扩展方法
| name | triton-ascend-ascend-hardware-constraints |
| description | Ascend 硬件约束与编译器限制速查。涵盖 CUBE/VEC 存储层级预算计算方法、bishengIR 编译器已知限制、strided access 性能特征。适用于所有 Triton Ascend 算子生成和调试场景。 |
| category | fundamental |
| version | 1.0.0 |
| metadata | {"backend":"ascend","dsl":"triton_ascend","hardware":"Atlas A2, Atlas A3","operator_type":"all"} |
不同型号的硬件具体容量不同,算子生成时会同步传入硬件信息文档,以下公式中的容量值请参考该文档。
Matmul 数据走 L0A/L0B/L0C,不经过 UB:
| 缓冲区 | 用途 | 约束公式 |
|---|---|---|
| L0A | 左矩阵 A tile (m0 × k0) | m0 × k0 × sizeof(A.dtype) ≤ L0A容量 |
| L0B | 右矩阵 B tile (k0 × n0) | k0 × n0 × sizeof(B.dtype) ≤ L0B容量 |
| L0C | 结果 C tile (m0 × n0),支持累加 | m0 × n0 × sizeof(C.dtype) ≤ L0C容量 |
计算示例(以某硬件 L0A = 64KB 为例):
选择 tile 尺寸时,确保三个缓冲区都不超限。fp32 占用是 fp16 的 2 倍,需相应缩小 tile。
向量运算数据走 UB:
| 缓冲区 | 用途 | 约束公式 |
|---|---|---|
| UB | 所有活跃 tensor 和中间变量 | BLOCK_SIZE × sizeof(dtype) × 活跃tensor数 × multi_buffer系数 ≤ UB容量 |
编译器启用 auto-multi-buffer 后,实际占用约为基础量的 2~3 倍。kernel 中的中间变量(如 tl.where 产生的临时缓冲)也占用 UB,实际占用会显著高于 BLOCK_SIZE × sizeof(dtype) × 输入数。
tile 选择策略:从较大 BLOCK_SIZE 开始尝试,遇到 ub overflow 编译错误时逐级缩小。
# 编译器崩溃(bishengIR SIGABRT)
for k in range(start_n, start_m + BLOCK, BLOCK_K):
...
start_n、start_m 是运行时值,BLOCK、BLOCK_K 是 tl.constexpr。这种混合用法会导致编译器内部错误。
规避方案:使用全 constexpr 的 range,在循环体内用运行时 if 跳过无效迭代:
for k in range(0, N, BLOCK_K): # N 和 BLOCK_K 都是 constexpr
# 可选:运行时条件跳过无效块
...
当嵌套 mask 组合传入 tl.where 时,编译器后端可能报 hivm.hir.vsel: Unsupported op for finding the root alloc。
规避方案:用乘法替代 tl.where,将 bool mask 转为 float 后与数据相乘:
# 触发 hivm.hir.vsel 错误
a = tl.where(tri_mask & bounds_mask, a, 0.0)
# 规避:mask 转 float 后相乘
a = a * tri_mask.to(tl.float16) * bounds_mask.to(tl.float16)
详见 debugging 文档中的「禁止使用的语法」完整列表。
Ascend 硬件对非连续内存访问有显著性能惩罚。当 kernel 的核心路径包含 stride > 1 的内存访问模式(如 pooling 的滑窗、dilated convolution 的间隔采样),Triton 生成的代码需要逐元素或小块 gather,而 CANN 原生算子可能使用硬件数据搬运单元(MTE)的专用模式,性能差距可达数十倍。
建议:
F.pad + contiguous view),再用连续 load 处理