最近在面試的時候發現移動端現在是越來越熱，然后就有被問到GPU的框架什么的PC端的這個可以參考這個：GPU硬件架構及其運行機制移動端的與PC端有很大的區別！比如移動端可以說沒有獨立的顯存只有些寄存器cache 和on-chip memory！

立即渲染模式IMR ：

IMR（Immediate Mode Rendering）就如字面意思一樣——提交的每個渲染要求都會立即開始，這是一種簡單而又粗暴的思路，優點缺點都非常明顯，如果不用為性能擔憂，這種方式會很省事，但是IMR的渲染實行的是無差別對待，那些遮蔽處理的部分依然會被渲染處理器，這也導致無意義的讀寫操作更多，浪費了大量性能和帶寬。
對于每一個具體的繪制，渲染管線里的讀寫操作都是直接在顯存和GPU中傳輸數據的， 在這種架構下，每一次渲染完的Color和Depth數據寫回到Frame Buffer和 Depth Buffer都會產生很大的帶寬消耗，所以IMR架構中也會有L1和L2之類的Cache來優化這部分大量的帶寬消耗。

移動端分塊渲染TBR模式：

GPU的渲染過程中，對功耗影響最大的是帶寬，所以能夠怎么樣從設計層面減少帶寬消耗，也就延申出TBR！
之前的OpenGL ES規范中CPU和GPU之間的內存是不能共享的，Vertex和Texture的Buffer是需要拷貝的，即使是在同一物理內存上。現在有了vulkan，openGL和openGL ES可以和CPU之間共享內存了，不用象以前那樣拷貝來拷貝去了，當然vulkan還有其他很有用的特性。
在異構計算方面，之前也是需要在CPU和GPU之間拷貝kernel的輸入數據和輸出結果，在OpenCL 2.0之后，也和vulkan一起走上了共享內存的康莊大道了。當然Metal也是可以共享內存的。
對于TBR來講，整個光柵化和像素處理會被分為一個個Tile進行處理，通常為16×16大小的Tile。TBR的結構通過On-Chip Buffers來儲存Tiling后的Depth Buffer和Color buffer。

在TBR的架構里，并不是來一個繪制就執行一個的，因為任何一個繪制都可能影響到到整個FrameBuffer，如果來一個畫一個，那么GPU可能會在每一個繪制上都來回運輸所有的Tile，這太慢了。
所以TBR一般的實現策略是對于Cpu過來的繪制，只對他們做頂點處理，產生的結果（Frame Data）暫時寫回到物理內存，等到非得刷新整個FrameBuffer的時候，比如說在代碼里顯示的執行GLFlush，GLFinish，Bind和Unbind FrameBuffer這類操作的時候，總之就是我告訴GPU現在我就需要用到FrameBuffer上數據的時候，GPU才知道拖不了了，就會將這批繪制做光柵化，做tile-based-rendering。
讀取只發生在需要幾何以及紋理信息的時候，寫回也只發生在整批繪制畫完的時候，具體的繪制都是在On_Chip Memory上完成的，也就是帶寬消耗最大的DepthBuffer 和 ColorBuffer的讀寫都發生在On_Chip Memory上

延遲渲染TBDR模式：

TBR雖然比IMR聰明多了，不過還是存在不少缺陷，TBDR（Tile Based Deferred Rendering，貼圖延遲渲染）閃亮登場，它跟TBR原理相似，但是使用的是延遲渲染（Deferred Rendering），合并了完美像素，通過HSR（Hidden Surface Removal，隱藏面消除）等進一步減少了不需要渲染的過程，降低了帶寬需求。實際上這些改變和PC上的渲染有些相似。
其實TBDR與TBR就是 在TBR的基礎上再加了一個Deferred。

總結：

作為一個即寫過GPU c-model，又調過shader unit驅動的前前前前 架構師，我認為，IMR不關注成本（即不關注效率），反復overdraw也無所謂，只求峰值性能大，把晶圓面積都給shader unit，犧牲效率 ，換得峰值性能，以及通過將shader unit數量最大化 換得更好的gpgpu向量計算通用性。

而TBR是最關注成本（最關注能效比），不追求峰值性能，但求最少的帶寬 功耗使用量，追求的是最高效率。把晶圓面積都給片上幀緩沖，說白了就是放棄通用性和峰值性能，只針對圖形渲染優化效率。所以你看很多游戲機GPU都是TBR的，為什么？說白了，就是為了效能比，追求效率。

參考資料：

tbr管線
GPU硬件架構及其運行機制
Metal圖形處理前

總結

以上是生活随笔為你收集整理的移动端GPGPU 架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。