就像人類(lèi)用眼睛看東西一樣，自動(dòng)駕駛汽車(chē)使用傳感器收集信息。這些傳感器收集了大量數(shù)據(jù)，因此需要高效率的車(chē)載數(shù)據(jù)處理，以便車(chē)輛對(duì)道路情況做出快速反應(yīng)。這種能力對(duì)自動(dòng)駕駛汽車(chē)的安全以及虛擬駕駛員的智能化水平至關(guān)重要。

由于需要冗余和多樣化的傳感器和計(jì)算系統(tǒng)，因此處理流水線的設(shè)計(jì)和優(yōu)化存在一定的難度。本文將介紹小馬智行（Pony.ai）車(chē)載傳感器數(shù)據(jù)處理流水線的發(fā)展歷程。

小馬智行的傳感器配置包含多個(gè)攝像頭、激光雷達(dá)和雷達(dá)。上游模塊負(fù)責(zé)同步傳感器，將數(shù)據(jù)封裝成消息并發(fā)送到下游模塊，后者根據(jù)這些數(shù)據(jù)消息完成物體分割、分類(lèi)和檢測(cè)等。

每種類(lèi)型的傳感器數(shù)據(jù)可能被多個(gè)模塊使用，并且用戶的算法可能是傳統(tǒng)的或基于神經(jīng)網(wǎng)絡(luò)的。

小馬智行自動(dòng)駕駛傳感系統(tǒng)功能

乘員安全是第一要?jiǎng)?wù)，因此整個(gè)流水線必須以最高效率運(yùn)行。而傳感器數(shù)據(jù)處理系統(tǒng)對(duì)安全的影響主要體現(xiàn)在兩個(gè)方面。

第一，自動(dòng)駕駛系統(tǒng)處理傳感器數(shù)據(jù)的速度是安全的決定性因素之一。如果感知和定位算法收到的傳感器數(shù)據(jù)出現(xiàn)數(shù)百毫秒的延遲，那么車(chē)輛就無(wú)法及時(shí)做出決策。

第二，整個(gè)硬件/軟件系統(tǒng)必須是可靠的，才能實(shí)現(xiàn)長(zhǎng)期保障。消費(fèi)者絕不會(huì)愿意購(gòu)買(mǎi)或乘坐在制造幾個(gè)月后就出現(xiàn)問(wèn)題的自動(dòng)駕駛汽車(chē)，這一點(diǎn)在量產(chǎn)階段至關(guān)重要。

高效處理傳感器數(shù)據(jù)

考慮到傳感器、 GPU 架構(gòu)和 GPU 內(nèi)存，需要采取較為全面的方法應(yīng)對(duì)傳感器處理流水線中的瓶頸。

從傳感器到 GPU

在小馬智行成立之初，傳感器配置由現(xiàn)成組件構(gòu)成。小馬智行使用基于 USB 和以太網(wǎng)的攝像頭，并將其直接連接到車(chē)載電腦上， CPU 負(fù)責(zé)從 USB /以太網(wǎng)接口讀取數(shù)據(jù)。

從攝像頭到 CPU 再到 GPU 的流水線功能

雖然這種方法有效，但在設(shè)計(jì)上存在一個(gè)基本問(wèn)題。USB 和以太網(wǎng)攝像頭接口（GigE-camera）會(huì)消耗 CPU。隨著越來(lái)越多高分辨率攝像頭的加入， CPU 很快就會(huì)不堪重負(fù)，無(wú)法執(zhí)行所有輸入輸出（I/O）操作。這種設(shè)計(jì)很難在保持足夠低的延遲的情況下進(jìn)行擴(kuò)展。

為了解決這個(gè)問(wèn)題，小馬智行為攝像頭和激光雷達(dá)增加了基于 FPGA 的傳感器網(wǎng)關(guān)。

擔(dān)任傳感器網(wǎng)關(guān)的 FPGA （傳感器部分使用攝像頭示范）

FPGA 通過(guò)處理攝像頭觸發(fā)和同步邏輯來(lái)實(shí)現(xiàn)更好的傳感器融合。當(dāng)攝像頭數(shù)據(jù)包準(zhǔn)備就緒時(shí)，就會(huì)觸發(fā) DMA 傳輸，通過(guò) PCIe 總線將數(shù)據(jù)從 FPGA 復(fù)制到主存儲(chǔ)器。DMA 引擎在 FPGA 上執(zhí)行此操作，不會(huì)占用 CPU。它不僅解放了 CPU 的 I/O 資源，而且還減少了數(shù)據(jù)傳輸延遲，使傳感器的配置更具有可擴(kuò)展性。

由于許多在 GPU 上運(yùn)行的神經(jīng)網(wǎng)絡(luò)模型都需要使用攝像頭數(shù)據(jù)，在通過(guò) DMA 將數(shù)據(jù)從 FPGA 傳輸?shù)?CPU 之后，仍須將其復(fù)制到 GPU 內(nèi)存。因此在某處需要進(jìn)行 CUDA HostToDevice內(nèi)存拷貝， FHD 分辨率的圖像每幀的用時(shí)需要約 1.5ms。

但小馬智行想進(jìn)一步減少延遲。理想情況下，應(yīng)直接將攝像頭數(shù)據(jù)傳輸?shù)?GPU 內(nèi)存，而不需要通過(guò) CPU。

攝像頭/FPGA/CPU/GPU流水線功能塊圖，使用 RDMA 在 FPGA 和 GPU 之間進(jìn)行通信

GPU Direct RDMA 使小馬智行能夠通過(guò) PCIe BAR （定義 PCIe 地址空間線性窗口的基地址寄存器）預(yù)分配 CUDA 內(nèi)存供 PCIe peers 訪問(wèn)。

它還為第三方設(shè)備驅(qū)動(dòng)程序提供了一系列內(nèi)核空間 API 以獲得 GPU 內(nèi)存物理地址。這些 API 方便了第三方設(shè)備的 DMA 引擎直接向 GPU 內(nèi)存發(fā)送和讀取數(shù)據(jù)，就像是在向主內(nèi)存發(fā)送和讀取數(shù)據(jù)一樣。

GPU Direct RDMA 通過(guò)消除 CPU 到 GPU 的復(fù)制來(lái)減少延遲，并在 PCIe Gen3 x8 下實(shí)現(xiàn)約 6 GB/s 的最高帶寬（理論極限值為 8 GB/s）。

跨 GPU 擴(kuò)展

由于計(jì)算工作負(fù)載的增加，小馬智行需要不止一個(gè) GPU。隨著越來(lái)越多的 GPU 加入到系統(tǒng)中，GPU之間的通信也可能成為瓶頸。經(jīng)中轉(zhuǎn)緩沖區(qū)通過(guò) CPU 會(huì)增加 CPU 成本，并限制整體帶寬。

通過(guò) PCIe 交換機(jī)進(jìn)行 GPU-GPU 通信

小馬智行添加了 PCIe 開(kāi)關(guān)提供最好的對(duì)等傳輸性能。在測(cè)量中，對(duì)等通信可以達(dá)到 PCIe 速度上限，提高了跨多個(gè) GPU 的擴(kuò)展性。

將計(jì)算轉(zhuǎn)移到專(zhuān)用硬件

小馬智行還將以前在 CUDA 核上運(yùn)行的任務(wù)轉(zhuǎn)移到專(zhuān)用硬件上，以加速傳感器數(shù)據(jù)處理。

例如，當(dāng)把 FHD 攝像頭圖像編碼成 JPEG 字符串時(shí)， NvJPEG 庫(kù)在 RTX5000 GPU 的單個(gè) CPU 線程上需要約 4 毫秒。NvJPEG 可能會(huì)消耗 CPU 和 GPU 資源，這是因?yàn)樗囊恍╇A段（比如 Huffman 編碼）可能完全是在 CPU 上運(yùn)行的。

使用 GPU 上的 NvJPEG 庫(kù)進(jìn)行 JPEG 編碼的數(shù)據(jù)流功能塊圖

小馬智行在車(chē)輛上采用了 NVIDIA 視頻編解碼器，以減輕 CPU 和 GPU （ CUDA 部分）進(jìn)行圖像編碼和解碼的負(fù)擔(dān)。此編解碼器在 GPU 的專(zhuān)用部分使用編碼器。它屬于 GPU 的一部分，但不會(huì)與用于運(yùn)行內(nèi)核和深度學(xué)習(xí)模型的其他 CUDA 資源相沖突。

小馬智行也一直在使用 NVIDIA GPU 上的專(zhuān)用硬件視頻編碼器將圖像壓縮格式從 JPEG 遷移到 HEVC（H.265）。這實(shí)現(xiàn)了編碼速度的提高，并為其他任務(wù)釋放了 CPU 和 GPU 資源。

在不影響 CUDA 性能的情況下，在 GPU 上對(duì) FHD 圖像進(jìn)行完全編碼需要 3 毫秒。該性能在純 I 幀模式下測(cè)量，可確保各幀之間質(zhì)量和壓縮偽影的一致性。

避免消耗 CUDA 核或 CPU 的 HEVC 編碼數(shù)據(jù)流功能塊圖

NVIDIA 視頻編解碼器在 GPU 芯片的專(zhuān)用分區(qū)中使用編碼器，不會(huì)消耗 CUDA 核或 CPU。NVENC 支持 H264/H265。將 FHD 圖像編碼為 HEVC 需要約 3ms，因此可以釋放 GPU 和 CPU 去處理其他任務(wù)。小馬智行使用純 I 幀模式，確保每幀都有相同的質(zhì)量和相同類(lèi)型的偽影。

GPU 上的數(shù)據(jù)流

另一個(gè)關(guān)鍵是將攝像頭幀作為信息發(fā)送到下游模塊的效率。

小馬智行使用谷歌的 ProtoBuf 來(lái)定義消息。以CameraFrame信息為例，攝像頭規(guī)格和屬性是該消息中的基本數(shù)據(jù)類(lèi)型。由于 ProtoBuf 的限制，真正的有效載荷——攝像頭數(shù)據(jù)必須被定義為主系統(tǒng)內(nèi)存中的字節(jié)。

CameraFrame 消息示例

以下代碼示例中的消息是一個(gè)原型。由于 protobuf 的限制， data 這一成員必須在主內(nèi)存中。

message CameraFrame {
optional string device_name = 1;
optional int32 width = 2;
optional int32 height = 3;
optional int32 pixel_format = 4;
optional bytes data = 5;
};

小馬智行使用發(fā)布-訂閱模式，通過(guò)模塊間的零拷貝消息傳遞來(lái)共享信息。CameraFrame 信息的許多用戶模塊使用攝像頭數(shù)據(jù)進(jìn)行深度學(xué)習(xí)推理。

在最初的設(shè)計(jì)中，當(dāng)此類(lèi)模塊收到信息時(shí)，它不得不調(diào)用 CUDA 的HostToDevice拷貝，在推理前將攝像頭數(shù)據(jù)傳輸?shù)?GPU 上。

發(fā)布-訂閱模型功能：攝像頭模塊向多個(gè)用戶模塊發(fā)送 CameraFrame 信息。每個(gè)用戶模塊需要進(jìn)行 CPU 到 GPU 的內(nèi)存拷貝。

每個(gè)模塊都必須進(jìn)行 CUDAHostToDevice拷貝，這項(xiàng)工作既多余又消耗資源。雖然零拷貝消息傳遞框架在 CPU 上運(yùn)行良好，但它需要進(jìn)行大量 CPU-GPU 數(shù)據(jù)拷貝。

支持 GPU 的零拷貝發(fā)布-訂閱信息傳遞

小馬智行通過(guò) protobuf 的插件 API 將新的數(shù)據(jù)類(lèi)型——GpuData字段添加到 protobuf 代碼生成器中，從而解決了這個(gè)問(wèn)題。如同 CPU 內(nèi)存bytes字段，GpuData支持標(biāo)準(zhǔn)resize操作。但它的物理數(shù)據(jù)存儲(chǔ)在 GPU 上。

當(dāng)用戶模塊收到消息時(shí)，他們可以檢索能夠直接使用的 GPU 數(shù)據(jù)指針。因此，小馬智行在整個(gè)流水線上實(shí)現(xiàn)了完全的零拷貝。

改進(jìn) GPU 內(nèi)存分配

當(dāng)我們調(diào)用GpuDataproto 的resize操作時(shí)，它會(huì)調(diào)用 CUDA 中的cudaMalloc參數(shù)。當(dāng)GpuDataproto 信息被銷(xiāo)毀時(shí)，它會(huì)調(diào)用cudaFree。

這兩個(gè) API 操作的成本并不低，因?yàn)樗鼈儽仨毿薷?GPU 的內(nèi)存映射。每次調(diào)用可能需要約 0.1ms。

由于該 proto 消息被廣泛使用，而攝像頭在不停地產(chǎn)生數(shù)據(jù)，所以小馬智行應(yīng)該優(yōu)化 GPU proto 消息的分配與釋放（alloc/free）成本。

小馬智行采用了固定片段大小的 GPU 內(nèi)存池來(lái)解決這個(gè)問(wèn)題。這個(gè)想法很簡(jiǎn)單：維護(hù)一個(gè)預(yù)先分配的 GPU 內(nèi)存池，內(nèi)存池的每個(gè)片段大小匹配攝像頭數(shù)據(jù)幀的大小。每次alloc時(shí)，就從堆棧中取出一片 GPU 內(nèi)存。每次free時(shí)，該 GPU 內(nèi)存片段就會(huì)返回到池中。通過(guò)重新使用 GPU 內(nèi)存，alloc/free時(shí)間接近于零。

僅支持固定分配大小的 GPU 內(nèi)存池

如果想支持不同分辨率的攝像頭該怎么辦？使用這種固定大小的內(nèi)存池，就必須始終分配盡量多的大小，或者初始化插槽大小不同的多個(gè)內(nèi)存池。這兩種情況都會(huì)降低效率。

CUDA 11.2 的新功能解決了這個(gè)問(wèn)題。它正式支持cudaMemPool，該內(nèi)存池可以被預(yù)先分配并在之后用于cudaMalloc和free。與之前的方法相比，這種方法適用于任何分配大小，以極小性能代價(jià)極大地提高了靈活性（每次分配約 2us）。

支持動(dòng)態(tài)分配大小的 GPU 內(nèi)存池

在這兩種方法中，當(dāng)內(nèi)存池溢出時(shí)，resize的調(diào)用會(huì)退回到傳統(tǒng)的cudaMalloc和free。

YUV 顏色空間中更干凈的數(shù)據(jù)流

通過(guò)上述所有的硬件設(shè)計(jì)和系統(tǒng)軟件架構(gòu)優(yōu)化，小馬智行實(shí)現(xiàn)了高效的數(shù)據(jù)流。下一步是優(yōu)化數(shù)據(jù)格式本身。

小馬智行的系統(tǒng)曾經(jīng)在 RGB 顏色空間中處理攝像頭數(shù)據(jù)。但攝像頭的圖像信號(hào)處理（ISP）輸出是在 YUV 顏色空間，在 GPU 上進(jìn)行 YUV 到 RGB 的轉(zhuǎn)換需要約 0.3ms。此外，一些感知組件不需要顏色信息。向它們提供 RGB 顏色像素是一種浪費(fèi)。

使用 YUV 格式避免顏色空間轉(zhuǎn)換

鑒于這些原因，小馬智行從 RGB 攝像頭格式遷移到 YUV 格式。由于人類(lèi)視覺(jué)對(duì)色度信息不如對(duì)亮度信息那么敏感，因此小馬智行選擇使用 YUV420 像素格式。

通過(guò)采用 YUV420 像素格式，小馬智行減少了一半的 GPU 內(nèi)存消耗。這也使小馬智行能夠只將 Y 通道發(fā)送到不需要色度信息的感知組件。與 RGB 相比，這減少了三分之二的 GPU 內(nèi)存消耗。

在 GPU 上處理激光雷達(dá)數(shù)據(jù)

除了攝像頭數(shù)據(jù)，小馬智行還在 GPU 上處理激光雷達(dá)數(shù)據(jù)，而且這些數(shù)據(jù)更加稀疏。不同類(lèi)型的激光雷達(dá)增加了這項(xiàng)處理工作的難度。在處理激光雷達(dá)數(shù)據(jù)時(shí)，小馬智行采取了一些優(yōu)化措施。

• 由于激光雷達(dá)掃描數(shù)據(jù)包含大量物理信息，小馬智行使用對(duì) GPU 友好的數(shù)組結(jié)構(gòu)代替結(jié)構(gòu)數(shù)組來(lái)描述點(diǎn)云，使 GPU 的內(nèi)存訪問(wèn)模式變得更加凝聚而不是分散。

• 當(dāng)必須在 CPU 和 GPU 之間交換時(shí)，將數(shù)據(jù)保存在鎖定內(nèi)存中以加速傳輸。

• NVIDIA CUB 庫(kù)在小馬智行的的處理流水線中被廣泛使用，尤其是 Scan/Select 操作。

從激光雷達(dá)傳感器到 GPU 上點(diǎn)云處理的流水線功能

通過(guò)所有這些優(yōu)化，小馬智行在關(guān)鍵路徑上將整個(gè)流水線的延遲減少了約 4ms。

總時(shí)間線

憑借所有這些優(yōu)化，小馬智行可以使用內(nèi)部的時(shí)間線可視化工具查看系統(tǒng)追蹤。

從傳感器數(shù)據(jù)到深度學(xué)習(xí)推理的總時(shí)間線

總時(shí)間線顯示了小馬智行目前對(duì) GPU 的總體依賴(lài)程度。盡管這兩個(gè) GPU 在 80% 的時(shí)間內(nèi)被使用，但 GPU0 和 GPU1 的工作負(fù)載并不平衡。GPU 0 在整個(gè)感知模塊迭代過(guò)程中被大量使用，而 GPU1 在迭代的中間階段有更多的空閑時(shí)間。

未來(lái)小馬智行將專(zhuān)注于進(jìn)一步提高 GPU 的效率。

生產(chǎn)就緒

在開(kāi)發(fā)初期，小馬智行通過(guò) FPGA 輕松試驗(yàn)在基于硬件的傳感器數(shù)據(jù)處理方面的想法。隨著傳感器數(shù)據(jù)處理單元變得越來(lái)越成熟，小馬智行開(kāi)始研究如何使用系統(tǒng)級(jí)芯片（SoC）提供緊湊、可靠的生產(chǎn)級(jí)傳感器數(shù)據(jù)處理器。

經(jīng)發(fā)現(xiàn)，車(chē)規(guī)級(jí) NVIDIA DRIVE Orin 系統(tǒng)級(jí)芯片完全滿足小馬智行的要求。它符合 ASIL 認(rèn)證，因此非常適合在量產(chǎn)車(chē)輛上運(yùn)行。

從 FPGA 遷移到 NVIDIA DRIVE Orin

在開(kāi)發(fā)初期，小馬智行通過(guò) FPGA 輕松試驗(yàn)在基于硬件的傳感器數(shù)據(jù)處理方面的想法。

隨著傳感器數(shù)據(jù)處理單元變得越來(lái)越成熟，小馬智行開(kāi)始研究如何使用系統(tǒng)級(jí)芯片（SoC）提供緊湊、可靠的生產(chǎn)級(jí)傳感器數(shù)據(jù)處理器。

小馬智行發(fā)現(xiàn)，車(chē)規(guī)級(jí) NVIDIA DRIVE Orin 系統(tǒng)級(jí)芯片完全滿足要求。它符合 ASIL 認(rèn)證，因此非常適合在量產(chǎn)車(chē)輛上運(yùn)行。

小馬智行將使用 NVIDIA DRIVE Orin 來(lái)處理所有傳感器信號(hào)處理、同步、數(shù)據(jù)包收集以及攝像頭幀編碼。小馬智行估計(jì)這種設(shè)計(jì)與其他架構(gòu)優(yōu)化結(jié)合后，將節(jié)省約 70% 的總硬件成本。

使用 NVIDIA DRIVE Orin 系統(tǒng)級(jí)芯片作為新的傳感器網(wǎng)關(guān)

通過(guò)與 NVIDIA 合作，小馬智行確保 Orin-CPU-GPU 組件之間的所有通信均通過(guò) PCIe 總線進(jìn)行，并通過(guò) NvStreams 支持 DMA。

• 對(duì)于計(jì)算密集型深度學(xué)習(xí)工作， NVIDIA Orin 系統(tǒng)級(jí)芯片使用 NvStream 將傳感器數(shù)據(jù)傳輸?shù)姜?dú)立的 GPU 上進(jìn)行處理。

• 對(duì)于非 GPU 工作， NVIDIA Orin 系統(tǒng)級(jí)芯片使用 NvStream 將數(shù)據(jù)傳輸?shù)街鳈C(jī) CPU 進(jìn)行處理。

Orin 提供每秒 254 萬(wàn)億次計(jì)算性能，可以處理與目前 L4 級(jí)自動(dòng)駕駛汽車(chē)計(jì)算平臺(tái)上所使用的 RTX5000 獨(dú)立 GPU 類(lèi)似的工作負(fù)載。但它需要通過(guò)多項(xiàng)優(yōu)化，才能充分釋放 NVIDIA DRIVE Orin 系統(tǒng)級(jí)芯片的潛力，例如：

• 結(jié)構(gòu)性稀疏網(wǎng)絡(luò)

• DLA（深度學(xué)習(xí)加速器）核

• 跨多個(gè) NVIDIA DRIVE Orin 系統(tǒng)級(jí)芯片的擴(kuò)展

結(jié)論

小馬智行傳感器數(shù)據(jù)處理流水線的發(fā)展歷程顯示了小馬智行采用系統(tǒng)化方法來(lái)實(shí)現(xiàn)高效率的數(shù)據(jù)處理流水線和更高的系統(tǒng)可靠性，這有助于實(shí)現(xiàn)更高的安全目標(biāo)。這種方法背后的簡(jiǎn)單理念是：

• 使數(shù)據(jù)流簡(jiǎn)單而流暢。數(shù)據(jù)應(yīng)該以最小化轉(zhuǎn)化開(kāi)銷(xiāo)的格式被直接傳輸?shù)剿鼘⒈皇褂玫牡胤健?/p>

• 專(zhuān)用硬件用于計(jì)算密集型任務(wù)，通用計(jì)算資源用于其他任務(wù)。

這種方法無(wú)法僅靠軟件或硬件來(lái)實(shí)現(xiàn)，而是依靠在軟件和硬件協(xié)同設(shè)計(jì)方面的共同努力。這對(duì)于滿足快速增長(zhǎng)的計(jì)算需求與生產(chǎn)期望至關(guān)重要。

原文標(biāo)題：加速小馬智行自動(dòng)駕駛汽車(chē)傳感器數(shù)據(jù)處理流水線