众所周知,Tile Based Rendering已经成为了事实上的移动平台GPU标配,不只如此,intel的新一代集成显卡也悄悄地加上这一特性的支持。移动平台GPU御三家(Adreno,Mali,PowerVR)也在本身的解决方案里,纷纷加上了本身的私货,不只可以优化性能,若是被标准化组织(Khronos)看上了列为下一代API的标配,又能够在市场竞争中多一份筹码。下面介绍Mali-GPU提供的一些独有特性。算法
在一个Render Pass中,每个Tile中的每一个像素可能会被绘制屡次,由此带来的Overdraw问题不可忽视。一般的作法是采起对模型的渲染顺序进行排序,按照Opaque:从近到远,Transparent:从远到近来进行,这样能够充分利用Early-Z进行剔除。可是这样的作法要求很高,通常很难作到完美。Mali的作法是,若是每一个Pixel会被渲染屡次(假设都是Opaque),那么将其放入一个队列中,不会立刻进行Fragment计算,若是后进入的Fragment深度比队列中前面的要小(假设ZTest为Less),那么前面的将会被抛弃掉。缓存
和PowerVT的HSV(Hidden Surface Removal)相比,这个方案存在必定的剔除不干净的可能(队列中的Fragment已经被处理了),可是其实现起来简单,若是不生效,队列就退化成正常渲染所用的队列。不过Mali推荐仍是使用排序的方式以充分进行Overdraw剔除。ide
Transaction Elimination也是一种颇有效的下降带宽的方法。在有些状况下,只有部分Tile中的内容会变化(例如摄像机不动,一个Tile中只有静态物体)。此时经过比较该Tile前一次和本次的渲染结果的CRC值,可获得Tile是否变化的结论,若是不变,那么就没有必要执行Tile到System Memory的写回操做了,有效地下降了带宽占用。性能
FrameBuffer中的内容,以无损的压缩格式存储,不只下降了传输带宽,还下降了显存占用,是一种用时间换空间/带宽的技术(这个技术貌似AMD的显卡也用了)。优化
然而这种技术有必定的局限性,若是Texture仅做为FrameBuffer的Color Output和Shader中使用texture()进行读取,那是没问题的,可若是使用了imageLoad和imageStore方法,驱动就是隐式地插入一个解压缩的步骤。这样反而形成了更多地存储占用和更多地计算负担。ui
从上面的描述能够看出,这种算法多是一种基于块的压缩算法,若是使用texture()去读,会去走texture缓存那条读取通道,这条通道上原本就有各类压缩格式的解压缩算法,再加一种也不是什么事。而imageLoad和imageStore走的是另外一条通用的存储读写通道,这条通道若是想加上on the fly的压缩/解压缩,看上去不是很现实。spa
目前也没有扩展进行显式的控制(待查证),若是一个Texture被做为FrameBuffer的Color Output写入以后立刻被Compute Shader用到了,那不是还得解压缩一份?这个问题有待实验考证。排序
参考资料:队列