GIDS

GDS、GIDS 和 uGDS 的名字非常接近，也都在讨论 GPU 与存储之间的数据通路，因此很容易被理解成同一项技术的三个版本。 实际上，它们解决的是三个不同层面的问题： GDS 关注数据路径：怎样让存储数据不经 CPU 内存中转，直接进入 GPU 显存； GIDS 关注控制路径：怎样让 GPU Kernel 自己决定并发起存储请求，减少 GPU 与 CPU 往返； uGDS 关注软件栈：怎样让 CPU 在用户态直接管理 NVMe 队列，绕过内核 NVMe 驱动与文件系统。 可以先用一句话概括： GDS 是“数据直达 GPU”，GIDS 是“GPU 主动要数据”，uGDS 是“用户态 CPU 直接驱动 NVMe 把数据送到 GPU”。 本文从请求由谁发起、数据经过哪里、NVMe 命令由谁构造、是否保留文件系统语义等维度，分析三者的区别与联系。更深入的原理可以继续阅读本系列的三篇文章： NVIDIA GPUDirect Storage（GDS）详解：让存储数据绕过 CPU 直达 GPU NVIDIA GPU-Initiated Data Storage（GIDS）详解：让 GPU Kernel 主动访问存储 uGDS 原理解析：在用户态打通 NVMe SSD 与 GPU 显存 一、先区分数据路径与控制路径 理解这三项技术的关键，是不要把“数据经过哪里”和“谁发起 I/O”混为一谈。 数据路径 数据路径描述有效载荷如何移动。例如： 传统路径：SSD → CPU 内存 → GPU 显存 直接路径：SSD ──────────→ GPU 显存 GDS、GIDS 和 uGDS 都希望建立 SSD 与 GPU 显存之间的 DMA 路径，减少 CPU bounce buffer。但“数据不经过 CPU 内存”并不代表“CPU 没有参与”。 ...

GPUDirect Storage（GDS）已经能够让存储数据绕过 CPU 内存，直接进入 GPU 显存。但经典 GDS 仍有一个重要特征：I/O 请求由 CPU 侧应用代码提交。 当 GPU kernel 在执行过程中才知道下一份数据位于哪里时，控制权必须在 GPU 与 CPU 之间往返。对于图计算、向量检索、稀疏模型和超大规模数据分析，这种细粒度同步可能比数据传输本身更昂贵。 NVIDIA GPU-Initiated Data Storage，简称 GIDS，试图进一步消除这层控制瓶颈：让 GPU kernel 直接发起存储 I/O，使 GPU 不仅是数据的接收者，也是 I/O 请求的生产者。 本文介绍 GIDS 的动机、架构、工作流程、适用场景，以及它和 GDS 的本质区别。 一、为什么有了 GDS 还需要 GIDS GDS 优化了数据路径： CPU 发起请求 │ ▼ 存储 ─────────────► GPU 显存 数据不经过 CPU 内存 这已经消除了大量主机内存中转，但控制路径仍然经过 CPU。经典流程可能是： GPU 执行 kernel； GPU 产生下一批要访问的数据索引； kernel 结束或与 CPU 同步； CPU 读取结果并构造文件 I/O； CPU 调用 cuFile； 数据进入 GPU； CPU 再次启动 kernel。 如果每次请求都是大块、批量且可提前预测，这种方式通常没有问题。但如果 GPU 在计算过程中产生数以万计甚至更多的动态访问，频繁的 GPU—CPU 往返会带来： ...