图森技术汇 | 面向自动驾驶的多GPU通信框架
图森未来在刚刚结束的的2021 IEEE International Conference on Cluster Computing上获得了唯一的一篇最佳论文奖。
自1999年创办以来，IEEE Cluster Computing已经成为分布式与并行计算领域非常重要的国际会议，大会在分布式系统、高性能计算、体系结构方面对学术界和产业界均有广泛的影响力。
本篇技术分享的作者吴昊为此次图森未来最佳论文奖的主人公之一，论文中提出的GPU消息通信框架，相比传统GPU通信方案，可以大幅度减少分布式异构计算环境中的数据传输时延，减少自动驾驶系统硬件资源的使用率，展现自动驾驶强大的系统工程能力。
简介
自动驾驶系统包含各种不同的软硬件模块，例如传感器模块、感知模块等，其中传感器会产生大量数据，例如图像、点云等，这些数据会频繁发送给下游模块处理。为了满足自动驾驶系统对低延时的需求，常见的自动驾驶系统会搭载加速处理器（如GPU）加速处理这些数据。虽然处理这些数据可被GPU加速，但模块间传输GPU数据还没有得到很好支持，导致这些数据在不同GPU间以及进程间频繁移动，既增加了自动驾驶系统端到端时延和反应速度，又加剧了车上本就有限的硬件资源竞争。
为了解决该问题，我们提出了一个高效的GPU消息通信框架。相比传统GPU通信方案，实验表明该方案可减少图像与点云传输时延53.7%，并且最高能减少自动驾驶系统硬件资源的使用率58.9%。
一 引言
随着近年来软硬件的发展，例如深度学习、GPU，自动驾驶技术逐渐走入现实。GPU的使用可大幅提高深度学习处理数据的效率，使得自动驾驶系统有能力实时感知周围环境。然而，自动驾驶软件模块间的合作要求数据在模块间流动。
图1显示模块可分为CPU模块和GPU模块，不同类型的数据在模块之间流动。传统通信框架主要集中在提升CPU模块间数据流传输效率，而随着利用GPU的模块越来越多，GPU模块间的数据流成为了实时系统上新的性能瓶颈。
为了简化模块间通信开发，自动驾驶系统通常会采用发布者订阅者模型（Publisher-Subscriber）协助模块间通信。由于该模型允许每个模块不感知数据的上下游关系，即不关心数据的发送者和接收者是哪个模块，模块间通信与模块内计算任务得到了解耦，使得模块可并行开发，提高了开发效率。
在Publisher-Subscriber模型实现层面，由于操作系统上的进程保证了资源隔离与错误隔离，自动驾驶模块通常由进程实现。因此，模块间的数据传输包含了进程间通信（IPC），如何优化进程间通信是减少模块通信时延的关键。对于利用了深度学习的模块，通常会利用GPU进行任务加速。随着深度学习模块任务的增加，自动驾驶系统为了满足计算性能需求会搭载多块GPU设备，这样导致了M个深度学习模块运行在 N个GPU设备的映射关系。
现实中M通常会大于N，即多个模块可能在不同GPU上运行，也可能在相同GPU上。也就意味着模块间通信可发生在一块GPU上，也可发生在多个GPU之间。因此，高效的传输GPU消息方案应充分利用模块与GPU设备间的映射关系。
图1显示模块可分为CPU模块和GPU模块，不同类型的数据在模块之间流动。传统通信框架主要集中在提升CPU模块间数据流传输效率，而随着利用GPU的模块越来越多，GPU模块间的数据流成为了实时系统上新的性能瓶颈。
为了简化模块间通信开发，自动驾驶系统通常会采用发布者订阅者模型（Publisher-Subscriber）协助模块间通信。由于该模型允许每个模块不感知数据的上下游关系，即不关心数据的发送者和接收者是哪个模块，模块间通信与模块内计算任务得到了解耦，使得模块可并行开发，提高了开发效率。
在Publisher-Subscriber模型实现层面，由于操作系统上的进程保证了资源隔离与错误隔离，自动驾驶模块通常由进程实现。因此，模块间的数据传输包含了进程间通信（IPC），如何优化进程间通信是减少模块通信时延的关键。对于利用了深度学习的模块，通常会利用GPU进行任务加速。随着深度学习模块任务的增加，自动驾驶系统为了满足计算性能需求会搭载多块GPU设备，这样导致了M个深度学习模块运行在 N个GPU设备的映射关系。
现实中M通常会大于N，即多个模块可能在不同GPU上运行，也可能在相同GPU上。也就意味着模块间通信可发生在一块GPU上，也可发生在多个GPU之间。因此，高效的传输GPU消息方案应充分利用模块与GPU设备间的映射关系。
二 GPU消息通信问题
由于传统的Publisher-Subscriber传输框架只支持CPU消息传输，使得模块开发者不得不直接管理GPU消息传输。对于模块开发者，一个典型的GPU消息传输包含以下步骤。
图2所示：首先，Publisher将GPU中的数据传输到CPU上组成一个CPU消息，然后利用Pub-Sub接口将该CPU消息传输给Subscriber，最后Subscriber收到消息后将CPU消息传输到GPU上用于计算。该方式不但增加了模块开发者复杂度，也造成了多次数据移动。比如在将数据从GPU移动到CPU上时需要经过PCIe，再将CPU数据传给其他Subscriber过程包含了IPC与序列化操作，这些操作都增加了数据通信时延。而且，当需要将GPU消息传输给N个subscriber时，以上开销均乘以N，结果更加加剧了PCIe与CPU内存带宽的竞争。
直觉上，优化GPU消息通信或许可以由模块开发者实现，比如如果两个模块在同一个GPU上运行，那么可以利用CUDA提供的IPC接口去共享一块GPU buffer。然而，该方法假定模块开发者知道两种信息，其一是模块间的上下游关系，其二是上下游模块与GPU设备的映射关系。
由于Publisher-Subscriber模型的解耦性，此两种信息在运行时才会决定，而在开发阶段对于开发者是未知的，因此，我们断言优化GPU消息通信应当由通信框架层解决。
在通信框架层，我们将GPU通信问题分解为三个子问题：同一个GPU上的消息传输、跨GPU的消息传输、以及支持复杂GPU消息。针对以上三个子问题，分别提出了以Publisher为中心的可扩展内存池、自动选择跨GPU通道、转换传输一体化三个解决方案。
当通信模块在同一个GPU设备上时，共享GPU buffer是最高效的通信方式。该方式是将一块GPU物理内存映射到需要通信的所有进程内，然后通信进程直接读写该buffer并同步来通信。
为了避免频繁GPU内存映射，通常会将一大块GPU内存作为通信buffer，每个消息申请占用其中一部分。但GPU内存是稀缺资源，较大的通信buffer会使得留给任务的GPU内存过少。
因此，为了折中映射次数与GPU内存使用量，我们采用可动态扩展的GPU内存池，当原有buffer不够用时，由Publisher申请新的GPU buffer并通过文件描述符同步给所有Subscriber。该方式使得同GPU上的模块通过共享GPU内存传输消息，避免了数据移动带来的开销。对于跨GPU的模块消息传输，我们提出自动选择GPU通道方案，该方案利用Offline Auto-tuning方式获取各种预定义通道方案的传输时延，在运行时根据模块与GPU映射关系以及数据流拓扑关系选取最优的通道。因此，无论运行时模块如何在GPU间调整，跨GPU传输方式都可找到最优的传输通道。
除此以外，结合Publisher-Subscriber语义，我们对同一个GPU上的所有Subscriber只发送一份消息并通过共享，进一步减少了跨GPU数据传输量。
对于GPU复杂消息可能包含指针无法直接在多进程共享的问题，我们提出转换传输一体化方案 (on-the-fly convert)方案。该方案基于offset的指针替换策略，但如果在GPU访存时转换指针会引入额外开销，降低GPU任务执行效率。
为了解决该问题，我们通过基于深度优先搜索的指针替换算法，在传输过程中将offset转换为本地合法指针，因此避免了在访问GPU内存时指针转换的开销。
通过以上三个解决方案，模块间传输GPU消息无需模块开发者参与即可自动达到高效。
图2所示：首先，Publisher将GPU中的数据传输到CPU上组成一个CPU消息，然后利用Pub-Sub接口将该CPU消息传输给Subscriber，最后Subscriber收到消息后将CPU消息传输到GPU上用于计算。该方式不但增加了模块开发者复杂度，也造成了多次数据移动。比如在将数据从GPU移动到CPU上时需要经过PCIe，再将CPU数据传给其他Subscriber过程包含了IPC与序列化操作，这些操作都增加了数据通信时延。而且，当需要将GPU消息传输给N个subscriber时，以上开销均乘以N，结果更加加剧了PCIe与CPU内存带宽的竞争。
三 解决方案
直觉上，优化GPU消息通信或许可以由模块开发者实现，比如如果两个模块在同一个GPU上运行，那么可以利用CUDA提供的IPC接口去共享一块GPU buffer。然而，该方法假定模块开发者知道两种信息，其一是模块间的上下游关系，其二是上下游模块与GPU设备的映射关系。
由于Publisher-Subscriber模型的解耦性，此两种信息在运行时才会决定，而在开发阶段对于开发者是未知的，因此，我们断言优化GPU消息通信应当由通信框架层解决。
在通信框架层，我们将GPU通信问题分解为三个子问题：同一个GPU上的消息传输、跨GPU的消息传输、以及支持复杂GPU消息。针对以上三个子问题，分别提出了以Publisher为中心的可扩展内存池、自动选择跨GPU通道、转换传输一体化三个解决方案。
当通信模块在同一个GPU设备上时，共享GPU buffer是最高效的通信方式。该方式是将一块GPU物理内存映射到需要通信的所有进程内，然后通信进程直接读写该buffer并同步来通信。
为了避免频繁GPU内存映射，通常会将一大块GPU内存作为通信buffer，每个消息申请占用其中一部分。但GPU内存是稀缺资源，较大的通信buffer会使得留给任务的GPU内存过少。
因此，为了折中映射次数与GPU内存使用量，我们采用可动态扩展的GPU内存池，当原有buffer不够用时，由Publisher申请新的GPU buffer并通过文件描述符同步给所有Subscriber。该方式使得同GPU上的模块通过共享GPU内存传输消息，避免了数据移动带来的开销。对于跨GPU的模块消息传输，我们提出自动选择GPU通道方案，该方案利用Offline Auto-tuning方式获取各种预定义通道方案的传输时延，在运行时根据模块与GPU映射关系以及数据流拓扑关系选取最优的通道。因此，无论运行时模块如何在GPU间调整，跨GPU传输方式都可找到最优的传输通道。
除此以外，结合Publisher-Subscriber语义，我们对同一个GPU上的所有Subscriber只发送一份消息并通过共享，进一步减少了跨GPU数据传输量。
对于GPU复杂消息可能包含指针无法直接在多进程共享的问题，我们提出转换传输一体化方案 (on-the-fly convert)方案。该方案基于offset的指针替换策略，但如果在GPU访存时转换指针会引入额外开销，降低GPU任务执行效率。
为了解决该问题，我们通过基于深度优先搜索的指针替换算法，在传输过程中将offset转换为本地合法指针，因此避免了在访问GPU内存时指针转换的开销。
通过以上三个解决方案，模块间传输GPU消息无需模块开发者参与即可自动达到高效。
四 实验
我们在基于RTX2080 GPU计算平台上与其他GPU消息传输方案进行了对比，实验数据采用ROS2官方提供的Image与PointCloud消息格式。
相比传统GPU通信方案，实验表明该方案相比目前最高效方案可减少图像与点云传输时延53.7%，并减少自动驾驶系统硬件资源PCIe与CPU内存带宽使用率分别为58.9%与13.2%。
五 总结
GPU在自动驾驶系统中至关重要，因为硬件传感器产生的数据越来越多，基于深度学习技术的软件模块利用GPU加速数据处理，提高了自动驾驶技术响应性。然而，随着GPU模块的增加，GPU消息的传输量越来越大，由于现有通信框架并没有支持GPU消息传输，导致模块间传输GPU消息成为新的瓶颈。
本文提出了一个高效的GPU消息传输框架，基于同GPU共享内存策略与高效的跨GPU通信方案，通过最小化模块间数据移动达到提高通信效率目的。实验数据表明，相比目前最优GPU传输方法，本方案可减少图像、点云通信延时达53.7%，最高减少自动驾驶系统硬件资源使用率58.9%。
百威成长空间 50人发布