人工智能编译器模型编译高性能计算深度学习CANN【免费下载链接】pyptoPyPTO发音: pai p-t-oParallel Tensor/Tile Operation编程范式。项目地址https://gitcode.com/cann/pypto点击查看免费下载导读本文以 PyPTO 项目 SIMD-API 中的同步控制文档为主体系统讲解 Ascend 950 系列A5上 Kernel 编程所需的全部同步原语核内流水同步sync_src/sync_dst、单流水屏障bar_m/bar_mte1/bar_mte2/bar_mte3/bar_fix、全流水屏障bar_all、缓冲区互斥mutex_lock/mutex_unlock以及跨核同步set_cross_core/wait_cross_core/sync_all。读完本文你将理解 AI Core 内部多条并行流水之间的数据依赖模型掌握在 Vector/Cube 区段中正确编排同步指令、避免数据竞争与死锁的完整方法并能在自己的 PyPTO Kernel 中直接复用文中的可运行示例。产品支持情况本目录全部接口仅支持Ascend 950PR/Ascend 950DTA5 系列Atlas A3 训练/推理系列与 Atlas A2 训练/推理系列均不支持。源码侧同步控制相关 ST 测试也通过_require_a5与pytest.mark.soc(950)限定运行设备参见 test_pipe_barriers.py。一、前置知识AI Core 的并行流水模型理解同步控制的前提是认识 AI 处理器内部的并行流水结构。PyPTO 用pypto_pro.language.PipeType枚举标记操作运行在哪条硬件流水上其完整定义与职责如下详见 PipeType.md枚举值职责MTE1搬运流水 1L1 Buffer → L0A/L0B/BiasTable/L0A_MX/L0B_MX BufferMTE2搬运流水 2GM → L1 Buffer/UB 的 load 搬入MTE3搬运流水 3UB → GM 的 store 搬出、UB → L1 Buffer 的 moveM矩阵计算流水Cube/MAD 等 matmul 计算V向量计算流水element-wise、reduce、cast、quant、dequant 等S标量流水getval、setval 等标量操作FIXFixpipe 流水L0C Buffer 结果读出及随路量化/反量化ALL本 AI Core 的全部流水V、M、MTE1、MTE2、MTE3、FIX 等数据搬运操作load/store/move的流水由源/目的内存空间自动决定loadGM→UB/L1走 MTE2storeUB→GM走 MTE3storeL0C→GM走 FIXmoveL1→L0A/L0B走 MTE1moveUB→UB走 V 等。由于不同流水并行执行上游流水尚未完成的数据读写下游流水可能已经开始执行这正是同步控制要解决的问题。二、核内流水同步sync_src 与 sync_dst2.1 功能与原理sync_src与sync_dst用于同一 AI Core 内不同流水之间的点对点同步二者必须配对使用sync_src(set_pipe..., wait_pipe..., event_id...)当set_pipe中位于本接口之前的所有数据读写操作完成后将对应标志位置 1Set Flag。该接口不会阻塞set_pipe中位于其后的操作。sync_dst(set_pipe..., wait_pipe..., event_id...)当wait_pipe执行到本接口时若对应标志位为 0则wait_pipe中位于本接口之后的操作被阻塞若标志位为 1则清零并继续执行Wait Flag。这一置位不阻塞发送方、等待阻塞接收方的设计让搬运流水MTE2/MTE3与计算流水V/M/FIX之间可以流水化并行只在数据依赖点精确停靠。底层实现中两个接口在 system_ops.py 分别生成system.sync_src与system.sync_dstIR 调用校验set_pipe/wait_pipe为具体流水并检查event_id范围。2.2 参数说明参数输入/输出说明set_pipe输入源流水发送同步事件的流水。必须为具体流水不支持PipeType.ALL且必须与wait_pipe不同wait_pipe输入目的流水等待同步事件的流水。必须为与set_pipe不同的具体流水不支持PipeType.ALLevent_id输入事件 ID。支持 Python int、整型常量表达式或整型运行时 Scalar不支持 bool取值范围[0, 7]2.3 支持的流水组合Vector 段支持的组合set_pipe支持的 wait_pipeMTE2V、MTE3、SMTE3V、MTE2、SVMTE2、MTE3、SSV、MTE2、MTE3Cube 段支持的组合set_pipe支持的 wait_pipeMTE1MTE2、M、MTE3、FIXMTE2MTE1、M、MTE3、S、FIXMTE3MTE1、MTE2、SMMTE1、MTE2、FIX、SSMTE2、MTE3FIXM、MTE2、S、MTE3、MTE12.4 典型同步模式场景set_pipewait_pipe说明load 后进行向量计算MTE2VGM 数据搬入 UB/L1 后再计算向量计算后 storeVMTE3计算完成后再搬出到 GMstore 后再次 loadMTE3MTE2搬出到 GM 后再向相同 Buffer 搬入新数据L1→L0A 搬运后矩阵计算MTE1M确保矩阵操作数就位matmul 后 FIX 读出结果MFIX确保矩阵计算完成标量读写MTE2/MTE3Sgetval/setval 走标量流水2.5 调用示例以下示例先经 MTE2 把两个 FP32 输入从 GM 搬入 UB再用MTE2→V同步确保搬运完成执行pl.add计算完成后用V→MTE3同步确保计算完成最后pl.store写回 GM。该示例与 ST 测试 test_sync_src_dst 中的sync_src_dst_kernel完全一致测试在 Ascend 950 上断言out a b。import pypto_pro.language as pl pl.jit() def sync_src_dst_kernel( a: pl.Tensor[[64, 64], pl.DT_FP32], b: pl.Tensor[[64, 64], pl.DT_FP32], out: pl.Tensor[[64, 64], pl.DT_FP32], ): tt pl.TileType(shape[64, 64], dtypepl.DT_FP32, target_memorypl.MemorySpace.Vec) tile_a pl.make_tile(tt, addr0x0000) tile_b pl.make_tile(tt, addr0x4000) tile_out pl.make_tile(tt, addr0x8000) with pl.section_vector(): pl.load(tile_a, a, [0, 0]) pl.load(tile_b, b, [0, 0]) pl.system.sync_src(set_pipepl.PipeType.MTE2, wait_pipepl.PipeType.V, event_id0) pl.system.sync_dst(set_pipepl.PipeType.MTE2, wait_pipepl.PipeType.V, event_id0) pl.add(tile_out, tile_a, tile_b) pl.system.sync_src(set_pipepl.PipeType.V, wait_pipepl.PipeType.MTE3, event_id1) pl.system.sync_dst(set_pipepl.PipeType.V, wait_pipepl.PipeType.MTE3, event_id1) pl.store(out, tile_out, [0, 0])2.6 约束要点两个接口的set_pipe、wait_pipe、event_id必须完全一致且先sync_src后sync_dst。同一 set_pipe/wait_pipe 组合下同一event_id只能在前一次sync_dst完成等待后复用连续调用sync_src、漏写配对接口或两个接口所在控制流路径不一致都可能造成数据竞争或死锁。与auto_mutexTrue同时使用时应确保显式同步与自动 mutex 分别处理明确的依赖避免对同一依赖重复同步。三、单流水屏障bar_m / bar_mte1 / bar_mte2 / bar_mte3 / bar_fix当只需要等待某一条流水时应使用对应的单流水屏障接口避免bar_all带来的全局停顿开销。这些接口均无参数、无返回值仅等待当前 AI Core 内对应流水中此前下发的操作完成不执行跨核同步。IR 层统一通过_create_barrier_op生成system.bar_*调用参见 system_ops.py。接口等待的流水可调用区段特别约束bar_mM矩阵计算仅 Cube 区段等待 M 流水矩阵操作完成bar_mte1MTE1仅 Cube 区段等待 MTE1 搬运完成bar_mte2MTE2Cube 或 Vector 区段连续 MTE2 搬入写入的片上地址重叠时两次搬入之间必须调用否则产生错误数据bar_mte3MTE3Cube 或 Vector 区段连续 MTE3 搬出写入的GM 地址重叠时两次搬出之间必须调用否则产生错误数据bar_fixFIX仅 Cube 区段等待 FIX 流水操作完成bar_mte2与bar_mte3的地址重叠约束是最常见的正确性陷阱当循环复用同一块片上 Buffer 反复搬入/搬出数据时若不在轮次之间插入对应屏障前一次 DMA 尚未完成、下一次 DMA 已改写同一地址将读到错误数据。例如循环内复用 UB 的场景with pl.section_vector(): for i in pl.range(0, 128, 64): pl.load(tile_x, x, [i, 0]) # MTE2 搬入 pl.system.sync_src(set_pipepl.PipeType.MTE2, wait_pipepl.PipeType.V, event_id0) pl.system.sync_dst(set_pipepl.PipeType.MTE2, wait_pipepl.PipeType.V, event_id0) pl.add(tile_out, tile_x, tile_x) # V 计算 pl.system.sync_src(set_pipepl.PipeType.V, wait_pipepl.PipeType.MTE3, event_id1) pl.system.sync_dst(set_pipepl.PipeType.V, wait_pipepl.PipeType.MTE3, event_id1) pl.store(out, tile_out, [i, 0]) # MTE3 搬出Cube 区段中的bar_m可用于强制两次连续 matmul 串行化如累加复用 L0C 的场景见 bar_m.md 示例。四、全流水屏障bar_allpypto_pro.language.system.bar_all() - Nonebar_all等待当前 AI Core 内 V、M、MTE1、MTE2、MTE3 和 FIX 等全部流水此前下发的操作完成可在 Cube 区段或 Vector 区段调用。需要特别注意它仅是核内全流水屏障不是多核之间的全局屏障多核同步请使用sync_all。它会让当前 AI Core 的全部流水停顿可能影响性能只需等待一条流水时应优先使用对应单流水屏障接口。典型用途是循环体顶部的全流水同步确保上一轮迭代的 store 全部完成后再开始本轮 load。文档示例与 ST 测试 test_bar_all 中的bar_all_kernel一致import pypto_pro.language as pl pl.jit() def bar_all_kernel( x: pl.Tensor[[128, 64], pl.DT_FP16], out: pl.Tensor[[128, 64], pl.DT_FP16], ): tt pl.TileType(shape[64, 64], dtypepl.DT_FP16, target_memorypl.MemorySpace.Vec) tile_x pl.make_tile(tt, addr0x0000) tile_out pl.make_tile(tt, addr0x2000) with pl.section_vector(): for i in pl.range(0, 128, 64): pl.system.bar_all() # 等待上一轮全部流水完成 pl.load(tile_x, x, [i, 0]) pl.system.sync_src(set_pipepl.PipeType.MTE2, wait_pipepl.PipeType.V, event_id0) pl.system.sync_dst(set_pipepl.PipeType.MTE2, wait_pipepl.PipeType.V, event_id0) pl.add(tile_out, tile_x, tile_x) pl.system.sync_src(set_pipepl.PipeType.V, wait_pipepl.PipeType.MTE3, event_id1) pl.system.sync_dst(set_pipepl.PipeType.V, wait_pipepl.PipeType.MTE3, event_id1) pl.store(out, tile_out, [i, 0])五、缓冲区互斥mutex_lock 与 mutex_unlock5.1 功能与原理mutex_lock在指定 pipe 上获取mutex_id对应的缓冲区互斥资源buffer-id token资源尚未释放时当前 pipe 等待直到能够获取mutex_unlock释放该资源使等待的其他 pipe 继续执行。二者用于防止多条 pipe 同时访问同一片上缓冲区其 IR 实现位于 system_ops.py。pypto_pro.language.system.mutex_lock( *, pipe: PipeType, mutex_id: Union[int, Scalar], ) - None pypto_pro.language.system.mutex_unlock( *, pipe: PipeType, mutex_id: Union[int, Scalar], ) - None5.2 参数说明参数输入/输出说明pipe输入PipeType枚举值必须是 MTE1/MTE2/MTE3/V/M/S/FIX 中的一条具体 pipe不允许PipeType.ALLmutex_id输入Python 整数、结果为整数的常量表达式或整型的运行时 Scalar 表达式。静态 ID 取值范围 [0, 31]不接受 bool动态 ID 运行时取值需在 [0, 31] 内5.3 约束要点mutex_lock必须与同一 pipe、同一 mutex_id的mutex_unlock成对使用先 lock 后 unlock。同一 pipe 上前一次 lock 未被对应 unlock 释放时不得再次获取同一 mutex_id否则第二次获取会持续等待导致死锁手动与自动生成的 mutex 操作也不得在同一 pipe 上重复获取尚未释放的同一 ID。同一 mutex_id 的 lock/unlock不得嵌套使用无论各组操作的 pipe 是否相同使用自动 mutex 时也须避免与显式 mutex 操作形成同一 ID 的嵌套。同一 pipe 上连续使用相同 mutex_id 的多组 lock/unlock不能保证该 pipe 中各组操作依次完成。需要保证同一流水内前序操作完成后再执行后序操作时应优先使用对应单流水屏障接口当前流水没有对应单流水屏障接口时可使用bar_all。lock/unlock 必须位于对称的控制流路径中确保每次获取的互斥资源均被释放。auto_mutexTrue仅对带 mutex 元数据的 Tile 自动生成互斥操作显式调用的mutex_lock仍会保留自动同步与手动同步可在同一 Kernel 中混用。常规单缓冲、双缓冲与 N 缓冲场景推荐使用 make_tile_group 配合auto_mutexTrue只有需要精确控制加锁 pipe 与插入位置时才使用手动 mutex。5.4 调用示例以下 Kernel 在auto_mutexFalse下计算out x x输入 UB 用 mutex ID 0 约束 MTE2 与 V 的访问顺序输出 UB 用 mutex ID 1 约束 V 与 MTE3 的访问顺序。每次 lock 之后均在同一 pipe 上调用对应 unlockimport pypto_pro.language as pl pl.jit(auto_mutexFalse) def mutex_kernel( x: pl.Tensor[[64, 64], pl.DT_FP32], out: pl.Tensor[[64, 64], pl.DT_FP32], ): tt pl.TileType(shape[64, 64], dtypepl.DT_FP32, target_memorypl.MemorySpace.Vec) tile_x pl.make_tile(tt, addr0x0000) tile_out pl.make_tile(tt, addr0x4000) with pl.section_vector(): pl.system.mutex_lock(pipepl.PipeType.MTE2, mutex_id0) pl.load(tile_x, x, [0, 0]) pl.system.mutex_unlock(pipepl.PipeType.MTE2, mutex_id0) pl.system.mutex_lock(pipepl.PipeType.V, mutex_id0) pl.system.mutex_lock(pipepl.PipeType.V, mutex_id1) pl.add(tile_out, tile_x, tile_x) pl.system.mutex_unlock(pipepl.PipeType.V, mutex_id1) pl.system.mutex_unlock(pipepl.PipeType.V, mutex_id0) pl.system.mutex_lock(pipepl.PipeType.MTE3, mutex_id1) pl.store(out, tile_out, [0, 0]) pl.system.mutex_unlock(pipepl.PipeType.MTE3, mutex_id1)六、跨核信号同步set_cross_core 与 wait_cross_core6.1 功能与原理set_cross_core与wait_cross_core是一对核间同步接口基于计数信号量实现每个event_id对应一个初始值为 0 的计数器。set_cross_core在指定 pipe 的前序指令完成后使对应计数器加 1配对的wait_cross_core执行时若计数器为 0 则阻塞指定流水中的后续指令若大于 0 则减 1并继续。接口支持三类同步场景同类 AIC 或 AIV 的全核同步、同一 AI Core 内 AIV 之间的同步、同一 AI Core 内 AIC 与 AIV 之间的同步。参与同步的核与信号配对方式由sync_mode决定。pypto_pro.language.system.set_cross_core( *, pipe: PipeType, event_id: Union[int, Scalar], sync_mode: CrossCoreSyncMode pypto_pro.language.CrossCoreSyncMode.INTRA_BLOCK, ) - None pypto_pro.language.system.wait_cross_core( *, pipe: PipeType, event_id: Union[int, Scalar], sync_mode: CrossCoreSyncMode pypto_pro.language.CrossCoreSyncMode.INTRA_BLOCK, ) - NoneIR 层实现会对pipe做具体流水校验_validate_concrete_pipe并按event_id是否为运行时Expr分发到静态或动态_dyn指令参见 system_ops.py。6.2 参数说明pipe发送侧 set_cross_core表示发送信号所在的硬件流水该流水前序指令完成后 SET 才生效。INTER_BLOCK/INTER_SUBBLOCK/INTRA_BLOCK时取 M、V、MTE1、MTE2、MTE3、FIX不支持 S 和 ALLUNICAST_BLOCK时还可取 S但仍不支持 ALL。可与配对wait_cross_core的 pipe 不同。pipe等待侧 wait_cross_core表示等待期间被阻塞的流水。只阻塞该流水中尚未下发的后续指令已下发的指令仍可继续执行。四种模式均支持 M、V、MTE1、MTE2、MTE3、FIX 和 S不支持 ALL无需与配对的 set 侧 pipe 相同。event_id核间同步事件 ID支持 Python 整型常量或运行时整数 Scalar 表达式Python 整型常量当前只能取015动态表达式须由调用方保证运行时取值合法INTER_BLOCK/INTER_SUBBLOCK/INTRA_BLOCK取 015UNICAST_BLOCK在 AIV 侧取 015、在 AIC 侧取 031。UNICAST_BLOCK配对规则AIV0 发送的 015 与 AIC 等待的 015 配对AIV1 发送的 015 与 AIC 等待的 1631 配对AIC 发送的 015 与 AIV0 等待的 015 配对AIC 发送的 1631 与 AIV1 等待的 015 配对。每个事件 ID 的计数器取值范围为015同一事件的信号未被 WAIT 消费时连续发送超过 15 次 SET 会触发异常并中断执行。复用事件 ID 或将其用于不同同步模式前必须完成前一同步过程中的所有 SET 和 WAIT与sync_all同时使用时须避开 HARD 模式占用的事件 ID使用自动流水编排时还应避免与其分配的事件 ID 冲突。同一核连续发送多个 SET 时不保证不同事件 ID 之间的生效顺序存在先后依赖时应先完成前一组 SET/WAIT。sync_mode核间同步模式须与配对的 wait/set 使用相同模式取值见 CrossCoreSyncMode.md模式值说明INTER_BLOCK0多个 AI Core 之间的同类核全核同步。AIC 场景同步本次 Kernel 启动的所有 AICAIV 场景同步本次 Kernel 启动的所有 AIVAIC 与 AIV 不会在该模式下互相同步INTER_SUBBLOCK1同一 AI Core 内的 AIV0 与 AIV1 同步不同 AI Core 之间互不影响INTRA_BLOCK2同一 AI Core 内的 AIC 与全部 AIV 同步。AIV→AIC 方向须由 AIV0 和 AIV1 分别发送信号、AIC 等待两路信号AIC→AIV 方向由 AIC 发送信号、AIV0 和 AIV1 分别等待。默认同步模式UNICAST_BLOCK3同一 AI Core 内的 AIC 与单个 AIV 同步。AIC 侧事件 ID 015 对应 AIV01631 对应 AIV1AIV 侧事件 ID 取 0156.3 约束要点必须存在与当前调用匹配的配对接口且所有参与同步的核均能到达同步点否则可能死锁。使用INTER_BLOCK时若多流/多算子并发执行且并发算子申请的核数总和超过物理核数当至少两个并发算子使用核间同步时部分核可能因未被调度而无法到达同步点造成死锁须保证每个同步算子所需的核能够同时执行。6.4 调用示例各模式的典型调用片段详见 set_cross_core.mdwith pl.section_vector(): # INTER_BLOCK本AIV上的前置操作完成后全核同类AIV同步 pl.system.set_cross_core( pipepl.PipeType.MTE3, event_id0, sync_modepl.CrossCoreSyncMode.INTER_BLOCK, ) with pl.section_vector(): # INTER_SUBBLOCKAIV0和AIV1各自完成前置操作后互相同步 pl.system.set_cross_core( pipepl.PipeType.V, event_id1, sync_modepl.CrossCoreSyncMode.INTER_SUBBLOCK, ) with pl.section_cube(): # INTRA_BLOCKAIC等待AIV0和AIV1的两路信号 pl.system.wait_cross_core( pipepl.PipeType.MTE1, event_id2, sync_modepl.CrossCoreSyncMode.INTRA_BLOCK, ) with pl.section_cube(): # UNICAST_BLOCK仅等待AIV0的信号 pl.system.wait_cross_core( pipepl.PipeType.S, event_id15, sync_modepl.CrossCoreSyncMode.UNICAST_BLOCK, )完整的跨核 Kernel 示例实现Vector 侧AIV0/AIV1 各算一半把xy结果以 NZ 布局写入v1_mat经INTRA_BLOCK通知 Cube 侧 AICCube 侧等待信号后与rhs做 matmul 并写回 out的流水线协作其完整代码见 set_cross_core.md 与 wait_cross_core.md。核心结构为Vector 段内先做MTE2→V、V→MTE3核内同步搬出完成后set_cross_core(INTRA_BLOCK)Cube 段内wait_cross_core阻塞 MTE1待 AIV 信号到达后再执行move(v1_left, v1_mat)与matmul。七、全局核屏障sync_all7.1 功能与原理sync_all在多个 AIV 核、多个 AIC 核或 AIV 与 AIC 核之间建立核间屏障参与同步的核到达sync_all后等待直到本轮所有参与核均到达再继续执行。当前仅支持HARD 模式使用 FFTS 硬件同步不需要 workspace源码中sync_all在 system_ops.py 实现HARD 模式传入空 workspace 元组生成system.sync_all指令SOFT 模式GM 共享状态同步已在枚举中预留但当前暂不支持。pypto_pro.language.system.sync_all( workspaces: Optional[List] None, *, core_type: SyncCoreType pypto_pro.language.SyncCoreType.MIX, mode: SyncAllMode pypto_pro.language.SyncAllMode.HARD, ) - None7.2 参数说明参数输入/输出说明workspaces输入可选。当前仅支持 HARD 模式不使用 workspace保持默认None或传空列表core_type输入SyncCoreType 枚举值指定参与屏障的核类型默认MIX。该参数不指定参与核数量mode输入SyncAllMode 枚举值指定同步实现模式默认HARD当前仅支持HARDSyncCoreType取值AIV_ONLY仅同步参与执行的 AIV 核、AIC_ONLY仅同步参与执行的 AIC 核、MIX同步参与执行的 AIC 核和 AIV 核。7.3 约束要点所有参与同步的核必须以相同顺序执行相同次数的sync_all。循环次数或分支条件不一致导致部分核少执行或多执行 sync_all 时可能死锁。MIX 模式下 AIC 侧与 AIV 侧的调用必须一一对应。纯 Vector Kernel 使用AIV_ONLY纯 Cube Kernel 使用AIC_ONLY。MIX 模式要求 Cube 侧 AIC 与 Vector 侧 AIV 都执行对应的 sync_all只在一侧调用会使另一侧无法到达屏障导致Kernel 超时。多流/多算子并发执行且核数总和超过物理核数时若至少两个并发算子使用 sync_all部分核可能因未被调度而无法到达屏障造成死锁须保证每个同步算子所需的核能够同时执行。sync_all 只建立屏障屏障前后需要跨核读写 GM 数据时还需满足相应的数据可见性要求。与set_cross_core/wait_cross_core并用时两侧的 MIX 屏障必须位于该 SET/WAIT 对的同一侧禁止 Cube 侧先执行 sync_all 再 SET、Vector 侧先 WAIT 再执行 sync_all否则会形成环形等待。HARD 模式会占用核间同步事件 IDAIV_ONLY在 AIV 侧占用 14AIC_ONLY在 AIC 侧占用 11MIX在 AIC 侧占用 1113、在 AIV 侧占用 1213MIX 1:2 场景的 AIC 还会占用 28 和 29。与set_cross_core/wait_cross_core同时使用时不得将这些事件 ID 用于尚未完成的手工核间同步。7.4 调用示例纯 Vector Kernel 使用 HARDAIV_ONLY屏障的完整示例各 AIV 按核号处理互不重叠的行TileGroup与auto_mutex负责核内 pipe 依赖sync_all 位于循环外使所有参与 AIV 在本阶段结束后再越过屏障import pypto_pro.language as pl pl.jit(auto_mutexTrue) def sync_all_kernel( x: pl.Tensor[[2048, 64], pl.DT_FP32], out: pl.Tensor[[2048, 64], pl.DT_FP32], ): tt pl.TileType(shape[1, 64], dtypepl.DT_FP32, target_memorypl.MemorySpace.Vec) input_tiles pl.make_tile_group( typett, addrs[0x0000, 0x0100], mutex_ids[0, 1]) output_tiles pl.make_tile_group( typett, addrs[0x0200, 0x0300], mutex_ids[2, 3]) with pl.section_vector(): for row in pl.range(pl.get_block_idx(), x.shape[0], pl.get_block_num()): tile_x input_tiles.next() tile_out output_tiles.next() pl.load(tile_x, x, [row, 0]) pl.add(tile_out, tile_x, tile_x) pl.store(out, tile_out, [row, 0]) pl.system.sync_all( modepl.SyncAllMode.HARD, core_typepl.SyncCoreType.AIV_ONLY, )HARD 模式下三种core_type的放置方式分别对应纯 Vector、纯 Cube、CubeVector 共存 Kernel详见 sync_all.md# 纯Vector Kernel所有参与AIV都执行 with pl.section_vector(): # ... Vector阶段计算 pl.system.sync_all(modepl.SyncAllMode.HARD, core_typepl.SyncCoreType.AIV_ONLY) # 纯Cube Kernel所有参与AIC都执行 with pl.section_cube(): # ... Cube阶段计算 pl.system.sync_all(modepl.SyncAllMode.HARD, core_typepl.SyncCoreType.AIC_ONLY) # Cube、Vector共存的KernelAIC和AIV必须到达同一个MIX屏障 with pl.section_cube(): # ... Cube阶段计算 pl.system.sync_all(modepl.SyncAllMode.HARD, core_typepl.SyncCoreType.MIX) with pl.section_vector(): # ... Vector阶段计算 pl.system.sync_all(modepl.SyncAllMode.HARD, core_typepl.SyncCoreType.MIX)八、同步原语选型从核内到跨核综合全部分组可按下述原则快速选型同一流水的串行化连续 MTE2/MTE3 操作访问重叠地址或需要同流水前序操作完成后才执行后序操作时优先使用对应单流水屏障bar_mte2/bar_mte3流水无对应屏障时用bar_all。同一 AI Core 内不同流水之间的点对点依赖如 load→计算→store使用sync_src/sync_dst配对按 PipeType.md 的典型模式选择 set_pipe/wait_pipeevent_id取 [0, 7]。同一片上缓冲区的跨 pipe 互斥访问常规多缓冲场景用make_tile_groupauto_mutexTrue需要精确控制加锁 pipe 与插入位置时手动mutex_lock/mutex_unlockmutex_id取 [0, 31]。核内全部流水统一停靠需要等待当前 AI Core 全部流水完成时使用bar_all注意其性能开销且非跨核屏障。跨核协同需要同类核全核同步、同核 AIV 间同步或 AIC/AIV 间同步时使用set_cross_core/wait_cross_core并按CrossCoreSyncMode选择配对模式需要全局多核屏障时使用sync_allHARD 模式并严格避开其占用的事件 IDAIV 14、AIC 11、MIX 1113/1213 等。所有接口的完整函数原型、参数表与可运行示例均可在 synchronization 目录 下按名查阅IR 层实现集中在 system_ops.pyST 验证用例见 test_pipe_barriers.py 与 test_manual_mutex.py。在 Ascend 950PR/Ascend 950DT 上编写 Kernel 时遵循配对成双、路径对称、ID 不冲突、核全到达四条铁律即可写出无数据竞争、无死锁的高效同步代码。赞分享人工智能编译器模型编译高性能计算深度学习CANN【免费下载链接】pyptoPyPTO发音: pai p-t-oParallel Tensor/Tile Operation编程范式。项目地址https://gitcode.com/cann/pypto点击查看免费下载相关推荐PyPTO 同步控制详解bar_fix 实现 FIX 流水屏障同步PyPTO 同步控制详解bar_fix 实现 FIX 流水屏障同步 bar_fix 是 CANN PyPTO 并行编程范式中用于 FIXFixpipe流水人工智能编译器模型编译高性能计算深度学习CANNCANN PyPTO bar_m 屏障同步详解在 Cube 区段中同步 M 流水线CANN PyPTO bar_m 屏障同步详解在 Cube 区段中同步 M 流水线 导读 bar_m 是 CANN PyPTOParallel Tensor人工智能编译器模型编译高性能计算深度学习CANNLinux内核同步原语深入理解互斥锁(Mutex)Linux内核同步原语深入理解互斥锁 Mutex 前言 在多任务操作系统中同步原语是确保多个执行线程或进程能够正确共享资源的关键机制。Linux内核提供了多文档教程操作系统创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考