PTO 虚拟 ISA 执行模型解析Host/Device/Core 三层代理、Tile 粒度调度与架构可见顺序域【免费下载链接】pto-isaParallel Tile Operation (PTO) is a virtual instruction set architecture designed by Ascend CANN, focusing on tile-level operations. This repository offers high-performance, cross-platform tile operations across Ascend platforms.项目地址: https://gitcode.com/cann/pto-isaPTOParallel Tile Operation虚拟指令集架构在执行模型层面回答了PTO 程序在哪里运行、以什么粒度运行、如何确定执行顺序这三个核心问题。本文基于 PTO 虚拟 ISA 手册第 2 章执行模型展开系统讲解抽象 PTO 机器的三层执行代理Host/Device/Core、Tile 粒度的程序模型、派发调度规则、三个架构可见顺序域以及 Auto/Manual 双模式的职责边界并结合仓库中的机器模型文档与指令参考如TLOAD/TSTORE、TASSIGN、SYNCALL给出源码级佐证。读完本文你将掌握 PTO 执行模型的完整骨架理解架构定义与实现定义的分界从而写出跨后端可移植、顺序语义正确的 PTO 程序。1. 执行模型的定位架构契约而非微架构描述PTO 虚拟 ISA 手册在 总览 中明确了设计目标在硬件代际演进中提供稳定架构契约以 Tile 为中心定义语义并明确区分架构定义与实现定义。执行模型 这一章手册第 2 章正是这一目标在程序如何执行维度的落地。该章范围定义非常清晰定义虚拟 ISA 程序面向的抽象执行模型包括架构可见的顺序ordering与职责responsibility边界不定义微架构内部实现例如缓存层级、发射端口、片上网络拓扑等。也就是说执行模型是架构层可见行为的抽象契约任何符合规范的实现真实 NPU 后端、CPU 仿真器、虚拟后端都必须满足这一契约但内部如何组织硬件资源属于实现自由。手册 index 给出的权威来源优先级也印证了这一点逐条指令语义以docs/isa/*_zh.md为准公共 API 形态以include/pto/common/pto_instr.hpp为准本手册含执行模型定义分层模型、架构契约与一致性策略。2. 抽象 PTO 机器的三层执行代理执行模型将抽象 PTO 机器抽象为三个概念代理execution agent每个代理承担一类职责代理核心职责Host machine准备负载workload、提交执行、管理全局资源Device machine在执行资源之间调度 Tile 程序Core machine执行 Tile/标量指令与同步原语一个符合规范的实现conforming implementation可以内部采用不同映射例如一个物理卡对应一个 Device、多个核对应多个 Core或仿真器中用线程模拟 Core但MUST 保持架构可见行为一致——这是三层代理模型最重要的约束。仓库中的 抽象机器模型文档 对这三层给出了更具体化的解释可以作为理解本节的佐证PTO Host Machine主机侧系统负责编译/JIT Tile 代码并缓存编译后的函数、构建和优化 Tile 图调度、分区、替换、分配和管理全局内存缓冲区、向一个或多个 Device 提交工作并协调完成。从 ISA 角度看主机行为超出范围但端到端系统中编译与调度决策的位置在这里。PTO Device Machine一组 Core Machines 加上一个调度器将工作分解为Tile 块确切单元由实现定义通常是小的 Tile 程序或 Tile 图的一个区域调度到可用的 Core 上并跟踪全局内存依赖关系使TLOAD/TSTORE观察到的读写以合法顺序发生。PTO Core Machine执行单个 Tile 指令流的最小执行代理。模型暴露了程序员可见的概念标量单元驱动控制流、内存地址计算、事件操作与显式同步、多个Tile 执行引擎/流水线向量流水线、矩阵/立方体流水线、内存流水线、固定功能单元、Tile 存储类似寄存器文件的片上存储存放Vec/Mat/Left/Right/Acc等 Tile 对象以及可选的共享内存。此外根据平台不同还可能有集体通信单元设备间通信和 DMA/预取引擎全局内存与片上缓存间的后台数据移动等附加概念组件——它们同样位于执行模型的扩展面上不改变三层代理的基本职责划分。3. 程序粒度Tile 程序与 Tile 图PTO 程序以Tile 粒度运行这是 PTO 与通用 GPU 指令集写法的根本区别之一总览 将Tile 为主计算单位列为一等架构特征。执行模型规定程序是对tile、scalar、memory、event值进行操作的有序指令序列执行单元MAY并发处理相互独立的 Tile 程序可见顺序MUST遵循数据依赖与显式同步语义。抽象机器模型文档 进一步区分了两个相关概念Tile 程序一系列针对 Tile、全局张量、标量和事件的 PTO 操作序列Tile 图一组具有显式数据依赖关系的 Tile 程序或块通常由全局内存读写和事件顺序引发。Tile 粒度与指令集参考中的记号完全对应。ISA 通用约定 定义了Tile片上二维操作数对象如pto::Tile...、GM通过pto::GlobalTensor...访问的片外内存视图、标量/立即数三类操作数。指令语义默认迭代域为valid_row dst.GetValidRow()、valid_col dst.GetValidCol()数学语义仅对有效区域内0 i valid_row且0 j valid_col的dst[i, j]定义——这就是程序以 Tile 粒度运行在单条指令层面的落点执行单元处理的是带有有效区域元数据的 Tile 值而非裸的连续内存。4. 派发与调度实现定义但受架构规则约束执行模型明确调度策略属于实现定义implementation-defined但必须服从两条架构规则独立工作MAY乱序并行执行有依赖的工作MUST满足要求的 happens-before 关系。后端/运行时MAY采用 SPMD单程序多数据、MPMD多程序多数据或混合派发模型。仓库文档对这一点有直接印证抽象机器模型文档 规定在单个核心的一个 Tile 块内对于具有显式数据或事件依赖关系的操作程序顺序得以保留跨 Tile 块和核心顺序只有在通过全局内存依赖关系TSTORE产生数据后被TLOAD消费或显式事件/同步表达时才得到保证设备实现可以乱序且并行地执行独立的 Tile 块。关于 MPMD抽象机器模型文档 说明虽然许多内核以 SPMD 风格编写所有核心运行相同的入口函数Device Machine 模型也允许 MPMD 风格——调度器选择一个 Tile 块并映射到一个核心实现可通过多个内核入口点或调度器提供的任务 ID传入单个入口函数用于分派程序体暴露这一能力。这意味着程序员不能假设指令按书写顺序全局执行只能依赖数据依赖、显式事件和同步语义来获得顺序保证。这也正是第 5 节架构可见顺序域存在的意义。5. 架构可见顺序域三条必须满足的顺序规则执行模型在三个域上定义顺序语义这是本章的核心内容任何 PTO 程序的正确性分析都应从这三个域入手5.1 程序顺序域Program order domain在单一依赖链中后续操作 MUST 观察到前序已提交committed的效果。注意这里的限定是单一依赖链——顺序只沿依赖传播并不要求全局顺序。5.2 事件/同步域Event/synchronization domain事件操作与 event synchronization MUST 建立架构定义的顺序点ordering points。这是 PTO 顺序表达的主要载体同步章节 规定event synchronization 用于在操作集合之间建立顺序关系一致性实现 MUST 保证顺序点之前的操作结果按照内存模型对顺序点之后的消费者可见并且优化与降层过程保持同步语义不支持的同步形式以确定性诊断拒绝。同步需求通常来自四类冒险同步章节 列出读后写RAW依赖、资源复用时的写后读WAR交互、写后写WAW顺序约束、跨流水线交接冒险内存/向量/矩阵域。事件模型 MUST 提供确定性依赖关系以支持生产者与消费者指令组之间的流水线交接、Tile 与内存资源的安全复用以及在等价程序顺序与依赖描述下可复现执行。ISA 参考中跨核同步的典型原语是 SYNCALL跨核同步屏障硬件 FFTS 或软件 GM 轮询。5.3 内存可见性域Memory visibility domainTLOAD/TSTORE的可见性遵循内存顺序与一致性章节定义的约束原文档称第 11 章内存顺序约束手册中该内容实际位于第 10 章。其一致性基线为依赖有序一致性dependency-ordered consistency数据依赖与显式同步定义必须满足的可见顺序相互独立操作在内部 MAY 重排必需同步点 MUST 建立定义的可见性关系。一致性实现 MUST 保证在必需同步/顺序点之后生产者写入对依赖消费者可见且 event synchronization 与事件依赖定义的顺序在内存可见性上得到体现。将三个域合起来看程序顺序域负责依赖链内的顺序事件/同步域负责跨指令组的显式顺序点内存可见性域负责TLOAD/TSTORE与同步之间的可见性衔接——三者共同构成了 PTO 执行模型完整的顺序语义。6. Auto 与 Manual两种架构级职责模型PTO 在架构层支持两种职责模型这是贯穿整个手册总览、编程模型契约的双编程模型在设计上的具体体现Auto 模式编译器/运行时SHOULD自动插入合法同步synchronization与放置placement策略用户意图保留为架构可见语义执行细节由工具链管理生成代码 MUST 保持虚拟 ISA 语义在等价源码与选项下用户可见行为 MUST 保持确定性。Manual 模式程序员负责显式放置、顺序控制与流水线安全调度工具链MUST保留显式编写的同步语义同步章节 进一步强调工具链 MUST NOT 删除必要的用户显式同步除非证明存在等价顺序保持非法手工配置 MUST 以可执行诊断失败。两种模式在实际项目中常常混合使用抽象机器模型文档 明确指出许多应用会混合使用两种风格从 PTO-Auto 开始然后手动优化关键内核。Manual 模式下程序员控制内存布局与绑定的典型指令是 TASSIGN将 Tile 对象绑定到实现定义的片上地址即手动放置而顺序/同步通过事件、event synchronization 表达Auto 模式则把这些职责交给编译器和运行时并在可用时应用 VF 融合等优化。7. 实现定义边界与后端画像执行模型明确划出了一块实现定义区域以下内容属于实现定义且MUST 在后端画像backend profile中说明调度启发策略scheduler heuristics流水线占用与发射细节pipeline occupancy and issue details内部缓冲与临时放置internal buffering and transient placement后端支持子集的合法性约束backend-specific legality subsets。同时给出硬性边界这些实现差异 MUST NOT 改变架构定义的指令语义。这一实现定义边界与后端画像与一致性章节形成闭环。后端画像 MUST 记录支持的指令族与操作形式、支持的 dtype/layout/location/shape 组合、同步与内存顺序限制、实现定义行为边界、对不支持特性的诊断策略画像可对应具体目标例如 A2/A3/A5/CPU 仿真器。工具链 MUST 基于画像能力门控后端特化当请求行为超出画像支持时编译/合法化 MUST 确定性失败或选择显式定义的回退路径。从源码结构看仓库对多后端 实现定义差异的组织方式与这一契约吻合include/pto/cpu/与include/pto/npu/分别承载 CPU 仿真与 NPU 侧的算子实现include/pto/costmodel/提供性能模型支持而include/pto/common/pto_instr.hpp作为公共 API 形态的权威来源保持跨后端统一——公共接口稳定、后端差异收敛到画像与实现目录内正是执行模型实现可以不同映射但 MUST 保持架构可见行为一致原则的工程化落地。8. 从执行模型到一致性验证与诊断执行模型定义的顺序语义最终要落到可验证的一致性上。手册后端画像与一致性章节给出的评估维度与执行模型的三域一一对应语义一致性指令行为合法性一致性契约验证顺序一致性同步与内存可见性——对应执行模型的程序顺序域、事件/同步域、内存可见性域诊断一致性确定性且可执行错误。建议的一致性等级从 Level 0解析/形态逐级上升到 Level 3跨层稳定性AS/字节码/后端转换后语义、顺序、诊断保持稳定后端 SHOULD 公布最高已验证等级及已知缺口。必需的测试矩阵包含按指令族划分的合法/非法组合测试、同步与内存顺序场景测试、精度/模式交互测试、文本/AS/字节码往返工具链测试和诊断稳定性快照测试。诊断方面执行模型要求实现定义行为在后端画像中说明状态与类型章节 与同步章节 也分别要求类型/状态验证诊断与同步诊断包含确定性错误标识、操作数位置、缺失或无效依赖上下文等信息面向 CI 稳定。仓库中的一致性验证工具如docs/tools/check_isa_consistency.py、docs/tools/check_virtual_manual_consistency.py正是用于保障指令参考、虚拟手册与后端实现三者口径一致的基础设施可作为理解执行模型一致性要求的实践参照。总结PTO 执行模型用一套简洁的抽象回答了大粒度计算内核的经典问题谁执行Host/Device/Core 三层代理职责分别是准备提交、调度分配、执行同步执行什么以 Tile 为粒度运行的操作序列并发边界由依赖关系而非书写顺序决定怎么排序程序顺序域依赖链、事件/同步域顺序点、内存可见性域TLOAD/TSTORE与内存模型三个域共同约束谁负责Auto 模式由工具链自动插入同步与放置Manual 模式由程序员显式管理两者均为架构层公民差异边界调度启发、流水线细节、缓冲放置等属于实现定义必须写入后端画像且不得改变架构语义。理解这一模型是阅读后续章节同步、内存顺序与一致性、后端画像与一致性的基础也是编写可移植 PTO 内核、实现后端与一致性测试的出发点。【免费下载链接】pto-isaParallel Tile Operation (PTO) is a virtual instruction set architecture designed by Ascend CANN, focusing on tile-level operations. This repository offers high-performance, cross-platform tile operations across Ascend platforms.项目地址: https://gitcode.com/cann/pto-isa创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考