硬件加速：用起来很美

发表于 2010/8/26 9:35:33 阅读（2432）

其实在硬件加速方面，特权同学早想写一篇博文，只是苦于没有合适的对比题材。赶上最近的一个系统平台，整个SOPC，完全自己DIY外设系统，所以很大程度上会去考量外设到底是作为硬件外设、还是软件模拟外设，抑或是软硬兼施。在《图片显示速度测试报告》的博文中展现了相当让人无法忍受的软件运行效率，因此，系统必须优化，优化的最好途径就是用硬件来加速。那么，下文就有文章可做了。

也正好昨天的FTF展示了一款叫做Killer的游戏硬件加速引擎，给特权同学留下了较为深刻的印象。在广告片中，用了两个相同游戏界面作为对比，一个是基于通常的PC平台，另一个则是在原有PC平台上加入了这款游戏硬件加速引擎Killer（估计是一个PCI外设吧，相当于给用户加了一个优化系统显示性能的“显卡”）。先说个题外话，特权同学对游戏不是很在行，不过还记得大学时候比较痴迷的一款NBA live的游戏，由于显卡不堪重负，玩久了，在比赛中就经常卡死。一个很经典的界面：两个球员一前一后，通常是你跑一步，我跑一步，两个球员的“慢速跑动”镜头把CPU的顺序工作机制“穿帮”了。好，回到原话题，在广告游戏中的普通游戏界面里两个人的走动就好似前面的“穿帮”镜头一前一后；而有 Killer的平台里两个人则非常协调的看上去“很美”的并行跑动。我想，Killer带来的就是一种纯粹硬件的加速，我不知道那两个人是否真正的在并行工作。因为，在视频面前，人眼是靠不住的。但有，一点是可以确定的：硬件加速不仅看上去很美，而且用起来也很美。

如果说广告片中Killer有搀水分之嫌，不能让各位看官信服，那么下面特权同学就要用数据和波形来证实这一点：硬件加速确实很美！

使用以下程序测试一幅图片的显示速度。

IOWR_ALTERA_AVALON_PIO_DATA(PIO_LED_BASE,0x00); //LED OFF

Flash_photo_display(0,0); //送第0幅图片

IOWR_ALTERA_AVALON_PIO_DATA(PIO_LED_BASE,0xff); //LED ON

用示波器观察LED管脚输出的低脉冲时间，即可得出显示一幅图片运行的时间。

在特权同学的《图片显示速度测试报告》一文中有一段简单的遍历坐标地址清屏程序：

for(y=0;y<480;y++)

{

for(x=0;x<800;x++)

{

//送显示数据

IOWR_16DIRECT(MCULCD_CTRL_0_BASE,((y<<11)+(x<<1)),0x001f);

}

上面这段程序执行的LED低脉冲情况如图1所示，这个清屏的时间大约需要575ms。《图片显示速度测试报告》一文中已经提到了，这个显示的大部分时间是消耗在了软件变量的变化读写时间上，纯粹硬件接口层（显示控制器外设）的写时间（46ms）占的比例很小。因此软件程序或者说处理器性能将是优化的重点。

图1

图2是在图1基础上，读FLASH中预存储的一幅图片，然后逐个像素点的送一幅图片给显示控制器所耗费的时间。这幅图片的显示大约要1.6s，用户如果看着这样一幅图片慢慢的至上而下显示出来，感觉可想而知。优化势在必行。

图2

先不说如何优化，先看结果。如图3所示。优化后一幅图片的显示只需要70ms左右，基本已经接近了理论的最短时间46ms。呵呵，其实对于优化后的系统来说，理论的最短时间其实已经不是46ms了，要远比这个值小。WHY？不卖关子了，后面要步入正题：因为，硬件加速了！

图3

粗略的算一下从FLASH读一整幅图片的理论最短时间：

(25us+25ns*2048byte)*375page = 28.575ms。

而实际上在硬件层度FLASH每个字节的周期是100ns，那么理论时间应该是：

(25us+80ns*2048byte)*375page = 70.815ms。

那么实际上，我们在硬件优化后显示一幅图片的时间完全取决于硬件外设本身，基本和软件以及处理器性能没有关系了。硬件加速真的这么神吗？真的这么管用吗？在这个测试中，特权同学也很震撼，平时我们不仅高估了软件（抑或说是处理器）的性能，而且大大低估了硬件的性能。在这一点上，我想会让我今后对手中的FPGA更有信心。

最后，简单的说一下这个硬件加速系统是如何工作的。如图4所示，是这个系统优化之前的一个简单系统架构，FLASH的读写控制完全交给了CPU，而CPU的每次执行都是依赖于RAM上的程序和变量的，然后CPU还需要把读出来的数据送给LCD Controller。