移动端GPGPU 架构

最近在面试的时候发现移动端现在是越来越热，然后就有被问到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图形处理前