15.1 ION/DMA-BUF框架內(nèi)存分配的基石先講ION。這是Android系統(tǒng)里統(tǒng)一的內(nèi)存分配器專門給多媒體、顯示、相機這些模塊用的。為什么需要ION因為顯示驅(qū)動需要的內(nèi)存不是普通的內(nèi)存。它需要連續(xù)物理內(nèi)存或者至少是IOMMU映射好的內(nèi)存還要支持跨進程共享。你想想看應(yīng)用層畫了一幀畫面要傳給SurfaceFlinger合成再送到顯示硬件——這中間要跨多少道進程ION的核心概念就是「Heap」。每個Heap代表一種內(nèi)存類型Heap類型用途特點ION_HEAP_TYPE_SYSTEM普通系統(tǒng)內(nèi)存非連續(xù)速度一般ION_HEAP_TYPE_SYSTEM_CONTIG連續(xù)物理內(nèi)存用于顯示控制器直接訪問ION_HEAP_TYPE_CARVEOUT預(yù)留內(nèi)存固定大小不參與頁回收ION_HEAP_TYPE_CHUNK分塊內(nèi)存MTK平臺常用兼顧連續(xù)性和靈活性我在MTK8678上調(diào)試時遇到過一個問題用SYSTEM_HEAP分配顯示緩沖區(qū)結(jié)果畫面偶爾出現(xiàn)條紋。查了半天發(fā)現(xiàn)是內(nèi)存不連續(xù)導(dǎo)致DMA傳輸出錯。后來換成SYSTEM_CONTIG_HEAP問題就解決了。關(guān)鍵點顯示緩沖區(qū)必須使用物理連續(xù)內(nèi)存或者通過IOMMU映射成連續(xù)的虛擬地址空間。DMA-BUF是ION的底層機制。它本質(zhì)上是一個文件描述符代表一塊可以跨設(shè)備、跨進程共享的內(nèi)存。ION分配的內(nèi)存最終都會導(dǎo)出為一個DMA-BUF fd。// ION分配內(nèi)存示例 struct ion_allocation_data alloc_data { .len buffer_size, .heap_id_mask 1 ION_HEAP_TYPE_SYSTEM_CONTIG, .flags ION_FLAG_CACHED, }; int ret ioctl(ion_fd, ION_IOC_ALLOC, alloc_data); // 獲取DMA-BUF fd int dma_buf_fd alloc_data.fd;嗯這里要注意ION的API在較新內(nèi)核中已經(jīng)被DMA-BUF Heaps替代了。但MTK平臺為了兼容性內(nèi)部還是保留了ION的接口封裝。你看到代碼里還有ION相關(guān)的調(diào)用別奇怪。15.2 GraphicBuffer分配從應(yīng)用到驅(qū)動的橋梁GraphicBuffer是Android上層對ION/DMA-BUF的封裝。應(yīng)用層畫圖時不會直接調(diào)ION接口而是通過GraphicBufferAllocator來申請。它的分配流程是這樣的應(yīng)用調(diào)用ANativeWindow::dequeueBuffer()SurfaceFlinger通過BufferQueue向GraphicBufferAllocator請求bufferGraphicBufferAllocator調(diào)用ION分配內(nèi)存ION返回DMA-BUF fd封裝成GraphicBuffer對象GraphicBuffer通過Binder跨進程傳遞給應(yīng)用我個人習(xí)慣在調(diào)試時先確認(rèn)GraphicBuffer的格式和尺寸是否正確。MTK8678支持多種像素格式比如RGBA_8888、RGBX_8888、NV12等。如果格式不匹配顯示硬件會直接罷工。調(diào)試技巧在dumpsys SurfaceFlinger的輸出中可以看到每個Layer的buffer信息。重點關(guān)注buffer的width、height、format和usage flags。GraphicBuffer還有一個重要屬性叫usage flags。它告訴ION這塊內(nèi)存要用來做什么GRALLOC_USAGE_HW_RENDER給GPU渲染用GRALLOC_USAGE_HW_COMPOSER給顯示合成器用GRALLOC_USAGE_HW_VIDEO_ENCODER給視頻編碼器用GRALLOC_USAGE_SW_READ_OFTENCPU頻繁讀取這些flags會影響內(nèi)存的cache策略和物理位置。比如HW_COMPOSER通常要求uncached內(nèi)存因為顯示控制器不經(jīng)過CPU cache。15.3 Fence同步機制別讓畫面撕裂多屏顯示最頭疼的問題是什么同步。你想想看GPU在渲染第N幀顯示控制器在讀取第N-1幀如果兩者同時操作同一塊buffer畫面就會撕裂。Fence就是用來解決這個問題的。它本質(zhì)上是一個內(nèi)核態(tài)的同步原語用文件描述符表示。Fence有兩種狀態(tài)signaled操作已完成可以安全使用bufferunsignaled操作還在進行中別碰buffer典型的同步流程是這樣的GPU開始渲染buffer A創(chuàng)建一個release fenceGPU渲染完成后signal這個fence顯示控制器等待這個fence signaled后才開始讀取buffer A顯示控制器讀取完成后創(chuàng)建另一個release fenceGPU等待這個fence才能把新數(shù)據(jù)寫入buffer A我曾經(jīng)在MTK8678上遇到一個詭異的問題雙屏顯示時副屏偶爾卡住不動。查了三天發(fā)現(xiàn)是Fence超時導(dǎo)致的。主屏的release fence一直沒signal副屏的acquire fence等不到就卡死了。避坑指南我曾經(jīng)因為Fence超時時間設(shè)置太短導(dǎo)致正常操作也被誤判為超時。建議把超時時間設(shè)為5秒以上調(diào)試階段甚至可以設(shè)到10秒。在代碼層面Fence的操作主要通過sync_file接口// 創(chuàng)建fence int fence_fd sync_file_create(gpu_render_fence); // 等待fence struct sync_fence_info_data *info; int ret ioctl(fence_fd, SYNC_IOC_FENCE_INFO, info); // 合并多個fence int merged_fd sync_file_merge(merged_fence, fence1_fd, fence2_fd);15.4 BufferQueue生產(chǎn)者-消費者模型BufferQueue是Android顯示系統(tǒng)的核心數(shù)據(jù)結(jié)構(gòu)。它實現(xiàn)了生產(chǎn)者-消費者模型讓應(yīng)用生產(chǎn)者和SurfaceFlinger消費者能高效地交換buffer。BufferQueue的核心成員成員作用mSlots[]存儲所有buffer的數(shù)組默認(rèn)64個slotmQueue已填充好的buffer隊列等待消費者處理mFreeSlots空閑slot列表mActiveBuffers當(dāng)前正在被生產(chǎn)或消費的buffer它的工作流程說白了就是三個操作dequeueBuffer生產(chǎn)者申請一個空閑bufferqueueBuffer生產(chǎn)者把填充好的buffer放入隊列acquireBuffer消費者從隊列取出bufferreleaseBuffer消費者用完buffer后歸還多屏場景下每個顯示設(shè)備都有自己的BufferQueue。MTK8678支持三個屏幕同時顯示那就需要三個獨立的BufferQueue實例。這里有個坑BufferQueue的深度即mQueue中最多能放幾個buffer會影響延遲。深度太小生產(chǎn)者容易阻塞深度太大畫面延遲會增加。我一般建議設(shè)成2或3兼顧流暢度和延遲。核心要點BufferQueue Fence ION這三者配合構(gòu)成了Android顯示系統(tǒng)的完整數(shù)據(jù)通路。ION負(fù)責(zé)「在哪里放數(shù)據(jù)」Fence負(fù)責(zé)「什么時候可以動數(shù)據(jù)」BufferQueue負(fù)責(zé)「數(shù)據(jù)怎么流轉(zhuǎn)」。15.5 實戰(zhàn)經(jīng)驗多屏顯示的內(nèi)存優(yōu)化最后分享一個我在MTK8678項目中的優(yōu)化經(jīng)驗。當(dāng)時客戶要求三屏同時顯示1080p視頻每個屏幕60fps。算一下1920×1080×4字節(jié)×3屏×60fps ≈ 1.5GB/s的帶寬。這還沒算GPU和CPU的訪問。內(nèi)存帶寬很快就成了瓶頸。我做了幾件事使用AFBC壓縮ARM的幀緩沖壓縮技術(shù)可以減少30%-50%的帶寬調(diào)整ION heap分配策略把顯示buffer放在專用的carveout內(nèi)存里避免和系統(tǒng)內(nèi)存爭搶優(yōu)化Fence等待邏輯減少不必要的同步等待讓流水線更緊湊BufferQueue深度調(diào)優(yōu)從默認(rèn)的1改成2讓GPU和顯示控制器能并行工作優(yōu)化后帶寬占用降到了800MB/s左右三屏播放流暢無卡頓。嗯這一章的內(nèi)容就到這里。緩沖區(qū)管理是顯示驅(qū)動的核心也是問題最多的地方。建議你在實際調(diào)試時先從ION分配開始排查再看Fence同步最后檢查BufferQueue的狀態(tài)。按這個順序來能省不少時間。