N-Buffer特性介绍

1. 原理介绍

1.1 背景

在NPU（神经网络处理单元）的数值计算中，性能瓶颈往往不在于计算单元本身的处理速度，而在于数据搬运与计算之间的等待延迟。传统编程模式下，数据加载（通常由MTE流水完成）和矩阵计算（由Cube流水执行）采用串行执行方式：计算单元必须等待当前数据块完全加载至片上后才能开始运算；而在计算过程中，数据加载单元又处于空闲状态。这种串行模式导致硬件资源利用率低下，计算流水线上频繁出现“空洞”，严重制约了整体性能。

1.2 原理

N-Buffer 是一种经典的流水线并行优化技术，其核心思想在于通过引入多份缓冲区，实现数据加载与计算的重叠执行，从而有效隐藏数据搬移带来的延迟。

以双缓冲机制为例，通过将芯片内部缓冲区划分为两个独立区域，使得数据搬运与计算任务能够交替进行，避免了因防止数据冲突而引入的等待开销，从而提升了流水线并行度。然而，当数据搬移时间较长或计算粒度较小时，双缓冲机制仍可能出现计算单元空闲、等待数据就绪的情况。

为进一步隐藏数据搬移延迟，可引入四缓冲机制。四缓冲在双缓冲的基础上将缓冲区数量扩展至四个，构建更深层次的流水线结构，进一步增强数据供给与计算执行之间的解耦能力。在高端 NPU 或对性能有极致要求的场景中，还可根据实际流水级数和访存特性，进一步增加缓冲块数量，以实现更高的资源利用率。

计算流水图如下：

如图所示，在传统串行模式下，计算单元与搬运单元无法并行工作，导致计算资源频繁空闲，整体效率显著降低。而在Double Buffer双缓冲（下文简称 DB）模式下，当计算单元正在处理缓冲区0中的数据时，数据加载单元可同时将下一块数据预取至缓冲区1中。通过这种“乒乓”式的流水线机制，计算与搬运过程实现完全重叠，流水线持续饱满，硬件利用率得以大幅提升。

可以在流水图中看到，各级均配置了ping/pong双缓冲区，从而实现“搬运-计算”的无缝重叠。这六个步骤环环相扣，最大限度地提升了硬件利用率。

1.3 预期效果

隐藏搬运延迟：计算单元无需等待数据加载，持续满负荷运转。
提升硬件利用率：MTE2和Cube单元并行工作，接近理论峰值性能。
减少流水间隙：消除计算间的等待时间，实现指令级并行。

2. 实践：使用DB优化matmul计算流水

2.1 代码

以下以一个典型的MatMul计算为例，展示如何改造为DB使能版本。

2.1.1 流水同步事件初始化

由于 MatMul 计算流水线由流水同步事件严格管控，在循环起始处需等待上一轮数据搬运完成后方可继续执行，因此需要提前初始化同步事件标志。在串行版本中，仅初始化了单一组事件标志，所有同步操作均依赖同一标志位，导致不同流水阶段之间无法实现独立的并行执行。

引入DB机制后，可初始化两组独立的事件标志，分别对应 Ping 缓冲区和 Pong 缓冲区。同时，引入 l1PingPong 与 l0PingPong 计数器，用于追踪当前所使用的缓冲区索引，为后续实现乒乓切换机制奠定基础。

串行版本：

constexpr static int16_t ZERO_FLAG = 0;
...

// 流水同步事件初始化
AscendC::SetFlag<AscendC::HardEvent::MTE1_MTE2>(ZERO_FLAG);
AscendC::SetFlag<AscendC::HardEvent::M_MTE1>(ZERO_FLAG);

DB使能版本：

constexpr static int16_t ZERO_FLAG = 0;
constexpr static int16_t FIRST_FLAG = 1;
...

// 初始化变量
uint64_t baseM = 256;
uint64_t l1PingPong = 0;   // L1 ping-pong缓冲区索引
uint64_t l0PingPong = 0;   // L0 ping-pong缓冲区索引
// ... 其他初始化代码

// 流水同步事件初始化（包含两套事件标志）
AscendC::SetFlag<AscendC::HardEvent::MTE1_MTE2>(ZERO_FLAG);
AscendC::SetFlag<AscendC::HardEvent::M_MTE1>(ZERO_FLAG);
AscendC::SetFlag<AscendC::HardEvent::MTE1_MTE2>(FIRST_FLAG);
AscendC::SetFlag<AscendC::HardEvent::M_MTE1>(FIRST_FLAG);

2.1.2 将L1数据搬运到L0A/L0B阶段

串行版本每次搬运操作前，必须等待上一次操作完全结束后方可执行，搬运完成后才能触发下一阶段，整个过程严格串行，硬件资源无法得到充分利用。

通过引入DB机制，可动态选择对应的事件标志进行等待，使得当前缓冲区的计算与下一缓冲区的数据预加载能够并行执行。每次操作完成后，计数器相应递增，实现 Ping/Pong 缓冲区的循环切换，从而形成连续的流水线结构，有效提升硬件资源利用率。

串行版本：

// 等待MTE1搬运完成，触发MTE2启动
AscendC::WaitFlag<AscendC::HardEvent::MTE1_MTE2>(ZERO_FLAG);

// 将L1数据搬运到L0A/L0B
// ... 数据搬运代码

// 标记MTE2搬运完成，触发MTE1启动
AscendC::SetFlag<AscendC::HardEvent::MTE2_MTE1>(ZERO_FLAG);
AscendC::WaitFlag<AscendC::HardEvent::MTE2_MTE1>(ZERO_FLAG);

// ... L0A/L0B搬运至MMAD并计算

// 标记MTE1搬运完成，触发对应L1缓冲区的下一轮MTE2启动
AscendC::SetFlag<AscendC::HardEvent::MTE1_MTE2>(ZERO_FLAG);

DB使能版本：

// 根据当前L1缓冲区索引等待对应事件
uint64_t l1BufId = l1PingPong & 1;
AscendC::WaitFlag<AscendC::HardEvent::MTE1_MTE2>(l1BufId);

// 将L1数据搬运到L0A/L0B
// ... 数据搬运代码

// 标记MTE2搬运完成，触发对应L1缓冲区的MTE1启动
AscendC::SetFlag<AscendC::HardEvent::MTE2_MTE1>(l1BufId);
AscendC::WaitFlag<AscendC::HardEvent::MTE2_MTE1>(l1BufId);

// ... L0A/L0B搬运至MMAD并计算

// 标记MTE1搬运完成，触发对应L1缓冲区的下一轮MTE2启动
AscendC::SetFlag<AscendC::HardEvent::MTE1_MTE2>(l1BufId);
l1PingPong++;

2.1.3 MMAD计算阶段

串行版本采用单一事件标志控制同步，计算单元必须等待数据准备就绪后方可开始运算，反之数据搬运亦须等待计算完成，二者形成相互等待的阻塞关系，严重制约了并行执行效率。

相比之下，DB 方法为 L0 层级引入独立的缓冲区索引与事件标志，使 L0 数据的准备与 MMAD 计算能够重叠执行。当一组 L0 数据送入计算单元时，另一组 L0 数据可同步进行预处理，从而进一步深化流水线并行度，显著提升整体执行效率。

串行版本：

// 等待MMAD计算完成，触发MTE1启动
AscendC::WaitFlag<AscendC::HardEvent::M_MTE1>(ZERO_FLAG);

// 将L0A/L0B数据送入MMAD进行计算
// ... 数据准备代码

// 标记MTE1搬运完成，触发MMAD启动
AscendC::SetFlag<AscendC::HardEvent::MTE1_M>(ZERO_FLAG);
AscendC::WaitFlag<AscendC::HardEvent::MTE1_M>(ZERO_FLAG);

// 执行矩阵乘加计算
AscendC::Te::Mad(
    MmadAtom<MmadTraits<MmadOperation, MmadTraitDefault>>{},
    tensorL0C, tensorAL0, tensorBL0, para);

// 标记MMAD计算完成，触发下一轮MTE1启动
AscendC::SetFlag<AscendC::HardEvent::M_MTE1>(ZERO_FLAG);

DB使能版本：

// 根据当前L0缓冲区索引等待对应事件
uint64_t l0BufId = l0PingPong & 1;
AscendC::WaitFlag<AscendC::HardEvent::M_MTE1>(l0BufId);

// 将L0A/L0B数据送入MMAD进行计算
// ... 数据准备代码

// 标记MTE1搬运完成，触发对应L0缓冲区的MMAD启动
AscendC::SetFlag<AscendC::HardEvent::MTE1_M>(l0BufId);
AscendC::WaitFlag<AscendC::HardEvent::MTE1_M>(l0BufId);

// 执行矩阵乘加计算
AscendC::Te::Mad(
    MmadAtom<MmadTraits<MmadOperation, MmadTraitDefault>>{},
    tensorL0C, tensorAL0, tensorBL0, para);

// 标记MMAD计算完成，触发对应L0缓冲区的下一轮MTE1启动
AscendC::SetFlag<AscendC::HardEvent::M_MTE1>(l0BufId);

l0PingPong++;  // 切换L0缓冲区

2.1.4 fixpipe搬出数据阶段

在结果搬出环节，串行等待方式导致其与计算过程无法有效并行。

相比之下，DB 机制在循环处理结束后，结果搬出操作虽仍可与计算并行执行，从而在一定程度上提升整体性能，但其本质上仍存在串行等待机制，限制了并行效率的充分发挥。

串行版本：

// 等待MMAD计算完成，触发fixpipe搬出数据
AscendC::SetFlag<AscendC::HardEvent::M_FIX>(ZERO_FLAG);
AscendC::WaitFlag<AscendC::HardEvent::M_FIX>(ZERO_FLAG);

// 将L0C结果搬回GM
auto copyL0C2GM = AscendC::Te::MakeCopy(AscendC::Te::CopyL0C2GM{});
AscendC::Te::Copy(copyL0C2GM, gmBlockC_, tensorL0C);

// ... 循环处理

// 释放尾轮多余的事件配置
AscendC::WaitFlag<AscendC::HardEvent::MTE1_MTE2>(ZERO_FLAG);
AscendC::WaitFlag<AscendC::HardEvent::M_MTE1>(ZERO_FLAG);

DB使能版本：

// 等待MMAD计算完成，触发fixpipe搬出数据
AscendC::SetFlag<AscendC::HardEvent::M_FIX>(ZERO_FLAG);
AscendC::WaitFlag<AscendC::HardEvent::M_FIX>(ZERO_FLAG);

// 将L0C结果搬回GM
auto copyL0C2GM = AscendC::Te::MakeCopy(AscendC::Te::CopyL0C2GM{});
AscendC::Te::Copy(copyL0C2GM, gmBlockC_, tensorL0C);
// ... L0C缓冲区切换

// ... 循环处理

// 释放所有事件配置
AscendC::WaitFlag<AscendC::HardEvent::MTE1_MTE2>(ZERO_FLAG);
AscendC::WaitFlag<AscendC::HardEvent::M_MTE1>(ZERO_FLAG);
AscendC::WaitFlag<AscendC::HardEvent::MTE1_MTE2>(FIRST_FLAG);
AscendC::WaitFlag<AscendC::HardEvent::M_MTE1>(FIRST_FLAG);

关键改动点：

引入双缓冲区：定义两个缓冲区
异步搬运：在计算当前块的同时，发起下一次搬运
乒乓切换：通过buffId交替使用缓冲区

2.2 修改注意点

缓冲区大小设置：需要根据硬件L1/L2缓存大小和算子Tiling参数合理设置，避免数据溢出
同步点控制：确保流水同步等待先后顺序与预期执行逻辑一致
多核场景：通过流水ID切换，确保DB与多核并行结合，每个核独立使用双缓冲

3. 性能结果对比

3.1 case前后性能

以基础MatMul算子为例，在相同输入规模（M=1024, K=2048, N=4096）下进行性能测试，通过Profiling工具采集硬件流水线执行状态。

从上图可以看出，在串行执行模式下，计算单元（Cube）与数据搬运单元（MTE2）呈现明显的交替工作状态。当搬运单元加载数据时，计算单元处于空闲等待状态；而当计算单元开始运算时，搬运单元又停止工作。这种“搬-等-算-等”的串行模式导致硬件资源利用率低下，流水线中出现大量空洞，整体执行时间较长。

开启DB特性后，硬件流水线状态发生显著变化。计算单元与搬运单元实现高度并行：在Cube单元处理当前数据块的同时，MTE2单元已经开始预加载下一块数据。从图中可以清晰看到，两条流水线几乎完全重叠，流水线空洞大幅减少，硬件资源得到充分利用。最终体现在执行时间上，算子端到端延迟降低约40%，硬件利用率提升至接近理论峰值。

4. 结论

适用场景：

搬运带宽遇到瓶颈：当单次计算耗时远小于搬运时，带宽遇到瓶颈，开启db可以有效提升搬运效率。
多核并行：每个核独立使用DB，整体收益累加

对于是否可以通过开启DB来提升流水并行度，可以先分析Profiling数据，判断当前瓶颈是计算还是搬运。若搬运时间远大于计算，优先尝试DB优化，同时需要结合Tiling策略，确保切分后的Tile大小可以在开启双buffer后不超出硬件资源，多核使用时注意线程同步。

5. 编译执行

编译样例

从项目根目录启动构建，参考项目README.md

在仓库根目录下完成编译和安装后，进入当前样例目录：

cmake -S . -B build -DNPU_ARCH=dav-3510
cmake --build build --parallel
cmake --install build --prefix ./build_out
cd ./build_out/1_Features/instruction_optimization/n_buffer/

如需单独编译当前样例，可使用以下指令：

cmake --build build --target n_buffer
cp ./Samples/1_Features/instruction_optimization/n_buffer/scripts/* ./build/Samples/1_Features/instruction_optimization/n_buffer/
cd ./build/Samples/1_Features/instruction_optimization/n_buffer/

运行样例

使用可执行文件直接执行算子用例，需要指定矩阵乘维度，并随机生成输入数据。

./n_buffer 1024 2048 4096

运行成功后，终端将打印如下类似信息：

Data generated successfully!

[verify] shape(1024, 4096), elements=4194304 - summary (large matrix, full tensors omitted)
  abs_err: max=2.560000e+02, mean=6.286621e-03, rmse=1.268611e+00
  rel_err: max=6.410256e-03
  count(|abs_err| > 0.001): 103 / 4194304
  cpu golden (top-left 4x4):
tensor([[41984., 41984., 41472., 42752.],
        [41984., 41472., 41216., 42496.],
        [41216., 40960., 40448., 42240.],
        [40704., 40960., 40448., 41984.]], dtype=torch.bfloat16)
  npu out (top-left 4x4):
tensor([[41984., 41984., 41472., 42752.],
        [41984., 41472., 41216., 42496.],
        [41216., 40960., 40448., 42240.],
        [40704., 40960., 40448., 41984.]], dtype=torch.bfloat16)
max abs diff: 256.0
point error count(>0.1): 0/4194304
ratio error count(>0.001): 103/4194304, error ratio: 0.000025
[PASS] NPU results are consistent with CPU.

如果存在精度问题，则会打印错误数据，并显示如下结果。

[ERROR] NPU results differ from CPU.

测试性能运行性能测试脚本，指定矩阵乘法的维度后执行。

python3 profile_matmul.py 1024 2048 4096

打印如下执行结果，证明样例性能测试成功。

[Profile Breakdowm]
+-----------+------------+---------+------------+----------+----------+-------------+----------------+
| candidate | kernel(us) | mac(us) | scalar(us) | mte1(us) | mte2(us) | fixpipe(us) | icache_miss(%) |
+===========+============+=========+============+==========+==========+=============+================+
| n_buffer  |     66.000 |  40.810 |      2.558 |   10.659 |   37.595 |       1.980 |          1.200 |
+-----------+------------+---------+------------+----------+----------+-------------+----------------+

与相同输入规模下的基础 matmul 算子相比：

[Profile Breakdowm]
+-----------+------------+---------+------------+----------+----------+-------------+----------------+
| candidate | kernel(us) | mac(us) | scalar(us) | mte1(us) | mte2(us) | fixpipe(us) | icache_miss(%) |
+===========+============+=========+============+==========+==========+=============+================+
| matmul    |     86.870 |  43.804 |      1.850 |   12.997 |   51.857 |       2.970 |          2.200 |
+-----------+------------+---------+------------+----------+----------+-------------+----------------+

可以看到，整体计算时间显著缩短，性能有所提升。

6. 支持架构

NPU ARCH 3510

N-Buffer特性介绍

1. 原理介绍

1.1 背景

1.2 原理

1.3 预期效果

2. 实践：使用DB优化matmul计算流水

2.1 代码

2.1.1 流水同步事件初始化

2.1.2 将L1数据搬运到L0A/L0B阶段

2.1.3 MMAD计算阶段

2.1.4 fixpipe搬出数据阶段

2.2 修改注意点

3. 性能结果对比

3.1 case前后性能

4. 结论

5. 编译 执行

6. 支持架构

5. 编译执行