← AMD 专题与八个进阶单元

AMD / LAB 04 OF 08

数据移动与所有权:一次传输能省掉什么

为同一批数据做两次求和,区别容量、有效长度和最后一次使用。

本单元 4 小时。本公司八个单元共 32h,三家公司共额外 96h 核心实践;这笔时间在共同路线之外,未压入厂商入门的44h。

本页是实践讲义。打开、阅读或复制命令不代表完成。新单元的 SDK、simulator 与硬件命令均未在教材建设中执行;自己的结果应按实际后端保存。

先备与马上可用的例子

先完成:amd-03 →

直接打开机制图,边看边手推

PREDICT FIRST

具体问题与独立预期

输入与约定

X=[3,-1,4,0,2]。先求 sum(X),再对同一份只读 X 求 sum(2*X),不在 host 预先覆盖 X。

先根据输入写下自己的结果与理由,再展开参考推演;随后运行或检查实现。

对照参考结果与原因

结果为 8 和 16。32-bit 输入仅计有效 payload 为 20 bytes;两个 32-bit 标量回读共 8 bytes。

这是逻辑 payload 账本,不是 PCIe 实测流量。复用 device 输入可以避免第二次相同 H2D,但分配、打包和协议开销未被这些数字覆盖。

机制怎样连接起来

把 buffer 的容量和有效元素数分开:给 8 个 int 留容量,并不允许 kernel 读取 8 个输入;有效长度仍为 5。单元三的尾部检查在容量足够时也不能省略。

两个 kernel 只读 X,可以复用同一输入分配。输出各有自己的位置,直到对应回读完成后才重用或释放。先画生命周期,再引入异步传输;否则“优化复制”很容易变成 host 或 device 提前覆盖。

本次只比较两份设计的逻辑传输账本,不承诺真实带宽提升。把 memcpy、内部分配和格式转换逐项列出,后面的 profiler 单元再检验它们是否真的发生及花费多少。

CHOOSE ONE EXECUTION PATH

按手头环境推进

CPU 路径可以先完成。额外的 SDK 或设备验证要有自己的运行记录;本单元的四小时不同时要求完成四个分支。安装等待超过本页预算时,留下阻塞条件,继续可做的数学、代码与协议工作。

CPU · 现有机器 · 本单元尚未验收

条件:现有 macOS 或 Linux;C++20 编译器或 Python 3 标准库。无需加速卡。

本分支做什么:用分离容器和 copy 计数器做所有权模型。

保存什么证据:保存自己的源码、输入、实际 stdout/stderr 和退出码;只证明 CPU 逻辑。

教材初始执行状态:not-executed。这不是对你个人学习进度的判断。

SDK · 编译与环境 · 本单元尚未验收

条件:已有兼容 ROCm/HIP 的 Linux 工具链。

本分支做什么:核对分配释放 API,编译同步版;异步仍是下一单元。

保存什么证据:保存实际工具版本与编译命令;仅编译成功不能记成运行通过。

教材初始执行状态:not-executed。这不是对你个人学习进度的判断。

官方 simulator · 本单元尚未验收

条件:只有明确提供并且版本匹配的官方 simulator 才属于此分支。

本分支做什么:没有把容器复制叫作 DMA 仿真。

保存什么证据:记录 simulator 名称、版本、输入、日志、退出状态;网页或 CPU 模型不算 simulator。

教材初始执行状态:not-executed。这不是对你个人学习进度的判断。

真实设备 · 本单元尚未验收

条件:用户已有并可使用的兼容设备或实验室环境;本单元不要求购买、租用或提交集群作业。

本分支做什么:验证同步版回读,并在有条件时比较 pinned 和 pageable 两种配置;不预填性能值。

保存什么证据:真实设备输出、同步点、设备型号和复现日志单独保存;未执行保持未通过。

教材初始执行状态:not-executed。这不是对你个人学习进度的判断。

READ → BUILD → BREAK → EXPLAIN

四小时,留下一个完整产出

可拆成多个时段。每次停下时保存代码、输入、实际结果和下一步,不用重新读整篇。没有通过当前检查时继续修正,不靠翻页推进。

1. 画 buffer 表 · 30 分钟

  1. 列 host_X、device_X、device_Y0、device_Y1 的容量、有效长度、谁写谁读。
  2. 标记最后一次使用;两次计算后才可释放 device_X。

这一段的产出:所有权与有效范围表

2. 计算传输账本 · 40 分钟

  1. 方案 A 每次都上传 X:有效 H2D 共 40 bytes;方案 B 上传一次:20 bytes。
  2. 两种方案两个标量回读均为 8 bytes;把调用次数也单列。

这一段的产出:两方案 payload 对照

3. 实现复用 · 90 分钟

  1. 在自己的 reduction 外层保留 input 分配,增加 scale 参数 1 和 2;kernel 累加 scale*x[i],限制输入避免 int 溢出。
  2. CPU 路径用两份普通容器模拟 host/device,以计数器统计显式 copy;注释说明并非真实设备内存。
  3. HIP 路径先用同步 memcpy 验证 8/16,再选做 pinned host allocation,保留对应释放 API。

这一段的产出:复用实现和调用计数

4. 定位过早覆盖 · 50 分钟

  1. CPU 模型故意在第二次读取之前将输入改为 0,确认得到的错误值可由生命周期解释。
  2. 测试容量 8、N=5 的缓冲,额外三格填 100,结果仍为 8/16。
  3. 不要在实机释放仍在使用的分配;用依赖表审查这种错误。

这一段的产出:覆盖故障记录与容量测试

5. 说明可测与不可测 · 30 分钟

  1. 口述有效 payload 和硬件传输流量的区别。
  2. 保存下个单元可复用的 allocation/copy/compute/free 时间线。

这一段的产出:数据移动说明

EXPLICIT ENVIRONMENT / EXPLICIT STATUS

命令与可保存的起点

以下代码按各自环境使用,运行前完成对应步骤并核对版本。编译失败后停止,不运行目录中的旧二进制;每次采集日志使用新的运行目录。设备程序仅运行在你已有且可使用的环境中。

这个单元复用前一单元的项目文件,并按上面的具体任务修改。对应章节例子的源码、编译命令和预期输出在本页先备链接里;不要把例子自己的固定成功判定遗留到已改输入的版本中。

一个必须能解释的错误

错误情境:按照 device 分配容量 8 而不是有效 N=5 读取。

为什么会错:容量说明地址空间够大,不代表额外三个元素属于输入;填充值污染答案。

怎样修复:循环按有效 N 判断,并把容量和长度作为两个字段传递与验证。

EVIDENCE BEFORE ADVANCING

验收与面试追问

  • 两个结果 8/16 都检查;容量 8 的填充不影响答案。
  • 40 与 20 bytes 只标记逻辑 H2D payload,没有改名为带宽测量。
  • 每份资源有对应释放 API 与最后使用点。

最后留下这几项

输入和预期、自己的源码或明确标为推演的状态表、实际命令/输出/退出码、一个失败与修复、后端与版本、尚未执行的部分。运行已有教学例子与独立完成修改分别记录。

1. 只读输入何时可复用?

对照中文要点与英文回答

当它仍存活、格式和有效长度满足两个消费者,并且没有并行写入时;释放必须等最后一个消费者完成。

A read-only input can serve multiple consumers while its allocation remains alive. Reuse must preserve the format, bounds and completion dependencies.

2. 为什么不能把 20 bytes 除以 host launch 时间当带宽?

对照中文要点与英文回答

测量范围没有覆盖数据传输完成,分子也只是有效 payload。

Launch latency is not transfer completion time, and payload bytes are not a hardware traffic measurement.

3. pinned 是否一定更快?

对照中文要点与英文回答

它支持特定异步路径,但分配成本、输入大小和重用方式都会影响总时间,需要实际测量。

Pinned memory can enable an asynchronous path, but allocation cost and reuse determine the end-to-end benefit.

这些是依照本单元机制设计的追问,不是公司真题。个人验收仍依据实际代码、测试、测量与口述。

资料与版本核验

  • HIP device memory ↗

    Device allocation and memory copies

    核验日期:2026-09-05。HIP latest / 7.15.0 页面;记录实际 runtime、driver 和设备名称。

  • HIP host memory ↗

    Pinned host memory and host allocation

    核验日期:2026-09-05。HIP latest / 7.15.0 页面;按实际安装版本核对 hipHostMalloc/hipHostFree。

  • HIP asynchronous execution ↗

    Streams, events and overlap requirements

    核验日期:2026-09-05。HIP latest / 7.15.0 页面;记录设备 asyncEngineCount 与实际 tracing 工具版本。

正文、问题和实践设计依据公开资料独立撰写。官方页面的示例输出是资料中的结果,不是本机运行证据。latest 链接可能变化,请在自己的复现说明中保留实际版本。