RK3588這個(gè)芯片做邊緣AI視覺的人應(yīng)該都很熟了4顆A76加4顆A55內(nèi)置6TOPS算力的NPU還有RGA、VPU、Mali-G610 GPU接口上MIPI CSI、HDMI、PCIe一應(yīng)俱全。但芯片規(guī)格只是第一步真正讓項(xiàng)目跑起來并且跑得穩(wěn)數(shù)據(jù)通路怎么設(shè)計(jì)才是見功夫的地方。這個(gè)話題我打算接著前幾期專門聊零拷貝跨進(jìn)程通信。為什么單獨(dú)拿出來說因?yàn)槲乙娺^太多項(xiàng)目模型跑得飛快幀率卻上不去調(diào)度器一查CPU全耗在memcpy上了。RK3588上部署yolov8或者做多路RTSP實(shí)時(shí)視頻監(jiān)控?cái)?shù)據(jù)從攝像頭到NPU再到編碼器如果每個(gè)環(huán)節(jié)都拷貝一遍1080p30fps一路視頻光拷貝的帶寬開銷就有近100MB/s四路就是400MB/s。這個(gè)數(shù)字在板子上會(huì)直接體現(xiàn)為CPU占用飆升、掉幀、延遲抖動(dòng)。這篇文章把零拷貝這件事從原理到落地講透適合正在用RK3588做邊緣AI視覺、被多進(jìn)程架構(gòu)下的數(shù)據(jù)交互效率困擾的開發(fā)者。1. 為什么邊緣AI視覺里跨進(jìn)程數(shù)據(jù)通路會(huì)成為性能瓶頸1.1 一份幀數(shù)據(jù)在RK3588內(nèi)部要旅行多遠(yuǎn)先不急著上代碼我們先看清楚一個(gè)問題一份圖像數(shù)據(jù)從攝像頭進(jìn)來到最終顯示或編碼輸出在RK3588內(nèi)部到底要經(jīng)過多少個(gè)環(huán)節(jié)。典型的邊緣AI視覺鏈路是這樣的攝像頭sensor通過MIPI CSI接口輸出RAW或YUV數(shù)據(jù)進(jìn)入ISP做壞點(diǎn)校正、降噪、3A等處理ISP輸出的數(shù)據(jù)落到DDR內(nèi)存里。接著內(nèi)存里的幀要送給NPU做推理比如yolov8目標(biāo)檢測(cè)NPU算完輸出檢測(cè)框坐標(biāo)、類別、置信度這些結(jié)果通常交給CPU做后處理NMS、過濾、畫框畫完框的幀又要送給顯示控制器DRM/KMS或者硬編碼器VPU出RTSP流。在這條鏈路上數(shù)據(jù)在DDR里被多個(gè)硬件單元讀寫了多次。如果把系統(tǒng)設(shè)計(jì)成多進(jìn)程架構(gòu)——采集進(jìn)程只管采集AI進(jìn)程只管推理推流進(jìn)程只管編碼——那么每一幀圖像還要跨越進(jìn)程邊界。跨進(jìn)程意味著什么在傳統(tǒng)實(shí)現(xiàn)里就是memcpy發(fā)送方把數(shù)據(jù)從自己的用戶態(tài)緩沖區(qū)拷到內(nèi)核接收方再?gòu)膬?nèi)核拷到自己的用戶態(tài)緩沖區(qū)。這里有個(gè)很多人容易忽略的細(xì)節(jié)RK3588這類SoC和普通PC不同它的NPU、VPU、RGA對(duì)內(nèi)存有各自的偏好和要求。NPU希望輸入是物理連續(xù)的VPU和RGA對(duì)地址對(duì)齊有要求GPU則需要考慮緩存一致性。這些硬件單元的內(nèi)存視圖和進(jìn)程的虛擬內(nèi)存視圖之間本身就隔著一層。如果你只是簡(jiǎn)單用memcpy做跨進(jìn)程數(shù)據(jù)交換哪怕不考慮拷貝本身的CPU開銷也繞不開還要再映射給硬件用這層麻煩。1.2 拷貝的代價(jià)帶寬、延遲、CPU占用三本賬我們來算一筆實(shí)在的賬。一路1080p分辨率、NV12格式Y(jié)UV420半平面的幀大小是 1920 × 1080 × 1.5 ≈ 3.1MB。如果30fps一秒鐘就是約93MB/s。如果系統(tǒng)里有4路攝像頭同時(shí)做AI分析就是約373MB/s。這還只是源數(shù)據(jù)的體量。實(shí)際上在普通跨進(jìn)程拷貝方案中數(shù)據(jù)往往不止拷一次。例如采集進(jìn)程從V4L2 buffer讀出一次read或mmap后的用戶態(tài)訪問發(fā)送給AI進(jìn)程時(shí)通過共享內(nèi)存/消息隊(duì)列拷貝一次AI進(jìn)程把數(shù)據(jù)整理成NPU輸入格式又拷貝一次AI進(jìn)程把結(jié)果圖像發(fā)給顯示/編碼進(jìn)程再拷貝一次這么算下來一份數(shù)據(jù)在整個(gè)生命周期里可能被拷貝3到4次。4路1080p30fps的場(chǎng)景光拷貝吞吐量就超過1GB/s這還是在RK3588雙通道LPDDR4/LPDDR5內(nèi)存帶寬還算充裕的前提下。問題的關(guān)鍵不是帶寬不夠用而是每次拷貝都意味著CPU緩存被頻繁刷掉影響其他任務(wù)的執(zhí)行效率幀延遲增加對(duì)實(shí)時(shí)性要求高的場(chǎng)景比如工業(yè)質(zhì)檢、運(yùn)動(dòng)檢測(cè)聯(lián)動(dòng)很致命額外占用DDR帶寬而NPU、GPU、VPU這些硬件單元也在搶同一份帶寬內(nèi)存占用偏高因?yàn)槊恳环輸?shù)據(jù)在多個(gè)進(jìn)程里有多個(gè)副本。我做過的實(shí)際壓測(cè)里4路1080p30fps、模型是yolov8s的情況下如果全鏈路都用memcpy方式跨進(jìn)程傳幀CPU占用率大概多出20%到35%端到端延遲增加3到8毫秒。這個(gè)損耗在demo里看不出什么但在長(zhǎng)時(shí)間運(yùn)行的工業(yè)現(xiàn)場(chǎng)累計(jì)的掉幀數(shù)和延遲抖動(dòng)會(huì)直接影響系統(tǒng)的可用性。1.3 明確邊界哪些場(chǎng)景真的需要零拷貝說了這么多我也得潑盆冷水不是所有項(xiàng)目都需要零拷貝。如果只是單路視頻、非實(shí)時(shí)后處理、CPU負(fù)載余量很大那用傳統(tǒng)的共享內(nèi)存加拷貝完全沒問題實(shí)現(xiàn)簡(jiǎn)單調(diào)試也容易。零拷貝方案會(huì)引入fd管理、生命周期同步、緩存一致性等一堆復(fù)雜度小項(xiàng)目里可能得不償失。真正需要零拷貝的場(chǎng)景有這幾個(gè)特征多路視頻并發(fā)數(shù)據(jù)吞吐量大兩三路1080p以上幀率要求高或者端到端延遲敏感多進(jìn)程架構(gòu)模塊之間職責(zé)分離長(zhǎng)時(shí)間穩(wěn)定運(yùn)行CPU占用和散熱壓力需要控制。如果你正卡在這幾個(gè)特征里那下面的內(nèi)容值得認(rèn)真看。2. 零拷貝的底層地基DMA-BUF與dma_heap的工作方式2.1 DMA-BUF不是某個(gè)驅(qū)動(dòng)而是一套共享協(xié)議聊零拷貝繞不開DMA-BUF。很多人第一次接觸這個(gè)詞是在安卓的SurfaceFlinger里覺得它是某個(gè)圖形相關(guān)的驅(qū)動(dòng)。其實(shí)DMA-BUF是Linux內(nèi)核里一套通用的緩沖區(qū)共享機(jī)制核心思路是一塊物理內(nèi)存由某個(gè)分配者創(chuàng)建關(guān)聯(lián)一個(gè)文件描述符fd其他進(jìn)程或設(shè)備拿到這個(gè)fd后通過mmap把它映射到自己的地址空間或者直接通過這個(gè)fd把內(nèi)存交給硬件DMA使用。整個(gè)過程不拷貝數(shù)據(jù)只傳遞句柄?？梢赃@樣理解傳統(tǒng)拷貝是復(fù)印一份文件給對(duì)方零拷貝是把柜子的鑰匙遞給對(duì)方對(duì)方自己打開柜子取用那份文件。在RK3588的開發(fā)板上你大概率會(huì)看到這些節(jié)點(diǎn)/dev/dma_heap/system/dev/dma_heap/system-uncached/dev/dma_heap/cma有些固件里叫l(wèi)inux,cma以及Rockchip自家的 /dev/ion老固件常見dma_heap是內(nèi)核5.6之后主推的分配接口ION逐漸被淘汰。在RK3588的現(xiàn)代固件內(nèi)核5.10及以上里推薦直接使用dma_heap。2.2 RK3588上能直接拿到的內(nèi)存類型實(shí)際使用中邊緣AI視覺項(xiàng)目主要關(guān)心兩類內(nèi)存連續(xù)物理內(nèi)存CMANPU、VPU、ISP這些硬件單元做DMA時(shí)很多要求物理地址連續(xù)。CMA區(qū)域就是預(yù)留給這類用途的。dma_heap的cma heap分配出來的就是這類內(nèi)存。非連續(xù)但可DMA的內(nèi)存system heap硬件支持通過IOMMU/SMMU做分散聚合所以不需要物理連續(xù)。RK3588的NPU、RGA、VPU都有SMMU支持所以很多場(chǎng)景用system heap就夠了分配成功率更高也不容易把CMA區(qū)域耗盡。此外還有uncached和cached的區(qū)別。cached內(nèi)存對(duì)CPU訪問友好走Cache但硬件DMA操作后需要做緩存同步uncached內(nèi)存CPU訪問慢一些但不存在緩存一致性問題硬件寫完CPU直接讀就是最新數(shù)據(jù)。這塊內(nèi)存怎么分配在用戶態(tài)可以直接打開/dev/dma_heap/system-uncached發(fā)一個(gè)DMA_HEAP_IOCTL_ALLOC ioctl拿到fd。代碼大致長(zhǎng)這樣#include linux/dma-heap.h #include sys/ioctl.h #include fcntl.h #include unistd.h int alloc_dma_buf(size_t size) { int heap_fd open(/dev/dma_heap/system-uncached, O_RDWR); if (heap_fd 0) { perror(open dma_heap); return -1; } struct dma_heap_allocation_data data { .len size, .fd_flags O_CLOEXEC | O_RDWR, .heap_flags 0, }; if (ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, data) 0) { perror(DMA_HEAP_IOCTL_ALLOC); close(heap_fd); return -1; } close(heap_fd); return data.fd; // 這就是dma-buf的fd }注意分配到的這個(gè)fd屬于某個(gè)進(jìn)程。如果另一個(gè)進(jìn)程也要用它要么通過fork繼承特權(quán)場(chǎng)景常用要么走跨進(jìn)程fd傳遞機(jī)制下面會(huì)專門講。2.3 CPU訪問DMA-BUF時(shí)那個(gè)最容易漏掉的SYNC操作拿到dma-buf的fd之后進(jìn)程可以用mmap把它映射進(jìn)自己的用戶態(tài)地址空間void *map_dma_buf(int dma_fd, size_t size) { void *addr mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, dma_fd, 0); if (addr MAP_FAILED) { perror(mmap dma_buf); return NULL; } return addr; }這里有一個(gè)非常多見的坑對(duì)于cached類型的內(nèi)存CPU訪問之前和硬件訪問之后必須做緩存同步。如果你直接讀寫mmap出來的地址而這塊內(nèi)存剛被NPU或者攝像頭DMA改寫過你讀到的很可能是Cache里的舊數(shù)據(jù)。反過來CPU改完數(shù)據(jù)要交給硬件如果不主動(dòng)刷Cache硬件DMA可能讀到舊數(shù)據(jù)。內(nèi)核提供的接口是DMA_BUF_IOCTL_SYNCstruct dma_buf_sync sync { .flags DMA_BUF_SYNC_START | DMA_BUF_SYNC_READ, }; ioctl(dma_fd, DMA_BUF_IOCTL_SYNC, sync); // 在這里安全地讀取數(shù)據(jù) sync.flags DMA_BUF_SYNC_END | DMA_BUF_SYNC_READ; ioctl(dma_fd, DMA_BUF_IOCTL_SYNC, sync);如果不想糾結(jié)同步可以干脆用uncached內(nèi)存代價(jià)是CPU讀寫性能稍差。但注意用uncached內(nèi)存做CPU后處理比如NMS循環(huán)、畫框時(shí)大量隨機(jī)訪問會(huì)明顯慢于cached內(nèi)存。我自己實(shí)測(cè)畫框這種頻繁小寫操作uncached比cached慢15%到30%。所以更推薦的做法是NPU輸入用uncached保證一致性畫框、疊加這種CPU操作放到一個(gè)cached的dma-buf上配合SYNC ioctl來管理。3. 在RK3588上打通一路零拷貝視覺管線3.1 端到端鏈路設(shè)計(jì)與內(nèi)存分配策略聊完底層機(jī)制我們來看一個(gè)完整的設(shè)計(jì)。假設(shè)要這樣做一路AI視覺任務(wù)進(jìn)程A攝像頭采集 ISP輸出進(jìn)程BRKNN NPU推理 后處理進(jìn)程CRGA縮放/畫框 VPU編碼RTSP推流三個(gè)進(jìn)程各司其職。傳統(tǒng)方案里A把每幀拷貝給BB處理完拷貝給C。零拷貝方案的設(shè)計(jì)目標(biāo)是讓同一塊dma-buf在這三個(gè)進(jìn)程之間流轉(zhuǎn)只在必要的時(shí)候才新分配。一個(gè)經(jīng)驗(yàn)做法是建立一個(gè)幀緩沖池進(jìn)程A啟動(dòng)后從dma_heap分配一定數(shù)量的dma-buf按幀池容量比如5到8幀每幀圖片數(shù)據(jù)直接由ISP/RGA寫入這些dma-buf進(jìn)程A通過IPC把dma-buf的fd發(fā)給進(jìn)程B進(jìn)程B在fd上mmap或交給RKNN推理完成后把fd再轉(zhuǎn)給進(jìn)程C進(jìn)程C用RGA疊加結(jié)果、縮放然后送入VPU編碼。內(nèi)存分配只發(fā)生在啟動(dòng)階段運(yùn)行階段只有fd在不同進(jìn)程間流轉(zhuǎn)數(shù)據(jù)本身不移動(dòng)。這里有個(gè)細(xì)節(jié)值得強(qiáng)調(diào)提前分配幀池不要在每幀處理時(shí)反復(fù)分配/釋放dma-buf。我在項(xiàng)目里一開始偷懶每幀都現(xiàn)分配結(jié)果多路并發(fā)時(shí)內(nèi)存碎片很快出現(xiàn)跑幾個(gè)小時(shí)就分配失敗。幀池化之后系統(tǒng)穩(wěn)定運(yùn)行時(shí)間從幾小時(shí)提升到一周以上。3.2 跨進(jìn)程轉(zhuǎn)發(fā)DMA-BUF fd的兩種可靠姿勢(shì)那么問題來了fd怎么從一個(gè)進(jìn)程傳給另一個(gè)進(jìn)程fd本質(zhì)上是進(jìn)程級(jí)的文件描述符表項(xiàng)不能直接通過普通的int傳值給對(duì)方——同一個(gè)整數(shù)值在不同進(jìn)程里可能指向完全不同的文件。兩種可靠的轉(zhuǎn)發(fā)方式方式一Unix域socket SCM_RIGHTSLinux通用用sendmsg/recvmsg發(fā)送輔助數(shù)據(jù)讓內(nèi)核把fd從一個(gè)進(jìn)程的fd表復(fù)制到另一個(gè)進(jìn)程的fd表。這是純用戶態(tài)最通用的方案不依賴Android系統(tǒng)純Linux環(huán)境比如Debian 11、Ubuntu都能用。// 發(fā)送方把dma_fd通過socket傳給接收方 void send_fd(int sock, int fd) { struct msghdr msg {0}; char buf[CMSG_SPACE(sizeof(int))] {0}; struct iovec iov { .iov_base F, .iov_len 1 }; msg.msg_iov iov; msg.msg_iovlen 1; msg.msg_control buf; msg.msg_controllen sizeof(buf); struct cmsghdr *cmsg CMSG_FIRSTHDR(msg); cmsg-cmsg_level SOL_SOCKET; cmsg-cmsg_type SCM_RIGHTS; cmsg-cmsg_len CMSG_LEN(sizeof(int)); memcpy(CMSG_DATA(cmsg), fd, sizeof(int)); sendmsg(sock, msg, 0); } // 接收方收到的是一個(gè)新的、可用的fd int recv_fd(int sock) { struct msghdr msg {0}; char buf[CMSG_SPACE(sizeof(int))] {0}; struct iovec iov { .iov_base F, .iov_len 1 }; msg.msg_iov iov; msg.msg_iovlen 1; msg.msg_control buf; msg.msg_controllen sizeof(buf); recvmsg(sock, msg, 0); struct cmsghdr *cmsg CMSG_FIRSTHDR(msg); if (!cmsg || cmsg-cmsg_type ! SCM_RIGHTS) { return -1; } int fd 0; memcpy(fd, CMSG_DATA(cmsg), sizeof(int)); return fd; }這里的開銷是一次sendmsg 一次內(nèi)核級(jí)的fd表復(fù)制。相比整幀數(shù)據(jù)拷貝這個(gè)開銷幾乎可以忽略實(shí)測(cè)一次fd傳遞大約在微秒到幾十微秒級(jí)別。方式二BinderAndroid系統(tǒng)方案如果你的RK3588跑的是Android系統(tǒng)Binder是更熟悉的方案。Android的SurfaceBuffer跨進(jìn)程共享本質(zhì)上就是把dma-buf fd通過Binder傳給對(duì)方接收方再用gralloc映射。但這個(gè)方案和Android圖形棧綁得比較緊做純Linux邊緣計(jì)算設(shè)備時(shí)基本用不上。這篇文章按純Linux環(huán)境來講用的就是SCM_RIGHTS。還有一個(gè)土辦法是讓兩個(gè)進(jìn)程fork自同一個(gè)父進(jìn)程fd天然被繼承不需要傳遞。但這要求主進(jìn)程先分配好所有dma-buf并派生子進(jìn)程進(jìn)程結(jié)構(gòu)上不夠靈活我一般只在快速原型時(shí)用。3.3 實(shí)測(cè)零拷貝與普通拷貝的量化對(duì)比這里放一組我在RK3588開發(fā)板8GB內(nèi)存版本Debian 11系統(tǒng)上做的對(duì)比實(shí)測(cè)單路1080p30fps NV12幀從采集進(jìn)程到AI進(jìn)程這一段。方案A普通共享內(nèi)存 memcpy。每幀約3.1MB拷貝用時(shí)平均約1.2毫秒發(fā)送方和接收方各占一次memcpy總共約2.4毫秒期間CPU占用約為單核的25%左右。方案Bdma-buf SCM_RIGHTS傳fd。每幀不拷貝數(shù)據(jù)只有一次fd傳遞用時(shí)平均約40微秒CPU占用幾乎可以忽略。單從這一段看每幀省了2.3毫秒。整條鏈路如果省掉3次拷貝每幀就是7毫秒左右的收益。對(duì)于30fps幀間隔33毫秒的場(chǎng)景這7毫秒就是穩(wěn)定不掉幀和頻繁掉幀的分水嶺。這個(gè)數(shù)據(jù)在不同固件版本、不同內(nèi)存配置下會(huì)有波動(dòng)但量級(jí)是穩(wěn)定的零拷貝在延遲上快一到兩個(gè)數(shù)量級(jí)CPU開銷接近零。4. 和RKNN NPU對(duì)接時(shí)的對(duì)齊、生命周期與同步細(xì)節(jié)4.1 RKNN輸入輸出對(duì)內(nèi)存的隱性要求在RK3588上做AI視覺推理引擎幾乎都是RKNN Runtime。rknn_input結(jié)構(gòu)體里有一個(gè)成員叫buf_type我見過不少人在這一步忽略了零拷貝入口rknn_input inputs[1]; inputs[0].index 0; inputs[0].type RKNN_TENSOR_UINT8; inputs[0].size frame_size; inputs[0].fmt RKNN_TENSOR_NHWC; inputs[0].buf mmap_addr; // 指向dma-buf mmap出來的地址 inputs[0].pass_through 0; inputs[0].buf_type RKNN_INPUT_TYPE_NORMAL; // 注意這里如果buf_type設(shè)為RKNN_INPUT_TYPE_NORMAL驅(qū)動(dòng)容易走拷貝路徑。要真正利用dma-buf的零拷貝能力需要把buf字段換成dma-buf fd并讓RKNN走對(duì)應(yīng)的零拷貝輸入通道。具體API在不同版本的rknn-toolkit2里略有差異但思路一致希望NPU直接拿到的是物理/IOMMU可尋址的內(nèi)存而不是用戶態(tài)一個(gè)普通malloc地址。這里有個(gè)很隱蔽的坑RKNN對(duì)輸入內(nèi)存往往要求對(duì)齊。比如yolov8在RK3588上部署時(shí)輸入分辨率如果是640×640那還好但如果你的圖像尺寸比較特殊推理前通過RGA做縮放時(shí)要確保輸出內(nèi)存的寬、高、stride滿足NPU的對(duì)齊要求。常見的做法是分配dma-buf時(shí)就把寬對(duì)齊到16或64字節(jié)否則模型加載不報(bào)錯(cuò)推理結(jié)果卻會(huì)偶爾出現(xiàn)偏移或錯(cuò)位。4.2 fd生命周期誰分配、誰釋放、怎么防泄漏dma-buf的核心是一個(gè)文件對(duì)象引用計(jì)數(shù)由內(nèi)核維護(hù)。一個(gè)fd被SCM_RIGHTS傳給另一個(gè)進(jìn)程后內(nèi)核會(huì)為接收進(jìn)程創(chuàng)建新的fd同時(shí)引用計(jì)數(shù)加一。釋放的規(guī)則是每個(gè)進(jìn)程關(guān)閉自己的fd當(dāng)所有fd都關(guān)閉時(shí)dma-buf內(nèi)存才會(huì)被真正回收。這帶來兩個(gè)問題問題一重復(fù)close。如果接收方用完后close了fd但發(fā)送方以為對(duì)方還在用又close一次——不會(huì)崩潰但可能提前釋放內(nèi)存。所以需要在項(xiàng)目里明確一個(gè)幀dma-buf從池中取出后由哪個(gè)進(jìn)程負(fù)責(zé)關(guān)閉。我習(xí)慣的做法是最后一個(gè)使用者負(fù)責(zé)關(guān)閉把fd的歸屬權(quán)隨幀一起傳遞后處理完成后由接收方close并歸還給幀池。問題二fd泄漏。如果接收方進(jìn)程收到fd后異常退出或發(fā)送方發(fā)送后忘記closefd會(huì)一直占著。長(zhǎng)時(shí)間運(yùn)行會(huì)出現(xiàn)分配失敗的詭異問題。我的排查經(jīng)驗(yàn)是定期通過 /proc/pid/fd 計(jì)數(shù)觀察fd數(shù)量是否線性增長(zhǎng)。多路視頻跑一晚上fd數(shù)如果不回落基本就是哪里泄漏了。代碼規(guī)范上所有SCM_RIGHTS接收路徑建議加上MSG_CMSG_CLOEXEC避免子進(jìn)程意外繼承。4.3 fence同步不讓NPU和CPU互相踩腳零拷貝的隱藏復(fù)雜度在同步不在傳輸。當(dāng)多個(gè)硬件設(shè)備共享一塊內(nèi)存時(shí)必須保證誰寫完誰才能讀。比如NPU正在讀dma-buf推理CPU此時(shí)不能去改寫這份數(shù)據(jù)?，F(xiàn)代內(nèi)核里這個(gè)職責(zé)由sync_filefence機(jī)制承擔(dān)。dma-buf可以關(guān)聯(lián)一個(gè)或一組fence設(shè)備的DMA操作完成時(shí)signal fence等待方通過poll等待fence觸發(fā)。Rockchip的NPU驅(qū)動(dòng)和V4L2驅(qū)動(dòng)都實(shí)現(xiàn)了fence機(jī)制使用的時(shí)候要在應(yīng)用層把等待邏輯處理好。舉例進(jìn)程A的采集驅(qū)動(dòng)給幀1掛上寫完成fence進(jìn)程B把幀1交給NPU時(shí)會(huì)等待這個(gè)fence同樣NPU推理完成后會(huì)signal讀完成fence進(jìn)程C才能對(duì)這幀做畫框或編碼。如果忽略這一步常見癥狀是偶發(fā)性花屏、推理結(jié)果偶爾錯(cuò)亂、畫面撕裂。這類問題在開發(fā)機(jī)上很難復(fù)現(xiàn)一到現(xiàn)場(chǎng)就頻繁出現(xiàn)排查成本極高。所以架構(gòu)設(shè)計(jì)時(shí)一定要把誰等待誰的fence鏈條畫清楚。5. 我在實(shí)際項(xiàng)目中踩過的四個(gè)坑5.1 RGA輸出內(nèi)存64字節(jié)對(duì)齊的隱性問題RK3588的RGA2/RGA3硬件對(duì)輸出內(nèi)存地址有對(duì)齊要求不同固件要求不完全一樣但64字節(jié)對(duì)齊是基本盤。如果你用RGA把YUV縮放或者轉(zhuǎn)成RGB送給NPU輸出dma-buf的地址和stride都要對(duì)齊。具體踩坑是這樣我用RGA把1080p NV12縮放成640×640 RGB輸出buffer用dma_heap分配當(dāng)時(shí)覺得dma_heap分配的內(nèi)存天然對(duì)齊沒做檢查。結(jié)果偶發(fā)出現(xiàn)輸出圖像右移幾個(gè)像素的情況。排查到后面才發(fā)現(xiàn)dma_heap的物理地址對(duì)齊沒問題但RGA計(jì)算stride時(shí)要求buffer寬度按64字節(jié)對(duì)齊640×3RGB三個(gè)通道19201920對(duì)64剛好整除沒問題換成某些非標(biāo)分辨率時(shí)就會(huì)出問題。建議所有RGA相關(guān)buffer寬度統(tǒng)一按64字節(jié)對(duì)齊計(jì)算stride再乘以高度。5.2 進(jìn)程異常退出導(dǎo)致fd泄漏這是多進(jìn)程零拷貝方案里最麻煩的問題發(fā)送方把fd發(fā)給接收方接收方處理到一半崩潰了fd沒人關(guān)。如果之后發(fā)送方又發(fā)新fd最終所有分配器都因?yàn)閒d耗盡或內(nèi)存不釋放而罷工。我在一個(gè)9路相機(jī)的項(xiàng)目里遇到過一次詭異的運(yùn)行12小時(shí)后畫面逐漸卡死。定位過程很痛苦最后是靠在每路進(jìn)程里加心跳上報(bào)、崩潰自動(dòng)重啟并且在重啟時(shí)全量close舊fd、重建幀池解決。這個(gè)方案的代價(jià)是重啟瞬間會(huì)有幾幀丟失但系統(tǒng)整體可用性大幅提升。更徹底的做法是引入一個(gè)資源管理器進(jìn)程統(tǒng)一管理dma-buf的分配和回收其他進(jìn)程只通過IPC請(qǐng)求fd用完歸還。壞處是繞了一層性能有一點(diǎn)損耗好處是任何進(jìn)程崩潰都不會(huì)把內(nèi)存池搞亂。如果你做的是長(zhǎng)期運(yùn)行的工業(yè)設(shè)備我推薦花這個(gè)代價(jià)。5.3 緩存一致性在RK3588上的特殊表現(xiàn)緩存一致性的坑大多數(shù)時(shí)候在看起來沒問題的場(chǎng)景里潛伏。比如我一度全部用uncached內(nèi)存做幀緩沖CPU畫框確實(shí)慢一些但功能正常也就沒深究。后來把幀緩沖改成cached內(nèi)存以提升CPU訪問性能結(jié)果畫面出現(xiàn)間歇性花屏測(cè)試一天才出現(xiàn)兩三次非常難排查。最后定位到是CPU畫框后沒有做DMA_BUF_IOCTL_SYNC的START|WRITE刷CacheVPU讀的時(shí)候讀到了部分舊數(shù)據(jù)。這里提醒一下使用cached dma-buf時(shí)CPU寫前后都必須做SYNC不能只做一次。寫入前用START|WRITE寫入后用END|WRITE。這一對(duì)操作缺一個(gè)長(zhǎng)期運(yùn)行都會(huì)出問題。5.4 多路并發(fā)下的內(nèi)存碎片難題多路視頻并發(fā)時(shí)每一路都要維護(hù)自己的一堆幀緩沖。如果所有路共用一個(gè)大池子雖然內(nèi)存利用率高但分配/釋放頻率也高時(shí)間一長(zhǎng)CMA區(qū)域會(huì)被切成碎片后續(xù)大塊分配失敗。我的做法是把關(guān)鍵路徑上的大塊dma-buf全部在啟動(dòng)階段預(yù)分配好運(yùn)行期間不新增、不釋放如果需要?jiǎng)討B(tài)調(diào)整也只在系統(tǒng)空閑時(shí)做。預(yù)分配的數(shù)量按最大路數(shù) × 每路幀數(shù) × 余量計(jì)算比如8路每路5幀再留2路余量就是50幀左右。一套這樣的固定池方案配合不加鎖的環(huán)形隊(duì)列流轉(zhuǎn)實(shí)測(cè)跑7×24小時(shí)沒有出現(xiàn)分配失敗。6. 零拷貝方案選型建議什么場(chǎng)景該用、什么場(chǎng)景別碰6.1 先想清楚多進(jìn)程還是單進(jìn)程多線程零拷貝跨進(jìn)程通信解決的是多進(jìn)程架構(gòu)下的高效數(shù)據(jù)共享問題。但反過來想如果模塊之間信任度高、代碼庫(kù)統(tǒng)一單進(jìn)程多線程可能是更簡(jiǎn)單的方案線程天然共享地址空間一個(gè)指針就能傳數(shù)據(jù)不需要fd不需要SCM_RIGHTS不需要管生命周期歸屬。什么情況下值得多進(jìn)程模塊由不同團(tuán)隊(duì)維護(hù)或者要單獨(dú)升級(jí)、單獨(dú)重啟某模塊比如采集驅(qū)動(dòng)封裝穩(wěn)定性不夠崩了不能帶崩整個(gè)系統(tǒng)有安全隔離需求不同進(jìn)程的權(quán)限不同。如果這些你都不需要我的建議是優(yōu)先單進(jìn)程多線程把線程綁定到不同CPU核心RK3588有8個(gè)核心A76和A55各司其職數(shù)據(jù)用線程間無鎖隊(duì)列傳遞性能足夠開發(fā)效率高很多。6.2 什么時(shí)候不要用零拷貝零拷貝不是銀彈。遇到下面情況我會(huì)選擇退回傳統(tǒng)拷貝方案數(shù)據(jù)量小、頻率低比如只是傳一些結(jié)構(gòu)化的小數(shù)據(jù)檢測(cè)框坐標(biāo)、溫度值一次拷貝才幾百字節(jié)沒必要付出維護(hù)fence和生命周期的復(fù)雜度數(shù)據(jù)形態(tài)需要轉(zhuǎn)換比如RAW圖轉(zhuǎn)RGB、NV12轉(zhuǎn)BGR轉(zhuǎn)換本身就要讀寫全部數(shù)據(jù)這時(shí)候拷貝轉(zhuǎn)換合在一起反而更高效硬件單元不支持直接訪問有些第三方IP核或外設(shè)沒有SMMU要求物理連續(xù)內(nèi)存而零拷貝池不好滿足不如拷貝一次省心。6.3 我的最終架構(gòu)建議綜合這些經(jīng)驗(yàn)我現(xiàn)在在RK3588上做邊緣AI視覺的標(biāo)準(zhǔn)架構(gòu)是這樣的采集進(jìn)程V4L2/ISP采集啟動(dòng)時(shí)從dma_heap分配固定幀池幀數(shù)據(jù)由ISP直接寫入dma-buf推理進(jìn)程通過SCM_RIGHTS接收dma-buf fd交給RKNN零拷貝推理后處理NMS、邏輯判斷在cached dma-buf上做輸出進(jìn)程RGA疊加結(jié)果、VPU編碼RTSP推流同樣讀寫dma-buf fd幀池和fd生命周期由最后使用者負(fù)責(zé)每個(gè)進(jìn)程崩潰時(shí)都有守護(hù)進(jìn)程拉起重啟后重建幀池。這套方案在9路1080p25fps yolov8s檢測(cè)的工業(yè)場(chǎng)景里跑過CPU占用穩(wěn)定控制在20%左右端到端延遲平均80毫秒最長(zhǎng)連續(xù)運(yùn)行兩周沒有出現(xiàn)內(nèi)存或fd泄漏。相比最初全拷貝的版本CPU占用降了三分之一掉幀數(shù)歸零。最后再分享一個(gè)小技巧調(diào)試階段可以在每個(gè)進(jìn)程里定期打印 /proc/pid/status 里的VmLck、/proc/pid/fdinfo 里的dma-buf信息把fd數(shù)量和內(nèi)存占用打點(diǎn)記錄下來跑一晚上看曲線。所有不能收斂的曲線都是問題定位起來比瞎猜快得多。