问题的关键：到底是多少加多少？

　　最后，如果多个线程导致VLIW CORE的寄存器和缓存资源出现溢出，执行单元将会把这些线程发还UTDP进行线程块合并，在《谁是微软忠实随从 A/N统一架构历史回顾》及《忠实微软是否有用 A/N统一构架细节分析》中我们不难发现，对于Barts以及Cayman构架这种访问及操作路径和缓存资源均极端不足的构架来说，寄存器溢出基本上就意味着无后手可用，只能将线程发还给UTDP进行wavefront合并。与此同时，如果某线程未通过Adjacent-Instruction Dependencies检查，这些线程也将被押后最少64个周期并再次寻找依赖性达到要求的位置重新打包。这些重复和多次打包的要求对于本已负担沉重的UTDP无疑是雪上加霜的。

　　在这些客观因素的影响下，Barts以及Cayman的单卡在面对任务时，是很难跑出全部性能的，大量的单元会因为线程密度不足带来的延迟而处在闲置状态。 要解决这种问题其实倒也不难，只要降低UTDP的负担，让其能够更加平顺的吞吐和控制合适长度的线程队列，或者管理更少的ALU资源就行了。伴随着单位线程管理强度的下降，Barts和Cayman构架可以获得更高的性能提升幅度。

　　CrossFireX的操作，刚好对应了这种需求。

CrossFireX连接结构

　　我们前面的文章已经提到过，CrossFireX通过对画面的分割，实际上完成了对像素线程队列的分割，被分配到每个GPU中的像素线程队列仅有正常单卡处理时的一半左右，原先由2个UTDP处理的任务总量现在被平摊到了4个甚至更多的UTDP单元中共同完成，这极大地缩短了UTDP所要面对的线程队列长度，大幅削减的线程负担让UTDP可以更加从容的完成吞吐，并且有更多的周期来处理合并线程等其他琐事。更加合理高效的线程管理在时间和空间上提升了整个VLIW CORE的运算密度，这使得每一颗GPU都拥有了比单独处理任务时更高的性能表现。

CrossFireX对画面的拆分

　　这就是一切的真相，我们并不否认驱动优化的意义，但实际上CrossFireX的出现确实是“无意间”改善了Barts及Cayman构架先天设计的缺陷，只有在CrossFireX的状态下的Barts和Cayman才能够发挥出应有的性能水平。这个时候的1+1，才能得到正确的结果。所谓超过100%加速比的现象，不是火星科技，也不是极致优化所带来的锐意精进的结果，它只不过是由于单卡面对任务时性能无法得到发挥所导致起点过低而产生的错觉罢了。