什么是图形加速卡（四）
原文：http://www.azillionmonkeys.com/qed/accelerator.html
作者：Paul Hsieh
-潘宏 译
-2013年2月
-email: popyy@netease.com
-weibo.com/panhong101
（译注：本文写于2000年左右，很多内容稍显过时。但作为理解GPU发展的历史性、技术性材料，本文真是不可多得）
显示器刷新
最后一个瓶颈，是关于显示器刷新问题的。如我们在显存带宽一节中所说，显卡会消耗一定量的内存带宽用来更新显示器。然而为了避免画面撕裂（Tearing）和闪烁（Flickering），3D应用程序一般会采用双缓冲。也就是在两个帧缓冲之间进行切换的过程中，显示器会使用当前没有被更新的那个帧缓冲（稳定的、可显示的那个缓冲）来刷新自己。如果你想更深入地了解非硬件加速的，用来解决闪烁问题的双缓冲机制，可以阅读我的这篇“无闪烁动画”文章。
在任何情况下，当准备用显存的某一部分刷新屏幕以更新画面前，为了避免画面撕裂，必须等到当前刷新动作（还没完成的）完成后才能继续进行。通常这需要等待“垂直回扫（Vertical Retrace）”的完成。然而该“等待周期”，是由显示器本身的规格决定，而非CPU或者显卡决定，这和处理器标准相比太慢了（比如，在一个72Hz的显示模式下，该速度是平均1/36秒刷新一次）。
下图展示了显示器扫描枪的路径：
如图所示，有些固有的实时事件会按时发生（否则显示器就无法正确工作）。每个事件的长度由显示器的当前模式所决定，这些模式被编好，并放入显存数模转换器中，该转换器通常被称为RAMDAC。RAMDAC必须拥有一定的显存用于在需要时立即执行行刷新（Line Refresh）。有些旧式显卡由于显存带宽限制而无法工作在特定模式下。甚至一些现代显卡也会因严格的显存带宽原因，在高分辨率下（比如1280x1024x24，72Hz）运行缓慢，或根本无法工作。
前文曾提到，VRAM最初用于试图解决带宽问题（允许每周期多次显存访问），但它的成本较高，并且由于其复杂度导致时钟频率受限。较新的解决方案，是简单地将前面刷新时访问到的数据，缓冲（Buffer）到RAMDAC中的一个小的缓存（Cache）中，这样新的行刷新数据访问，就可以和之前访问时的RAMDAC输出，或水平回扫事件，存在时间上的交集。这种方案比较经济，比VRAM方案有更好的伸缩性，但要在技术上达到准确，这需要一个灵敏的显存仲裁器。
一般来说显卡厂商并不会开发精密的显存仲裁器，而只会给予足够大的显存带宽，以满足任何实际的带宽需求。这就导致在特定（经常会重复发生）情况下（比如一个比较大的通过总线传输的数据进入帧缓冲中），画面会产生“闪烁”，因为它无法访问到还没有传输完成的必要数据，以更新屏幕的特定部分。但市场证明了该方案无法被消费者接受，因此显卡厂商要么降低了最大刷新率，要么禁止了高分辨率，都是为了避免这样的显示问题。
过去还有一种方案，就是显示器的“交错模式（Interlaced Mode）”。这种模式下，每次屏幕刷新时只进行隔行刷新，奇数行和偶数行交替进行（NTSC制式的电视就是这种模式）。这降低了一半带宽，但导致了低质量、不稳定的输出。这种方案仍无法被市场接受，从此消失了。
在任何情况下，准确决定翻转帧缓冲的时机都是很重要的。大多数显卡都配有一个内存映射寄存器，用来返回当前正扫描的模拟信号显示行，也可能配有一个标识回扫结束的触发器或中断这种能够被主机监测到的机制。所以很简单：等待命令队列清空，接着等待扫描枪光束抵达屏幕底部，然后就开始翻转帧缓冲（把扫描地址设置为另一个帧缓冲的首地址）。如果显卡的渲染速度大于等于显示器刷新率，就不会对渲染速度产生影响，但在当前（1998）的技术水平下，这基本无法做到，因此高分辨率往往会产生较大的性能波动。
以上这个同步问题很棘手，这促使了厂商Ziff-Davis让两个评测软件（3D WinBench以及他们的一个新的纯应用评测程序）避开了这个同步问题。此行为让我感到很厌恶。Ziff-Davis还有那些对其施压让其就范的显卡公司，难道就不能意识到，完全可以通过适当的架构而不费力地解决该瓶颈吗？就像我们解决遇到的其他那些问题一样。
总之，这里的主旨是尽量避免“回扫等待”。对此我提出过一些实施策略，这里我通过一个例子来概述了我的观点（MS-Word DOC格式，StarOffice也能打开它）。文章的中心思想是：越靠近RAMDAC做帧缓冲翻转，所需等待的时间就越短。另外这些策略也没有什么开销。
最后，为了避免在SGI流水线架构下的各种等待开销，显卡必须必须引入一个三缓冲模式，这在我的“无闪烁动画”文章中有所描述。这当然不是最令人满意的方案，因为专用的纹理显存经常会带来更全面的性能提升。
当然，如果显卡厂商仍然很白痴（比如nVidia）的话，就算三缓冲也并不能解决所有问题。实现三缓冲机制的一个典型错误，就是当两个后备缓冲填充完毕的时候，渲染被暂停以等待前缓冲完成其显示，然后再按照顺序翻转两个后备缓冲，这总是以特定的顺序进行。这种错误的实现方式只会不断地导致暂停而没有根本解决该问题（这让人们错误地以为，未来他们应该需要四缓冲、五缓冲、六十九缓冲...）。
正确的实现会分清楚4种显示缓冲类型：
（1）当前正在显示的；
（2）当前正在填充的；
（3）填充完毕还没显示的；
（4）废弃的或还没填充的。
基本上规则是：显示指针会被设置到（3），然后把之前指向的缓冲设置为（4）。当要找一个新的缓冲来渲染的时候，应该选择（4）或者最长时间没有更新的（3），完成后把缓冲设置为（3）。使用这个规则，显卡或主机都不需要暂停。
以上我们分析了在SGI架构下所有可能产生回扫延迟的可能。然而，延迟渲染（Deferred Render）却产生了更多的延迟可能，这将在后面架构一节进行讨论。
