双buffer与单buffer

在嵌入式平台Linux，主要通过framebuffer来显示UI。FrameBuffer实际上就是嵌入式系统中专门为GPU所保留的一块连续的物理内存，LED通过专门的总线从framebuffer读取数据，显示到屏幕上。

根据系统中framebuffer的数量，可以分成单buffer和双buffer两种。

       先来说说单buffer：

       CPU往framebuffer上写，LED从framebuffer读，这是两个同时进行的过程，需要在时间上配合，否则会出现问题。

       如果CPU往framebuffer上写的速度>LED从framebuffer读的速度，那么就有可能出现LED在一行一行的读取前一屏数据的时候，CPU却已经刷新了整屏，从而导致显示混乱。这里要注意，LED从framebuffer读的速度并不等于屏幕的刷新频率，如果刷新频率为60hz，那么很有可能LED花了3个ms去读，剩余的时间都在等待。应该说CPU往framebuffer写的速度>LED从framebuffer读的速度还是很困难的。

       如果CPU往framebuffer写的速度太慢，也会出现屏幕闪烁的问题。比如说要画一幅图，CPU首先将其填充为白色，这时LED刷新，屏幕显示为白色，之后开始画完其他内容，屏幕正常显示。这时给用户的感觉就是屏幕一闪。这就要求CPU尽快的画完一屏，尽量保证写一屏不要跨越LED刷新周期。

       因此，在单framebuffer的时代，为了防止屏幕出现闪烁，我们一般是在内存中开辟一块与framebuffer同样大小的内容，将屏幕的内容都写好，然后再执行一次内存拷贝。从而使写framebuffer的时间尽可能的短。

       但这种机制有问题，我以屏幕分辩率为320*240为例。

       一块framebuffer的大小为:320*240*4=0.3072M。

       也就是说，我要先在内存中填写0.3M的内存，然后再把这块内存拷贝到framebuffer中。为了简单起见，这里我举一个将屏幕置为白色的例子，排除屏幕内容计算的影响。

       显示的实际过程为，将内存中0.3M置为0，然后读取这0.3M的内存，拷贝到Framebuffer中。

       在我使用的嵌入式平台中，采用的是SDRAM，532Mhz的ARM11芯片。通过使用lmbench得到内存访问的速率为：

*Local* Communication bandwidths in MB/s - bigger is better

-----------------------------------------------------------

Host           OS  Pipe AF    TCP  File     Mmap  Bcopy  Bcopy  Mem   Mem

                          UNIX      reread   reread (libc) (hand) read write

--------- ------------- ---- ---- ---- ------ ------ -------- ---- -----

phone  Linux 2.6 79.1 94.7 13.3  47.1    135.9   78.6   77.8  135. 205.9

很奇怪，为什么读会比写慢，可能与cache有关，这里先不用去管它。

下面我来计算单buffer所使用的时间。

       将0.3M内存置为0：0.3072×1000/200=1.5ms。

       读0.3M内存：0.3072×1000/135=2.7ms

       将03M内存写到framebuffer：0：0.3072×1000/200=1.5ms。

总共时间为5.7ms。实际的传输情况要比这个多，因为还要涉及循环的开销。

5.7ms看起来还行。

当屏幕分辨率变大时，情况就不一样了。如果屏幕的分辨率扩大为800*600，那么其数据量将是320*240的6.25倍。那么单纯的显示一个白屏的时间，将为5.7*6.25=36.6ms，也就是说如果只是显示白屏的话，我们也最多显示30帧，这个时间实在是太长了。

       并且如果我们只计算从内存拷贝到framebuffer的时间，其为 （2.7+1.5）*6.25=25.25ms。如何LED刷新频率为60hz，那么刷新一屏的时间将为18ms，这样即使单纯的从内存拷贝到framebuffer，写一屏的时间也大于LED的刷新频率，肯定会造成屏幕的闪烁。

       单buffer的另外一个问题在于，其每次都要进行内存拷贝，这样其会重新刷新CPU中的数据cache，对软件的性能有不利的影响。

 

性能的改善：

       从软件的角度来讲，每次尽量缩小刷新的区域，减少内存的传输。

       从硬件角度来讲，采用更高的CPU，采用更快的DDR内存，提高内存的吞吐率。

      

下面再来说下双buffer。

双buffer的好处在于，在LED显示当前framebuffer时，软件可以直接向后台的framebuffer写，在写完之后只是两个buffer做下切换即可，不再需要内存拷贝，从而提高效率。

还是以显示一个320×240的白屏为例，其过程变成：

1、  直接向后面的framebuffer写，其花费时间为0.3072×1000/200=1.5ms。

2、  写完之后framebffer切换，这个时间可以忽略不计。

那么当屏幕变为800×600时，其所花费的时间为1.5*6.25=9.375，要比单buffer的效率提高2.6倍。

并且双buffer还有一个好处，由于其没有了内存拷贝的环节，其对数据cache的影响较小，对于提高软件性能有利。另外给framebuffer的数据置位，其必然要经过Cache，由于这些数据写完后不再使用，那么使用写透cache要比使用回写式cache效率高。

 

双buffer还有一个好处，就是可以利用GPU的硬加速。如果要利用GPU的硬加速，则显示的数据必须是在预留的物理内存中，这在单buffer机制中是不能实现的。

 

双buffer也有一个致命的弱点：那就是局部刷新。

在单buffer的情况下，很容易实现局部刷新，只需要把局部的数据拷贝到对应的位置就可以了。而双buffer来讲，如果要实现局部刷新，则必须先将当前显示的buffer数据拷贝到后面的buffer，然后再做局部刷新。这样对于双buffer的设备来讲，刷新整屏的效率要比局部刷新更高。

 

局部刷新的理想情况：

将局部要修改的数据，直接写到另外一个显存中，与前buffer做叠加。

 

应该说单buffer和双buffer各有擅长，关键在于如何灵活运用。

 

直写式（write through），也叫写透，即CPU在向Cache写入数据的同时，也把数据写入主存以保证Cache和主存中相应单元数据的一致性，其特点是简单可靠，但由于CPU每次更新时都要对主存写入，速度必然受影响。

回写式（write back），即CPU只向Cache写入，并用标记加以注明，直到Cache中被写过的块要被进入的信息块取代时，才一次性写入主存。这种方式考虑到写入的往往是中间结果，每次写入主存速度慢而且不必要。其特点是速度快，避免了不必要的冗余写操作，但结构上较复杂。

直写式和回写式有着截然不同的操作，在不同的场合，不同的内存块使用不同的回写策略（如果你的系统可以实现的话）要比使用一种策略要高效得多。具体一点，对于反复存取的内存块置成写回，而把一次写入而很长时间以后再使用的内存置为写透，可以大大提高Cache的效率。

第一点很容易理解，第二点就需要琢磨一下了，由于写透的操作是，当缓存有该地址的数据时同时更新缓存和主存，当缓存没有该地址数据直接写主存，忽略缓存。当该地址的数据很长时间后才被使用到，那么在使用的时候该数据肯定不在Cache中（被替换了），所以不如直接写入主存来得直接；

相反，如果使用写回操作，当 Cache中有该地址数据，需要更新该数据，设置dirty位，很长时间后再使用该数据或被替换的时候才将其刷进主存，这样白白的占据了宝贵的Cache；而当 Cache没有该地址数据时，情况更糟糕，首先需要将相应的主存数据（一个Cache line）导入Cache，再更新数据，设置dirty位，再等待被刷回内存，这种情况不仅占用了Cache的空间，还多一次从主存中导入数据的过程，同样占据总线，开销很大。至于为什么要先从主存中导入数据，是因为Cache往主存回写数据时是按照一个Cache line 单位来写的，但被更新的数据可能没有一个Cache line这么多，所以为了保证数据一致性，必须先把数据导入Cache，更新后再刷回来。

对于很多视频解码来说，帧写入过程是一个一次性的动作，只有在下一次作为参考帧时才会被使用到，所以帧缓冲内存可以设置为写透操作，而下一次使用它的时候很可能是作为参考帧来使用，而作为参考帧不需要反复的存取，只需一次读操作就可以了，所以效率并不会因为不经过Cache而降低。实验证明该方法可以使 mpeg4 sp解码提高20-30%的效率。