尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

Triton 后端重构路线图解析:从第三方 GPU 后端入树到 Triton GPU IR 统一架构

Triton 后端重构路线图解析:从第三方 GPU 后端入树到 Triton GPU IR 统一架构 Triton 后端重构路线图解析从第三方 GPU 后端入树到 Triton GPU IR 统一架构【免费下载链接】tritonDevelopment repository for the Triton language and compiler项目地址: https://gitcode.com/GitHub_Trending/tri/triton本文围绕 Triton 语言与编译器项目在 2023 年 12 月社区例会docs/meetups/12-13-2023/notes.md中讨论的三项技术议题展开第三方 GPU 后端重构计划、AMD 前端重构以及将 Triton Shared 组件block pointers、ptr_analysis、mask_analysis增量引入 GPU 开发的可行性。读者读完本文后将理解当前仓库中统一 Triton GPU IR 可插拔后端接口 张量描述符tensor descriptor访存这套架构的来龙去脉并能在源码层面逐一验证这些设计决策的实现。会议背景与议题概览该笔记记录了 2023-12-13 社区例会的议程与会议纪要共三项核心议题第三方 GPU 后端重构计划——目标是让所有 GPU 后端从完全树外out of tree转变为Triton GPU IR 上的独立 pass并完成入树in-treeAMD 前端重构——与相关贡献者协作推进并在下次例会说明 AMD 与 Triton GPU IR 及代码流的差异点Triton Shared 组件复用——探讨 block pointers、ptr_analysis、mask_analysis 等组件能否按需、增量地引入 GPU 开发流程。这三项议题实际上勾勒出了 Triton 编译器架构演进的主线统一中间表示、解耦后端、收敛访存抽象。下面结合当前仓库源码逐一展开。议题一第三方 GPU 后端重构——从树外走向 Triton GPU IR 上的独立 Pass原始计划会议纪要明确了重构的时间目标与形态重构计划在当年年底前完成使所有 GPU 后端都能以Triton GPU IR 上的独立 pass形式存在而不再完全放在树外目标效果用户安装 Triton 时除了 CUDA 之外还能获得其他 GPU 支持非 GPU 相关的 Triton IRTTIR预期保持不变。当前仓库的实现印证从当前仓库结构看这一计划已落地成型。third_party/目录下集中了 amd、nvidia、proton、f2reduce等子项目GPU 后端不再游离于主仓库之外而是作为独立子模块统一入树维护各自保留专属的 dialect、转换 pass 与后端驱动。后端的统一抽象接口定义在 python/triton/backends/compiler.pyGPUTarget数据类描述目标设备backend如cuda、hip、arch如90或gfx940、warp_sizeBaseBackend抽象基类规定了每个后端必须实现的方法supports_target声明该后端支持的目标parse_options将选项字典转换为后端专属选项对象可内含目标相关启发式与合法性检查add_stages向编译流水线注册各阶段stage按插入顺序串行执行阶段间通过metadata通信最后一个阶段返回可供 launcher 执行的字节码load_dialects向 MLIR context 加载额外 dialectget_module_map返回接口模块到设备专属实现的映射。流水线的阶段注册制设计正是GPU 后端作为 Triton GPU IR 上的 pass这一思想的 Python 侧体现每个后端只需声明自己参与哪些 IR 变换阶段而非重复实现整条链路。测试 python/test/backend/test_device_backend.py 中的ExtensionBackend进一步演示了第三方后端如何接入它继承BaseBackend在add_stages中过滤掉不关心的阶段仅保留ast、ttir、ttgir并通过register_backend(cpu, ExtensionBackend)完成注册——这正是安装 Triton 即可获得其他后端这一目标的最小可运行范例。议题二AMD 前端重构——与 Triton GPU IR 的分化与收敛原始计划会议纪要指出AMD 相关重构将与 Phil 协作推进并在下次例会中详细说明AMD 在 Triton GPU IR 与代码流上已经产生分化的位置。这实质上承认了 AMD 后端此前存在与主线上游代码流不一致的定制路径需要系统性收敛。当前仓库的实现印证AMD 后端的现状可以在 third_party/amd/backend/compiler.py 中看到完整面貌HIPBackend(BaseBackend)L149通过supports_target声明支持target.backend hipbinary_ext hsacoadd_stagesL608-L622注册了完整流水线Triton 路径ttir前端 IR→ttgirTriton GPU IR→llir→amdgcn→hsacoGluon 路径glir→ttgir→ 后续同样落到底层parse_options中体现了与具体架构强相关的启发式gfx942上放开tf32作为 dot 输入精度、gfx950上追加fp8e5b16/fp8e4b8等被废弃的 fp8 dot 操作数类型、num_ctas 1时校验目标架构是否支持多 CTA 启动supports_multi_cta_launch等。在 C 侧third_party/amd/lib 的目录布局清晰地呈现了 AMD 与主线代码流的分化与收敛方式TritonAMDGPUDialectToLLVM/、TritonAMDGPUToLLVM/、TritonAMDGPUTransforms/、Analysis/各司其职把 AMD 特有的转换逻辑封装在独立目录中叠加在主线 Triton GPU IR 之上而不是重写整条流水线——与独立 pass 入树的总体方向一致。从前端重构的角度看语言层接口的映射同样模块化HIPBackend.get_module_map将triton.language.extra.libdevice映射到 AMD 专属实现from triton.language.extra.hip import libdevice从而让同一套 Triton 语言前端在不同后端上解析到正确的设备库。议题三复用 Triton Shared 组件——block pointers 的演进与张量描述符时代原始计划会议第三个议题提出block pointers、ptr_analysis、mask_analysis 等组件既然可用于 GPU是否存在计划将 Triton Shared 中的组件增量引入 GPU 开发纪要给出的答复是按具体案例逐一评估case by case。当前仓库的实现印证这个逐案评估的决策在访存抽象上催生了显著演进。当前仓库中tl.make_block_ptr与tl.advance已在 python/triton/language/core.py 中被移除取而代之的是张量描述符tensor descriptorAPItriton.jit def inplace_abs(in_out_ptr, M, N, M_BLOCK: tl.constexpr, N_BLOCK: tl.constexpr): desc tl.make_tensor_descriptor( in_out_ptr, shape[M, N], strides[N, 1], block_shape[M_BLOCK, N_BLOCK], ) moffset tl.program_id(0) * M_BLOCK noffset tl.program_id(1) * N_BLOCK value desc.load([moffset, noffset]) desc.store([moffset, noffset], tl.abs(value))make_tensor_descriptor的接口约束L2519-L2566完整继承了 block pointer 时代的语义并针对硬件做了明确限定base张量基地址指针必须16 字节对齐shape非负整数列表表示张量各维尺寸strides各维步长前导维度必须是 16 字节步长的整数倍最后一维必须连续block_shape从全局内存加载/存储的块形状padding_option默认zero用于越界填充目前仅支持2 到 5 维张量在支持 TMA 的 NVIDIA GPU 上该描述符会编译为 TMA 描述符对象desc.load/desc.store由 TMA 硬件执行由于 TMA 描述符要求全局内存分配文档示例同时演示了通过triton.set_allocator(alloc_fn)提供分配器。这一演进正是对议题三的长期回答与其把 Triton Shared 的 block pointer 组件逐个移植不如基于硬件能力TMA抽象出更贴合 GPU 的描述符访存模型。需要说明的是ptr_analysis、mask_analysis这类独立命名的分析组件在当前仓库主树中已不存在对应 pass指针与掩码相关的分析能力被吸收进 include/triton/Analysis如Alias、AxisInfo、Allocation、BufferIndexAnalysis等以及 TritonGPU 转换框架中访存语义则统一收敛到描述符 API 之下。三项议题的收束一条清晰的架构演进主线把 2023 年 12 月例会的三项议题放在一起看可以梳理出 Triton 编译器架构演进的三条主线且每一条都能在当前仓库中找到落点统一 IR 可插拔后端GPU 后端以独立 pass/子项目形式入树third_partyPython 侧通过 BaseBackend 抽象与register_backend机制实现安装即得多后端前端与代码流收敛AMD 以 HIP 后端为样板把架构相关启发式gfx942/gfx950精度策略、多 CTA 校验收敛进parse_options与专属转换目录避免对主线代码流的分叉访存抽象硬件化block pointer 组件经逐案评估后演进为张量描述符 API在支持 TMA 的硬件上直接下沉为硬件描述符同时保留shape/strides/block_shape这一稳定的用户接口语义。如何在当前仓库中继续深入阅读原始会议纪要docs/meetups/12-13-2023/notes.md以及同一系列例会笔记如 docs/meetups/10-25-2023/notes.md该期附有 triton-shared 议题的幻灯片研读后端抽象接口python/triton/backends/compiler.py对比 AMD/NVIDIA 后端实现third_party/amd/backend/compiler.py 与 third_party/nvidia/backend/compiler.py验证后端可扩展性运行 python/test/backend/test_device_backend.py 中基于register_backend的示例后端体验张量描述符 APIpython/triton/language/core.py 中的完整示例以及 NVIDIA TMA 相关转换实现third_party/nvidia/lib/TritonNVIDIAGPUToLLVM/TMAToLLVM.cpp。需要注意的是会议纪要描述的是 2023 年底的时间点与规划本文中关于当前仓库的描述均以本仓库实际代码为准硬件支持如 TMA、gfx950存在架构前提读者在具体平台上验证时应以对应后端的supports_target与文档注释为准。【免费下载链接】tritonDevelopment repository for the Triton language and compiler项目地址: https://gitcode.com/GitHub_Trending/tri/triton创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表