UnitFlag 与 L0C Double Buffer 的适用边界分析 —— 昇腾 950PR（DAV_3510）

0. 问题重述与先验共识

昇腾 950PR 上，Matmul 的标准数据流是：

GM ──MTE2──► L1 ──MTE1──► L0A/L0B ──MMAD──► L0C ──Fixpipe──► GM(C)

其中 L0C 的输出（Fixpipe 搬出）与 Cube 的计算（MMAD）之间存在「谁先谁后」的问题。用户观察到的两条掩盖路径：

1. L0C Double Buffer（dbL0C=2）：L0C 分两份，当前一份在 MMAD 计算，另一份在 Fixpipe 搬出，用「计算-搬出」重叠掩盖 Fixpipe。
2. UnitFlag（细粒度同步）：MMAD 每算完 512B 就立即触发 Fixpipe 搬出该 512B，用「指令级流水」掩盖 Fixpipe。

问题：既然 UnitFlag 能这么细粒度地掩盖，L0C 还需要开 Double Buffer 吗？ 两者的适用边界在哪？

1. 两条掩盖路径的原理性拆解

1.1 L0C Double Buffer 掩盖的是什么

L0C DB 的目标是：当前 base 块的 Fixpipe 搬出 与 下一个 base 块的 MMAD 计算 并行。它的掩盖对象是「base 块与 base 块之间的 Fixpipe 串行等待」。

• 时序（dbL0C=2，方块为 base 块）：

L0C 块0:  MMAD ──► Fixpipe 搬出
L0C 块1:           MMAD ──► Fixpipe 搬出
L0C 块2:                     MMAD ──► Fixpipe 搬出
时间轴:  ────────┬───────┬───────┬──►
                 块0搬出与块1计算重叠   块1搬出与块2计算重叠

• 关键点：没有 L0C DB 时，当前 base 块必须等 Fixpipe 完全搬出才能开始下一个 base 块的 MMAD（L0C 只有一份，搬出期间不能写入）；有 L0C DB 时，下一个 base 块的 MMAD 可以立即在另一份 L0C 上开始，当前块的 Fixpipe 与之并行。

1.2 UnitFlag 掩盖的是什么

UnitFlag 的目标是：单个 base 块内部，MMAD 计算 与 Fixpipe 搬出 的细粒度并行。它的掩盖对象是「单个 base 块内部的 MMAD-Fixpipe 串行等待」。

• 官方定义（《Matmul高阶API开启UnitFlag》）：UnitFlag 为 MMAD 计算指令和 FIXPIPE 搬运指令提供基于内存访问的 512B 细粒度同步，使计算与搬运流水并行。未开启时，FIXPIPE 要等整条 MMAD 指令算完才搬出；开启后，MMAD 每算完 512B 数据，FIXPIPE 立即搬出该 512B。

• 时序（单个 base 块内）：

未开 UnitFlag:  MMAD(整个base块) ──────► Fixpipe(整个base块)
开 UnitFlag:    MMAD[512B] ─► Fixpipe[512B]
                  MMAD[512B] ─► Fixpipe[512B]   ...
                （512B 粒度交错，计算与搬出重叠）

• 用户观察「最多剩一个小小的 16×16 尾巴 Fixpipe 输出不可掩盖」是对的：最后一个 512B 块算完后，它的 Fixpipe 没有后续 MMAD 可重叠，是尾开销。但相比整个 base 块的 Fixpipe 串行等待，这个尾开销很小。

1.3 两者的关系：掩盖对象不同，可叠加

关键结论：两者不互为替代，而是掩盖不同层级的串行。一个 base 块的完整耗时可以拆解为：

T_base_block ≈ max(T_MMAD_base, T_MTE1_base, T_MTE2_base) + T_Fixpipe_base_tail

• T_MMAD_base：该 base 块的 MMAD 计算时间；
• T_Fixpipe_base_tail：Fixpipe 搬出该 base 块的时间中无法被掩盖的部分。

开 L0C DB 的效果：下一个 base 块的 MMAD 可以并行启动，把「当前块 Fixpipe」的时间藏进下一个块的 MMAD 里。但如果当前块的 MMAD 本身就比 Fixpipe 短（计算快、搬出慢），下一个块的 MMAD 很快算完，又要等当前块的 Fixpipe → L0C DB 掩盖不住「计算远快于搬出」的场景。

开 UnitFlag 的效果：把当前块内部的 MMAD 与 Fixpipe 交错，Fixpipe 不再等整个 base 块算完，而是边算边搬。即使当前块 MMAD 很快，Fixpipe 也能跟着 MMAD 的进度流水走，把大部分搬出时间藏进 MMAD 里。

所以：L0C DB 掩盖「块间」串行，UnitFlag 掩盖「块内」串行；在「单块 MMAD 短、Fixpipe 长」的场景，L0C DB 掩盖不住，必须靠 UnitFlag；在「单块 MMAD 长、Fixpipe 短」的场景，L0C DB 已足够，UnitFlag 收益小。

2. mat_mul_v3 中两者的实际使用场景

2.1 L0C Double Buffer 的使用场景（Host tiling 决策）

mat_mul_v3 的 L0C DB 由 Host tiling 层计算 runInfo.dbL0C，写入 tiling data 的 dbL0C/l0cDB 字段，Device 侧消费。源码中 dbL0C 的设置点：

核心条件统一为：

dbL0C = (baseM · baseN · DATA_SIZE_FP32 · DB_SIZE ≤ L0C容量) ? 2 : 1

代入 950PR 数值（L0C=256KB=262144B，DATA_SIZE_FP32=4B，DB_SIZE=2）：

baseM·baseN·4·2 ≤ 262144  →  baseM·baseN ≤ 32768 = 2^15

baseM=baseN=256 时：256·256 = 65536 > 32768 → dbL0C=1（关）。

baseM=256、baseN=128 时：256·128 = 32768 → dbL0C=2（开）。

物理含义：baseM=baseN=256 的 FP32 累加块恰好填满整个 L0C（256KB），开不了 DB；只有把 baseN（或 baseM）砍到一半，L0C 才能容纳两份，才能开 DB。这与「baseM=baseN=256 是重复读最少的最优解」存在张力：base 块取 256×256 时，L0C 被占满，无法用 DB 掩盖 Fixpipe。

使用场景总结：mat_mul_v3 中，L0C DB 在绝大多数分支都可能开启（普通 ASWT、A/B 全载、StreamK 复用同一引擎），但前提都是 baseM·baseN ≤ 32768。当最优 base 块是 256×256 时，dbL0C 强制为 1。

2.2 UnitFlag 的使用场景（Device kernel 开启）

mat_mul_v3 中 UnitFlag 由 kernel 侧的 MatmulConfig.enUnitFlag 或自定义搬出回调的 fixpipeParams.unitFlag 控制。检索结果：

• 全局默认配置：mat_mul_v3_common.h 定义 MM_CFG_NO_PRELOAD = GetMDLConfig(..., true)（最后一个参数即 enUnitFlag）。多个 kernel（MatMulBasicKernel 等）默认 MM_CFG = MM_CFG_NO_PRELOAD。但 GetMDLConfig 是 MDL 模板，官方文档明确「MDL 下 enUnitFlag 默认不使能」，且 GetMDLConfig 的具体默认参数需查 API 文档——MM_CFG_NO_PRELOAD 的 enUnitFlag 实际生效值取决于 GetMDLConfig 的实现，不能直接断言 mat_mul_v3 所有路径都开了 UnitFlag。

• 唯一显式开启点：mat_mul_stream_k_kernel.h:36-37（StreamK 的自定义搬出回调 CustomDataCopyOut）：

if (params->enUnitFlag) {
    fixpipeParams.unitFlag = MM_FIX_PIPE_UNIT_FLAG; // 使能unitflag的参数 3U
}

这里 params->enUnitFlag 来自上层传入的搬出参数，unitFlag = 3U 直接写进 FixpipeParamsC310。

使用场景总结：mat_mul_v3 中 UnitFlag 的显式、确定开启只发生在 StreamK 分支的自定义搬出回调里（StreamK 的部分和需要从 L0C 搬到 GM workspace，再由 AIV 累加，搬出路径特殊）。普通 ASWT/A/B 全载分支是否开 UnitFlag，取决于 GetMDLConfig 的默认值（官方口径：MDL 模板默认不使能），源码没有显式强制开启。

3. 适用条件边界：什么时候用哪个

3.1 L0C Double Buffer 的适用边界

典型受益场景：baseM=256、baseN=128 的矩形 base 块，多 base 块循环，MMAD 与 Fixpipe 耗时相当。

3.2 UnitFlag 的适用边界（官方文档明确约束）

典型受益场景：单个 base 块内 MMAD 很快、Fixpipe 慢（如小 K、大 MN），且模板是 Norm/IBShare/MDL、无 L1→GM 混合搬出。

3.3 两者的叠加与互斥判断

从官方约束与源码实现看：

• 可叠加：L0C DB 是 Host 层的 buffer 划分，UnitFlag 是 Device 层的指令同步，两者作用于不同层级，不冲突。isA2B2Shared 字段说明里甚至建议「开启 A2B2 共享时同时设 enUnitFlag=true」。
• 不互斥，但有先后：baseM=baseN=256 时 L0C 开不了 DB（容量不够），此时若 Fixpipe 是瓶颈，只能靠 UnitFlag 在块内掩盖；baseM·baseN≤32768 时 DB 可开，块间掩盖由 DB 负责，块内细粒度掩盖仍可由 UnitFlag 补充。
• StreamK 的特殊性：StreamK 的搬出是「L0C→workspace→AIV 累加→GM」，不是直接 L0C→GM，且用自定义回调显式开了 UnitFlag——因为 StreamK 的部分和搬出频繁、且与计算强相关，细粒度同步收益大。

4. 对用户问题的直接回答

存在。Host 层 dbL0C 在 baseM·baseN·4B·2 ≤ L0C(256KB)（即 baseM·baseN ≤ 32768）时置 2，普通 ASWT、A/B 全载、StreamK（复用同一引擎）都会走到。但当最优 base 块是 256×256 时，dbL0C=1（开不了）。

存在，且显式开启点唯一：StreamK 分支的自定义搬出回调 CustomDataCopyOut（mat_mul_stream_k_kernel.h），在 params->enUnitFlag 为真时设 fixpipeParams.unitFlag = 3U。普通 ASWT 分支的 UnitFlag 状态取决于 MM_CFG_NO_PRELOAD（GetMDLConfig）的默认值——官方口径 MDL 默认不使能，因此普通 ASWT 路径上 UnitFlag 大概率是关的，需对照 GetMDLConfig 实际参数确认。

• L0C DB：掩盖「base 块之间」的 Fixpipe 串行，要求 L0C 能容两份 base 块（baseM·baseN≤32768），适合多 base 块、MMAD 与 Fixpipe 耗时相当的场景。
• UnitFlag：掩盖「base 块内部」的 MMAD-Fixpipe 串行，512B 细粒度，适合单块 MMAD 快、Fixpipe 慢的场景；但受模板（Norm/IBShare/MDL）、流水互斥（不能同时 CO1→GM 和 A1→GM）、累加方式（不能多次 Iterate 一次输出）约束，MDL 默认关。

不是。两者掩盖对象不同：L0C DB 掩盖块间、UnitFlag 掩盖块内。在「单块 MMAD 长、多块循环」的场景，L0C DB 已能很好掩盖，UnitFlag 收益小；在「单块 MMAD 短、Fixpipe 长」的场景，L0C DB 掩盖不住（下一块 MMAD 很快算完又要等当前块搬出），必须靠 UnitFlag。两者是正交互补，不是替代关系。

5. 对 mat_mul_v3 的观察与后续建议

1. UnitFlag 在普通 ASWT 路径的默认状态需确认：MM_CFG_NO_PRELOAD = GetMDLConfig(..., true) 的最后一个参数是否真是 enUnitFlag、MDL 默认值是否生效，建议对照 GetMDLConfig API 文档核实。若普通 ASWT 默认未开 UnitFlag，而 StreamK 开了，两者在 Fixpipe 掩盖上的行为不一致，值得在性能模型里区分。
2. dbL0C 与 baseM/baseN 的耦合：dbL0C 直接由 baseM·baseN 决定，但 baseM/baseN 的搜索（GetRebalanceBlock）目标是 CubeBound + 负载均衡，没有把「dbL0C 能否开」纳入目标函数。当 256×256（开不了 DB）与 256×128（能开 DB）性能接近时，模型可能选前者而牺牲 DB 收益——这是一个潜在的 tiling 改进点。
3. 性能模型需区分两种掩盖机制：后续 Phase 1 的 T_total = max(...) 模型里，Fixpipe 项应区分「块间掩盖（DB）」和「块内掩盖（UnitFlag）」，否则对 Fixpipe Bound 场景会高估或低估。

附录：关键证据索引