【昇腾/AscendC开发】AscendC 910B GM 标量/MTE 双向缓存不一致 Bug 详解

AscendC 910B GM 标量/MTE 双向缓存不一致 Bug 详解

一句话总结

在 910B (DAV_2201) 芯片上，同一块 GM 显存地址，标量赋值（gmPtr[i] = v）和 DMA 搬运（DataCopy）之间没有硬件缓存一致性协议。两个方向都可能写丢或读错，精度误差会膨胀10~100 倍。

1. 背景：910B 的两条"内存通道"

AscendC 的 AICore 访问 GM（显存）时，其实有两条独立的通路：

┌──────────────────────────────────────────────────────────┐ │ AICore │ │ │ │ ┌──────────────────────┐ ┌──────────────────────┐ │ │ │ 标量通路 (DataCache) │ │ MTE 通路 (DMA) │ │ │ │ │ │ │ │ │ │ gmPtr[i] = val │ │ DataCopy / │ │ │ │ gmPtr[i] += val │ │ DataCopyPad │ │ │ │ gmPtr[i] │ │ │ │ │ └──────────┬───────────┘ └──────────┬───────────┘ │ │ │ │ │ └──────────────┼─────────────────────────────┼──────────────┘ │ │ ▼ ▼ ┌─────────────────────────────────────────┐ │ GM (Global Memory) │ └─────────────────────────────────────────┘ ▲ ▲ │ │ 没有一致性协议！一个人写的东西，另一个人不一定看得到

CPU 上有 MESI 等缓存一致性协议，硬件帮你"通知"对端刷缓存。
910B 上没有 —— 这两条路互相不可见。

2. 什么是"标量访问" vs “MTE 搬运”？

简单说：

• 标量写= 你往一个小信箱（DataCache）里塞纸条，等攒够了一批才统一寄出去
• MTE 搬运= 叫搬运工（DMA）一次性把一车货从仓库搬到工作台

问题来了：小信箱和搬运工之间没有对讲机。你塞进去的纸条，搬运工不一定知道；搬运工刚搬走的东西，你的小信箱里可能还留着旧纸条。

3. 生活中的比喻

想象你和小李合租一个仓库：

• 你= 标量通路，写完只在自己的小本子（DataCache）上记一笔
• 小李= MTE 搬运工，只看仓库门牌（DRAM），从不翻你的小本子

场景 A：你先记，小李后搬

1. 你把"还剩 5 个箱子"写在自己的小本子上 ← DataCache 里有新值 2. 小李按门牌去仓库搬货 ← MTE 读 DRAM，看到的是旧值 3 3. 你的小本子和仓库不一致了

场景 B：小李先搬，你后记

1. 小李刚把仓库里"3 个箱子"改成"0 个" ← MTE 写 DRAM（异步，还在路上） 2. 你在仓库门牌上写"还剩 8 个" ← 标量写，覆盖了 DRAM 3. 几秒后小李的 DMA 到了，把你的"8"盖成"0" ← 你的写丢了！

两个方向都会出错

4. Bug 的两个具体方向

方向 1：标量写 → MTE 读

// 标量写：把 computed_value 写到 GM 缓冲区__gm__float*dSF32=/* GM scratch */;for(uint32_ti=0;i<N;i++){dSF32[i]=computed_value;// 进了 DataCache，不一定到 DRAM}// MTE 读：把同一块 GM 搬到 UBDataCopy(ubBuf,dSF32,N);// DMA 直读 DRAM，看不到 DataCache → 读到旧值！

方向 2：MTE 写 → 标量写

// MTE 写：把工作台上的 zeroBuf 搬到 GM（异步！）DataCopy(dWacc,zeroBuf,V*H);// DMA 还在路上// 标量写：在同一地址上累加for(uint32_ti=0;i<V*H;i++){dWacc[i]+=partial_sum;// 你的写可能被迟到的 DMA 盖掉！}

症状：精度误差在1e-3 ~ 2e-2级别（FP16 正常误差约 1e-4），没有任何编译/运行报错，只是结果不对。

5. 简单复现代码（host 端模拟）

下面这段独立可编译的 C++ 代码模拟了910B 的"两条不互通通路"，在标准 CPU 上也能看到类似现象。
它不是 AscendC 代码，但用最少的代码把"双向不一致"这件事演示清楚：

// simulate_910b_incoherence.cpp// 编译：g++ -std=c++17 -O2 simulate_910b_incoherence.cpp -o sim && ./sim//// 模拟 910B 上"标量通路"和"DMA 通路"共享同一块 GM，// 但两边没有缓存一致性协议。#include<cstdio>#include<cstring>#include<vector>// 模拟"标量通路"的小本子（DataCache）staticfloatg_scalar_notebook[16]={0};// 模拟"GM 仓库"（DRAM），刚开始是 0staticfloatg_gm[16]={0};// 模拟"MTE 搬运工"看到的 DRAM 视图staticfloatg_dma_view[16]={0};// 模拟标量通路：把值写进小本子，但不一定立刻同步到 GMvoidscalar_write(inti,floatv){g_scalar_notebook[i]=v;// 910B 上这一步只是写 DataCache，DRAM 还没收到g_gm[i]=v;// 模拟"已同步到 DRAM" —— 但实际硬件不保证}// 模拟 MTE 搬运工：直接读 DRAM（完全不知道小本子的存在）voidmte_read_all(){memcpy(g_dma_view,g_gm,sizeof(g_gm));}// 模拟 MTE 写：搬运工直接把一车"零"倒进 GMvoidmte_write_zeros(){// 标量通路可能不知道搬运工正在路上memset(g_gm,0,sizeof(g_gm));// 910B 上：这是异步 DMA，标量通路的小本子里仍是旧值g_scalar_notebook[0]=42.0f;// 标量写：把自己小本子改了// 如果 DMA 比这个标量写晚到，标量写就被覆盖}intmain(){// ===== 方向 1：标量写 → MTE 读 =====printf("=== 方向 1：标量写 -> MTE 读 ===\n");for(inti=0;i<8;i++)scalar_write(i,(float)(i+1));// 假设标量通路忘了刷回 DataCache，MTE 只看到旧值// （我们手动把"未同步"状态模拟出来：让 g_gm 保持为 0）memset(g_gm,0,sizeof(g_gm));// 模拟 DRAM 实际还是旧值mte_read_all();printf("标量写的期望值: 1 2 3 4 5 6 7 8\n");printf("MTE 读到的实际: ");for(inti=0;i<8;i++)printf("%.0f ",g_dma_view[i]);printf(" ← 全是旧值！\n\n");// ===== 方向 2：MTE 写 → 标量写 =====printf("=== 方向 2：MTE 写 -> 标量写 ===\n");mte_write_zeros();// 搬运工把 GM 清零// 标量通路以为自己在 g_gm[0] 上写了 42，但迟到的 DMA 可能盖掉// 我们模拟"搬运工迟到"：把 g_gm[0] 改回 0g_gm[0]=0.0f;// 模拟迟到的 DMA 写到达printf("标量写期望 g_gm[0] = 42\n");printf("实际 g_gm[0] = %.0f ← 被 DMA 覆盖了！\n",g_gm[0]);return0;}

运行结果（标准 Linux 上即可复现这个"两个方向都不一致"的演示）：

=== 方向 1：标量写 -> MTE 读 === 标量写的期望值: 1 2 3 4 5 6 7 8 MTE 读到的实际: 0 0 0 0 0 0 0 0 ← 全是旧值！ === 方向 2：MTE 写 -> 标量写 === 标量写期望 g_gm[0] = 42 实际 g_gm[0] = 0 ← 被 DMA 覆盖了！

真实 910B 上是硬件帮你"复制粘贴"了这段故事：DataCache 和 DMA 通路对同一地址的写入时序是不确定的，谁最后到 DRAM 谁就赢。

6. 真实 AscendC 代码长什么样？

❌ 错误写法（触发 bug）

// kernel 内：在 GM scratch 上做中间累加__gm__float*dSF32=/* GM scratch */;// 方向 1：标量写 GMfor(uint32_ti=0;i<N;i++){dSF32[i]=computed_value;// ← 写 DataCache}// 方向 1 后续：MTE 读同一块 GMDataCopy(ubBuf,dSF32,N);// ← DMA 看不到 DataCache 的新值// —— 或者 ——// 方向 2：MTE 写 GMDataCopy(dWacc,zeroBuf,V*H);// ← 异步 DMA// 方向 2 后续：标量写同一地址for(uint32_ti=0;i<V*H;i++){dWacc[i]+=partial_sum;// ← 可能被迟到的 DMA 覆盖}

✅ 正确写法（三种策略任选一种）

策略 1（推荐）：在 UB 里完成所有中间计算，根本不碰 GM

TPipe ep;TBuf<TPosition::VECIN>eb;ep.InitBuffer(eb,ubSize);LocalTensor<float>ubBuf=eb.Get<float>(N);// 全程在 UB 中计算for(uint32_ti=0;i<N;i++){ubBuf.SetValue(i,computed_value);}// 最后一次性 DataCopy 到 GMDataCopy(gmOut,ubBuf,N);

策略 2：全程用标量访问，不混 MTE

// 清零：标量写for(uint32_ti=0;i<V*H;i++){dWacc[i]=0.0f;}// 累加：也是标量写（同一通路 → 一致）for(uint32_ti=0;i<V*H;i++){dWacc[i]+=partial;}

策略 3：标量写后显式刷 DataCache

GlobalTensor<DT>gScratch;gScratch.SetGlobalBuffer((__gm__ DT*)scratch);// 标量写for(uint32_ti=0;i<N;i++){gScratch.SetValue(i,(DT)computed_value);}// 显式刷回 DRAMDataCacheCleanAndInvalid<DT,CacheLine::ENTIRE_DATA_CACHE>(gScratch);// 现在 MTE 能读到一致的值DataCopy(ubBuf,gScratch,alignedN);

7. 修复效果

误差从 1e-2 级别压到 1e-4~1e-5，回到 FP16 的正常精度。

8. 教训总结

附录：什么时候应该怀疑这个 bug？

如果你看到以下任意一条，先停下来检查代码里有没有 GM 上的标量/MTE 混用：

• 精度误差在1e-3 ~ 1e-2（FP16 正常 ~1e-4）
• 同样的代码逻辑在 910A / 950 上没问题，只在 910B 上飘
• 消除 GM 中间缓冲后精度恢复正常
• gmPtr[i] = v和DataCopy(..., gmPtr, ...)出现在同一地址
• 没有编译错误、没有运行错误，只是结果不对

满足其中 2~3 条，基本就是这个问题。改成 UB-only 中间计算，立竿见影。