在RK3588上做邊緣AI視覺真正讓人頭疼的往往不是模型跑多快而是數(shù)據從攝像頭到NPU、再到硬編碼和RTSP推流這一路上究竟被memcpy搬了多少次。很多教程只教你怎么在板子上把YOLOv8的demo跑起來可真正做產品時采集、推理、編碼往往是三個進程幀數(shù)據如果隔著socket和共享內存來回拷貝4K分辨率下光是搬數(shù)據就能吃掉好幾個毫秒CPU占用也壓不下去。這篇文章想和你聊聊在RK3588架構下怎么做零拷貝跨進程通信把視頻幀的整個生命周期都留在DMA-BUF里讓多個進程和NPU、VPU、RGA這些硬件模塊直接引用同一塊物理內存而不是你搬給我、我搬給他。這套方法也是邊緣AI視覺工程化繞不開的一環(huán)。不管你是準備把采集、AI推理、硬編碼拆成獨立進程還是想優(yōu)化現(xiàn)有項目的幀率瓶頸下面這套基于DMA-BUF加SCM_RIGHTS的方案都能直接參考。我盡量把原理、代碼、踩坑細節(jié)都寫透。1. 為什么需要零拷貝跨進程通信先算清楚拷貝這筆賬1.1 邊緣AI視覺典型的數(shù)據流和它真正的開銷在哪先還原一個典型場景。一塊RK3588板卡上做實時視頻監(jiān)控或邊緣計算盒子通常會有這么幾個角色采集進程負責從MIPI CSI或USB攝像頭拿圖像走Rockchip的rockit或V4L2框架AI進程負責跑NPU推理常見的是YOLOv8或者各種檢測分類模型編碼進程負責把處理后的畫面交給MPP硬編碼成H.264/H.265再走RTSP推給客戶端另外可能還有一個業(yè)務進程負責疊加OSD、保存錄像之類。如果按照最樸素的做法采集進程拿到一幀圖像后先把數(shù)據從內核buffer拷到用戶態(tài)內存然后通過socket發(fā)給AI進程AI進程再拷到自己內存跑完模型后再拷一次發(fā)給編碼進程編碼進程為了把數(shù)據交給硬件編碼器可能還要再拷一次。這條路走下來一幀4K NV12圖像數(shù)據量大約12MB拷三到四次什么概念RK3588的A76大核跑memcpy理想情況能到4到6GB/s左右但實際受DDR頻率、cache狀態(tài)、內存是否對齊影響往往打折扣。一幀4K大約12MB單次memcpy耗時大概2到4毫秒。算上socket收發(fā)過程中內核緩沖區(qū)的那幾次搬運一幀畫面光是數(shù)據搬運就吃掉6到15毫秒。如果跑30fps幀預算33毫秒拷貝占了三分之一甚至接近一半這還沒算模型推理和編碼的時間。多路視頻時這個開銷還會成倍往上翻。1.2 多進程還是多線程怎么選更合理有人會問既然進程間傳數(shù)據這么麻煩為什么不把所有邏輯塞進一個進程用多線程加指針直接共享內存天然零拷貝這個問題的標準答案是看你做的是demo還是產品。demo當然可以全塞一個進程但真實產品里采集、AI、編碼往往來自不同的SDKRockchip的RKMPP、rockit和RKNN runtime對資源的管理方式不同錯誤處理和崩潰影響范圍也不一樣。多線程單一進程的好處是共享數(shù)據簡單壞處是一個模塊崩了整條流水線跟著崩權限也難隔離。采集進程可能需要訪問攝像頭設備節(jié)點AI進程其實沒必要拿那么高的權限拆開之后可以單獨降權、單獨重啟這對邊緣盒子的穩(wěn)定性和可維護性是很重要的。所以很多RK3588上的商業(yè)方案都會選擇多進程架構把攝像頭上層、AI業(yè)務、編碼推流分開部署。既然選了多進程跨進程傳輸大塊圖像數(shù)據就是一個必須解決的問題而且必須高效。1.3 “共享內存”不等于“零拷貝”別被概念騙了不少人在這一步會陷入一個誤區(qū)用POSIX共享內存shm_open加mmap兩個進程不就能直接讀寫同一塊內存了嗎這算不算零拷貝算也不完全算。shm_open拿到的是一塊普通匿名內存CPU可以直接訪問沒錯但NPU、VPU、RGA這些硬件模塊訪問內存需要內核驅動拿到這塊內存的物理地址信息把它映射進IOMMU或做DMA映射。普通共享內存沒有這個機制硬件不認。所以即便你用shm共享了一塊內存最后為了讓硬編碼器能讀這幀數(shù)據還是得把數(shù)據從shm內存拷貝到MPP分配的硬件可訪問buffer里白白多一次搬運。真正的方案是讓整條數(shù)據鏈路都建立在DMA-BUF之上。DMA-BUF導出的fd同時具備兩個能力用戶態(tài)可以mmap訪問硬件驅動也能通過它拿到物理內存的訪問權。RGA、VPU、NPU、ISP這些驅動全都認這個fd。這才是“零拷貝”跨進程通信的地基。2. 兩塊基石DMA-BUF 和 SCM_RIGHTS2.1 DMA-BUF 到底是什么為什么硬件都認它DMA-BUF是Linux內核里一個標準的buffer共享機制?？梢赃@樣理解一個DMA-BUF對象代表一塊“能被硬件訪問的物理內存”。它由某個exporter設備創(chuàng)建然后通過fd的形式把這塊內存的訪問權分享給其他設備或進程。每個拿到fd的進程都能通過mmap把同一塊物理內存映射到自己的虛擬地址空間每個硬件驅動也能從fd那里拿到內核態(tài)的sg_table完成DMA映射。打個比方DMA-BUF fd就像一張圖書館的借書卡。大家拿著同一張卡借同一本書而不是每次有人要看就去復印一份再遞過去。書只有一本放在圖書館固定的書架上誰借誰來看。在RK3588平臺上最常用的分配接口是DMA-BUF heaps。內核啟動后一般能看到這樣的節(jié)點ls /dev/dma_heap/常見的有system、system-uncached、linux,cma等。不同開發(fā)板、不同內核版本節(jié)點名會有差異有些老SDK還是用的/dev/ion。如果你想確認當前平臺支持哪些堆直接看這個目錄最靠譜。正點原子、香橙派這類開發(fā)板廠商的內核配置不太一樣節(jié)點名和權限都要以實際為準。2.2 RK3588上常見buffer來源攝像頭、MPP、自分配具體到一條邊緣AI視覺鏈路DMA-BUF fd通常有三個來源。第一個來源是攝像頭采集。Rockchip的rockit框架或者V4L2配合rkcif/rkisp驅動導出的采集buffer本身就是DMA-BUF fd。比如你通過V4L2申請一組用于采集的bufferVIDIOC_REQBUFS之后用VIDIOC_QUERYBUF拿到的fd就是可以傳給下游的DMA-BUF fd。第二個來源是MPP的編解碼buffer。用MPP做硬編碼或硬解時通過mpp_buffer_get拿到的buffer本質上也是基于DMA-BUF分配的可以通過mpp_buffer_get_fd把fd取出來傳給其他進程。第三個來源是自分配。你想要一塊不屬于任何采集或編碼器、純粹用于進程間共享的buffer時可以直接懟dma-heap#include fcntl.h #include sys/ioctl.h #include sys/mman.h #include unistd.h #include linux/dma-heap.h 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 {0}; data.len size; // 建議按4096向上對齊 data.fd_flags O_CLOEXEC | O_RDWR; if (ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, data) 0) { perror(DMA_HEAP_IOCTL_ALLOC); close(heap_fd); return -1; } close(heap_fd); int buffer_fd data.fd; void *ptr mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, buffer_fd, 0);這里有個點要提醒如果這塊內存主要是給硬件設備讀、CPU不經常碰優(yōu)先選uncached的堆如果進程本身要用CPU頻繁讀寫又希望硬件訪問時一致那就需要處理cache同步后面會單獨講。2.3 SCM_RIGHTS把fd“快遞”給另一個進程有了DMA-BUF fd下一個問題很直接fd只是一個整數(shù)這個整數(shù)在進程A里指向某塊buffer進程B里隨便傳一個數(shù)字過去內核可不會認為它有效因為每個進程的文件描述符表是獨立的。所以需要一種內核幫你“打開文件引用”的機制這就是Unix domain socket上的SCM_RIGHTS輔助消息。本質上是讓內核從發(fā)送進程的fd表里取出對應的struct file復制一份引用安裝到接收進程的fd表里然后返回一個新的fd整數(shù)給接收進程。發(fā)送方和接收方各自持有的fd指向同一個內核對象DMA-BUF引用計數(shù)會相應增加生命周期由雙方共同維護。發(fā)送端的核心代碼#include sys/socket.h #include sys/types.h void send_fd(int sockfd, int fd_to_send) { struct msghdr msg {0}; char buf[1] {F}; struct iovec io { .iov_base buf, .iov_len sizeof(buf), }; char cmsg_buf[CMSG_SPACE(sizeof(int))]; msg.msg_iov io; msg.msg_iovlen 1; msg.msg_control cmsg_buf; msg.msg_controllen sizeof(cmsg_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_to_send, sizeof(int)); if (sendmsg(sockfd, msg, 0) 0) { perror(sendmsg); } }接收端的核心代碼int recv_fd(int sockfd) { struct msghdr msg {0}; char buf[1]; struct iovec io { .iov_base buf, .iov_len sizeof(buf), }; char cmsg_buf[CMSG_SPACE(sizeof(int))]; msg.msg_iov io; msg.msg_iovlen 1; msg.msg_control cmsg_buf; msg.msg_controllen sizeof(cmsg_buf); if (recvmsg(sockfd, msg, 0) 0) { perror(recvmsg); return -1; } struct cmsghdr *cmsg CMSG_FIRSTHDR(msg); if (!cmsg || cmsg-cmsg_type ! SCM_RIGHTS) { return -1; } int received_fd; memcpy(received_fd, CMSG_DATA(cmsg), sizeof(int)); return received_fd; }注意SCM_RIGHTS要求socket必須是Unix domain socket也就是AF_UNIX本地回環(huán)TCP可不行。還有一點輔助數(shù)據必須伴隨著至少一個字節(jié)的普通數(shù)據一起發(fā)送也就是說msg_iov里不能真的為空。3. 動手實現(xiàn)一套可復用的零拷貝幀傳輸模塊3.1 總體設計預分配緩沖區(qū)池控制通道到了實際操作層面我并不建議誰需要哪個buffer就現(xiàn)場分配一個那會帶來兩個問題一是運行期頻繁分配和釋放DMA-BUF容易產生碎片二是在多進程、多路視頻并發(fā)時內存使用不可控。更穩(wěn)妥的做法是預分配一個緩沖區(qū)池。啟動階段一次性分配N塊固定大小的DMA-BUF整條生命周期內都別釋放等系統(tǒng)退出時統(tǒng)一清理。進程間傳輸?shù)钠鋵嵅皇恰皵?shù)據”而是一個“token”這個token里有buffer索引、frame_id、寬高、時間戳這些元信息再加上對應的DMA-BUF fd。緩沖區(qū)池的狀態(tài)管理可以設計成這樣的結構#define MAX_FRAME_BUFFERS 8 struct frame_buffer_desc { int fd; // 生產者持有的fd size_t size; // 緩沖區(qū)大小 uint64_t frame_id; // 幀序號 uint32_t width; uint32_t height; uint32_t stride; uint32_t format; int state; // 0空閑 1已填充待消費 2消費中 3可回收 uint64_t timestamp; };這個狀態(tài)數(shù)組可以放在一塊單獨的共享內存頁里進程之間通過原子變量或者簡單的一個自旋鎖來修改。實際項目中我用過兩種狀態(tài)同步方式。一種是“生產者不等消費者”的丟幀策略。生產者每幀都去找空閑buffer找不到就直接丟幀用最新幀覆蓋策略或跳過這一幀。這種方式采集進程永遠不會被阻塞適合對實時性要求高的場景代價是極端情況下會丟幀。另一種是“消費完成通知”的回收策略。消費者處理完一幀后通過socket或者共享狀態(tài)把buffer標記為空閑。生產者只有拿到空閑標記才能復用這塊內存。這樣能保證每幀都被完整處理代價是如果消費者處理太慢生產者會被拖住。我的建議是如果是視頻監(jiān)控這類流水線任務選丟幀策略更合理。寧可偶發(fā)丟幀也別讓采集線程卡死。3.2 生產者端分配、填充、發(fā)布生產者進程的任務是把采集到的一幀數(shù)據灌進DMA-BUF然后把fd和幀描述信息發(fā)出去。整套流程大概是啟動階段通過dma-heap分配一大塊buffer池按幀大小切分成N塊每塊對應一個fd然后mmap到自己的用戶態(tài)虛擬地址空間。每來一幀攝像頭數(shù)據從buffer池里挑一個空閑buffer。把圖像數(shù)據填進去。這里有個關鍵選擇如果采集buffer本身就是DMA-BUF fd最好的辦法是直接把采集buffer的fd發(fā)給下游連獨立buffer池都不需要。但實際工程中采集和AI往往需要解耦AI進程可能還要做格式轉換、多路幀緩存所以獨立pool更常見。填充動作可以用CPU memcpy也可以用RGA做硬件搬運。后者不占CPU是更“零拷貝”的做法。更新幀描述信息包括frame_id、寬高、時間戳。通過Unix domain socket把frame_id作為普通數(shù)據、fd作為輔助數(shù)據一起發(fā)送。發(fā)送消息時可以打包一個小的協(xié)議頭struct frame_msg { uint32_t buffer_index; uint32_t format; uint32_t width; uint32_t height; uint32_t stride; uint64_t frame_id; uint64_t timestamp; };然后發(fā)送時普通數(shù)據就是frame_msg輔助數(shù)據要附帶的fd就是當前buffer的fd。接收方拿到的fd和發(fā)送方的fd指向同一個DMA-BUF對象。3.3 消費者端接收、映射、使用、歸還消費者進程這邊的流程是在socket上recvmsg同時拿到frame_msg和繼承來的fd。檢查這個fd是否已經mmap過。如果進程里維護一個“fd到虛擬地址”的映射表發(fā)現(xiàn)同一個DMA-BUF已經映射過就直接復用地址不用反復mmap/munmap。這一步能省不少系統(tǒng)調用。拿到指針之后交給后續(xù)模塊。如果是AI進程就喂給RKNN如果是編碼進程就導入給MPP。處理完畢把buffer狀態(tài)標記為可回收或者通過socket回一個ack給生產者。消費者mmap的邏輯很簡單int received_fd recv_fd(sockfd); // 假設已經有buffer元信息 void *mapped mmap(NULL, frame_size, PROT_READ | PROT_WRITE, MAP_SHARED, received_fd, 0); if (mapped MAP_FAILED) { perror(mmap dma-buf in consumer); } // 使用 mapped 指向的圖像數(shù)據這里有個經驗如果buffer池是預分配的消費者最好也按“buffer索引”來緩存mmap結果。第一次收到某個索引的fd時map一次之后同一索引復用。這樣既省了mmap/munmap的開銷也避免了fd反復打開關閉帶來的引用計數(shù)管理混亂。3.4 與RKNN、RGA、MPP對接的關鍵接口零拷貝的價值只有在和硬件模塊對接時才真正體現(xiàn)出來。否則你就算用DMA-BUF傳了半天fd最后在AI進程里還是把數(shù)據memcpy到普通內存再喂給RKNN那就沒意義了。對接RKNN時核心思路是讓NPU直接訪問這塊DMA-BUF而不是經過用戶態(tài)指針中轉。RKNN SDK通常提供從外部fd創(chuàng)建內存的方法類似#include rknn_api.h rknn_tensor_mem *external_mem NULL; // fd 就是我們從socket里收到的DMA-BUF fd // virt_addr 是mmap后的虛擬地址size 是buffer大小 rknn_create_mem_from_fd(ctx, fd, virt_addr, size, external_mem);然后推理時把external_mem塞進輸入tensor的內存指針。這樣NPU做DMA讀取時直接訪問的是物理內存不需要CPU先把數(shù)據從某個用戶態(tài)地址拷貝到NPU可達的buffer。具體函數(shù)簽名會隨SDK版本略有差異但大方向就是這樣。對接RGA時RK的RGA庫librga或im2d支持直接導入fd做格式轉換和縮放。比如AI進程要把NV12轉成RGB同時縮放到模型輸入尺寸可以走RGA硬件#include im2d.h #include rga.h rga_buffer_t src wrapbuffer_fd_t(fd, width, height, RK_FORMAT_NV12); rga_buffer_t dst wrapbuffer_fd_t(dst_fd, dst_w, dst_h, RK_FORMAT_RGB888); imresize(src, dst);wrapbuffer_fd_t這種接口就是讓RGA驅動通過fd訪問源和目標內存整個過程CPU不參與像素搬運。對接MPP硬編碼時MPP也支持從外部fd導入buffer#include mpp_buffer.h MppBuffer enc_buf NULL; // fd 是共享的DMA-BUF fd mpp_buffer_import(NULL, enc_buf, fd);導入之后就能把這份buffer當普通MppBuffer喂給編碼通道。編碼出的H.264/H.265碼流拿去做RTSP推流這就是我們常說的“基于RK3588硬編碼的實時視頻監(jiān)控系統(tǒng)”。所以完整鏈路可以是這樣的采集進程輸出DMA-BUF fdNV12→ 零拷貝IPC傳給AI進程 → 通過rknn_create_mem_from_fd交給NPU跑YOLOv8 → 推理結果通過RGA畫框/轉格式 → 再把fd傳給編碼進程 →mpp_buffer_import導入MPP硬編碼 → 碼流走RTSP推出去。整個過程里CPU沒有參與任何一幀像素數(shù)據的搬移。4. 真實項目中的坑RK3588上最常踩的五個問題4.1 花屏、亂幀的深層原因cache一致性和對齊很多人第一次把跨進程零拷貝鏈路跑通后會看到畫面時而正常、時而花屏或者模型推理結果偶爾不對又查不出代碼邏輯漏洞。這種情況十有八九是cache一致性問題。如果生產者用CPU往一塊cached的DMA-BUF里寫數(shù)據寫完直接發(fā)給NPU或VPU硬件DMA讀取時可能拿到的是還沒寫回內存的臟cache數(shù)據。解決辦法有這么幾條一是分配buffer時直接用uncached堆例如/dev/dma_heap/system-uncached。代價是CPU訪問這塊內存的性能會明顯下降所以只適合“CPU不怎么碰數(shù)據”的鏈路。二是保留cached堆但在關鍵位置主動做sync。用戶態(tài)可以通過DMA_BUF_IOCTL_SYNC告訴內核在硬件訪問前把cache刷回內存struct dma_buf_sync sync {0}; sync.flags DMA_BUF_SYNC_START | DMA_BUF_SYNC_RW; ioctl(buffer_fd, DMA_BUF_IOCTL_SYNC, sync); // CPU 讀寫這塊 buffer sync.flags DMA_BUF_SYNC_END | DMA_BUF_SYNC_RW; ioctl(buffer_fd, DMA_BUF_IOCTL_SYNC, sync);三是讓整條鏈路盡量使用采集或MPP導出的buffer因為這些buffer在驅動層已經把同步處理好了用戶態(tài)不太需要操心。只有自己分配、自己用CPU填充時才需要注意這個坑。還有一類花屏和cache無關純粹是對齊問題。RGA、VPU、NPU對buffer的起始地址和大小都有對齊要求一般建議按2MB或1MB對齊至少也要按64字節(jié)對齊。分配時可以讓size ALIGN(frame_size, 4096)再用一個ALIGN_UP宏把所有寬高參數(shù)按硬件要求的stride對齊。4.2 幀串號和丟幀緩沖區(qū)復用管理另一個高頻問題是幀號錯亂?，F(xiàn)象是消費者收到的frame_id順序不對或者畫面內容是上一幀的時間戳卻是這一幀的。這多半是因為生產者把同一塊buffer發(fā)出去兩次或者消費者還在讀某塊buffer生產者就把它重新填充并再次發(fā)布了。解決思路很直接buffer狀態(tài)機必須嚴格?？臻ebuffer只能被生產者拿到消費者處理完必須顯式標記為可回收中間不能跳狀態(tài)。我踩過的一個坑是為了省事生產者發(fā)完fd就立刻把buffer狀態(tài)改成空閑結果消費者還沒讀完下一幀數(shù)據已經覆寫進來了。后來改成消費者處理完通過共享內存標記回收生產者只從“已回收”狀態(tài)的buffer里挑問題就消失了。4.3 fd生命周期和內存泄漏fd生命周期問題是零拷貝鏈路里隱藏最深的一類bug。SCM_RIGHTS傳遞fd后發(fā)送端和接收端各自都有一個fd指向同一個DMA-BUF。如果發(fā)送端在sendmsg之后直接close沒有別的影響因為接收端持有的fd已經增加了引用計數(shù)。但如果你兩邊都close了而mmap還在DMA-BUF仍然不會釋放因為mmap本身也持有引用。反過來說如果接收端用完fd直接close又忘了munmap就會內存泄漏。長時間運行的邊緣設備這種泄漏積累到最后會致命。我的建議是每個進程維護一張“buffer索引到虛擬地址”的映射表mmap一次后不隨便munmapfd在mmap成功后也可以立即close掉因為mmap已經持有引用。等整個會話結束統(tǒng)一munmap所有映射再統(tǒng)一close所有殘留fd。這樣管理起來清爽得多。4.4 內核沒有DMA-BUF節(jié)點或者權限被限制新版RK3588 SDK基本都支持/dev/dma_heap但有些老SDK或者定制內核只有/dev/ion或者兩個節(jié)點都沒有。拿到新板子第一件事就是檢查這些節(jié)點ls -l /dev/dma_heap/ 2/dev/null || ls -l /dev/ion 2/dev/null如果節(jié)點不存在大概率是內核配置里沒開CONFIG_DMABUF_HEAPS或者DTS里沒有使能對應的heap。這時候要么改內核配置重新編譯要么就只能退回MPP的mpp_buffer_get這類封裝接口。如果改完內核發(fā)現(xiàn)系統(tǒng)起不來也別糾結RK3588開發(fā)板刷機很快recovery或maskrom模式下用USB Type-C連電腦就能裝回來。還有權限問題。容器化部署邊緣盒子時/dev/dma_heap下的節(jié)點不會自動映射進容器必須在docker run時手動加--device /dev/dma_heap:/dev/dma_heap否則容器里open必然失敗。4.5 常見錯誤速查表現(xiàn)象可能原因排查方向另一進程mmap返回EPERM或ENOMEMfd不是真實DMA-BUF fd或權限不夠檢查SCM_RIGHTS是否真正傳成功確認socket是AF_UNIX檢查容器device映射RGA調用返回錯誤碼buffer地址或stride未對齊格式不支持分配時按64字節(jié)或更大對齊確認RGA版本支持目標格式VPU編碼畫面花屏cache未同步或stride設置和buffer實際寬度不一致加DMA_BUF_IOCTL_SYNC核對stride和width關系RKNN輸入無效或推理異常外部fd創(chuàng)建內存失敗或buffer是cached且未同步用rknn_create_mem_from_fd前確認fd可用uncached優(yōu)先幀號亂序、畫面內容錯幀buffer被過早復用狀態(tài)機不嚴嚴格“空閑→填充→發(fā)布→消費→回收”流程內存持續(xù)上漲mmap或fd未釋放用cat /proc/pid/smaps檢查映射區(qū)間清點每個buffer的映射生命周期8K或4K多路時分配失敗內存池過大或heap碎片化減小緩沖池深度或改用CMA堆5. 效果評估和性能對比這套方案到底值不值得上最后說點實際的。零拷貝跨進程通信聽起來很酷但它不是銀彈它解決的是“大塊圖像數(shù)據在進程間頻繁傳輸”這個特定問題。如果你的應用只是偶爾傳一些小的結構化數(shù)據用它反而復雜了。我整理了兩種方案的粗略對比數(shù)據來自我們RK3588板卡上的實測不同板卡、不同內存頻率會有差異思路比數(shù)值更重要。項目傳統(tǒng)socket傳整幀DMA-BUF零拷貝傳fd一幀1080p NV12傳輸額外耗時2至4ms左右含內核拷貝和用戶態(tài)拷貝小于0.1ms只傳元信息和fdCPU占用每次拷貝都會占用A76核心幾乎為零硬件DMA直讀是否適合多路視頻4路以上CPU占用吃緊多路時依然能保持低CPU負載實現(xiàn)復雜度簡單但低效需要設計buffer池和狀態(tài)機和RKNN/MPP/RGA對接需要額外拷貝到硬件可訪問buffer直接導fd無縫對接如果你跑的是單路1080p30fps的簡單demo傳統(tǒng)socket方式也許夠用CPU多花幾個點沒什么感覺。但一旦跨到4路1080p或者4K60fps拷貝開銷會成倍放大這時零拷貝就不是優(yōu)化項而是剛需。就算自身業(yè)務暫時用不到多進程我個人也建議在RK3588上做視覺方案時一開始就把幀傳輸通路設計成基于DMA-BUF的形式。后面無論是想把AI推理獨立成進程、還是加一路硬編碼推流改動都會小很多不至于推倒重來。這也是我在RK3588架構上做邊緣AI視覺項目后期體會最深的一點數(shù)據通路的設計比一開始用的模型大小、算力預算更值得花時間提前規(guī)劃。