首先再来回顾下Copybit的接口函数,虽然简单,但功能一个都不少。
Copybit模块主要使用的硬件加速功能有:
bitBlit
Stretch
Rotate
Alpha blending
Color Transform
1、bit blit和stretch的实现
strctch并没有特殊去实现,因为所有的坐标数据都是Android的Surface和OpenGL ES层传下来的,主要还是实现bit blit,即块拷贝。
Android上层,主要是SurfaceFlinger,维护着几块重要的图形缓冲区。
这些图形缓冲区是通过Gralloc模块申请到的PMEM空间,因此都可以获取物理地址,提供给2D加速引擎。
为什么只有几片缓冲区呢?我估计800x480的屏幕大约只要10MB的PMEM空间即可,这么点的数据,如果连续传给LCD,肯定是不够的。
因此Android采用了部分更新策略,只更新屏幕是需要改变的部分,这一点很适合2D引擎,因为引擎可以只把改变的数据刷到屏幕上。
Copybit的上层会传递两个参数,一个是当前缓冲(屏幕)的总大小,比如800x480,另外是需要更新的窗口大小(x,y,w,h)。
最后需要注意,将数据提供给S3C6410的blit引擎前,需要区分src和dst的数据是什么(fb或者pmem),如果是fb,传递fb基址,否则传递pmem物理地址。
2、Rotate实现
Rotate很简单,坐标数据上层基本做好了,刷新矩形框可以直接使用msm模块的set_rects,配置下2D引擎的选择模式即可。
3、Alpha blending实现
Alpha有两种模式,一种是全屏Alpha数值,另外一种是Android提供的RGBA数据进行Alpha渲染。
第一种比较简单,如果发现有全屏Alpha值,配置AMB寄存器为刷新全屏alpha,并填上alpha数据,不过我因为三星0值为0x0,而上层为0xff,所以需要做下转换,不过全屏alpha的机会很少,看不出。
第二种就是RGBA8888数据中带有alpha值,这种情况较多,主要体现在界面上。
Android的界面基本是贴两层数据,一层为背景图片(RGB565),另外一层为图标(RGBA8888)。
一开始我无论如何配置,屏幕上背景都是黑色,郁闷了很长时间后才发现需要配置AMB寄存器为alpha with bitmap模式,但是驱动里面并没有写。。。。。。
4、Color Format Transform
颜色格式转换,因为screen是RGB565的,如果刷来RGBA8888数据,肯定要进行颜色格式转换,这块2D引擎肯定有支持。
可是,开始配置RGBA8888转RGB565时,发现屏幕是红色的?
调试了很长时间,发现Google Android的RGBA8888竟然是大印第安序的,也就是对应ARM的ABGR8888,这种颜色三星貌似不支持。
手动将颜色配置为ARGB8888,发现白色正常,绿色和蓝色反了呵呵,于是写了一个颜色格式软换的函数:
daddr[i] = ((saddr[i]) & 0xFF00FF00) | (((saddr[i])&0xFF)<<16) | (((saddr[i]) & 0xFF0000)>>16);
结果这个函数让界面的效果有所减低,为了这个转换我还用了另外一块PMEM。
昨天看三星Android1.5的内核驱动代码,竟然发现三星操作了一个数据手册没有的地址(0x350)omg
在网上一搜,有的头文件将其标记位印第安序转换寄存器,顿时欣喜若狂,这样就支持ABGR颜色格式了,不用软件转换了!
试过之后,果然有用,流畅感大升,三星你果然还留了一手啊,或许我看的数据手册太老了。
5、Cache的一致性问题
因为PMEM分配的内存上层也要使用,如果不能被cache,性能会有损失。
但是6410的cache是write back的,也就是不同步在内存中跟新。
这样会导致如果图像缓寸数据被cache了,屏幕上会出现一些细小的颜色错误。
目前的解决方法是启动2D引擎前flush下cache,不知道能够将cache配置为wirte through,哪个性能损失小呢?
Rockie Cheng
阅读(790) | 评论(0) | 转发(0) |