首先再来回顾下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
阅读(782) | 评论(0) | 转发(0) |
