引用:

原帖由 seek 于 2012-9-20 18:11 发表
360显卡自带的dram太小了，一个pass渲染不过来，共享显存又太慢..

我说，你明白你在说什么吗？一个pass渲染不完和屏幕撕裂有啥关系？EndTiling又不会触发swap或SynchronizeToPresentationInterval
每次swap/present之前，都需要把backbuffer（本质就是一个rendertarget）从EDRAM中resolve到main mem的（front buffer存在于main mem中）。每次resolve的都必然是一个完整的frame。
造成撕裂的原因无非就是没有设置同步垂直罢了。XBOX360没有自动的tripple buffering，它的Backbuffer+2-frontbuffer mode只是不会block住CPU的fill GPU Commandbuffer（GPU还是会block住）。所以想实现类似tripplebuffer效果需要手动处理一下。要麻烦一些。
不过tripple buffer也不是一个always win的选择，比如input latency方面有副作用，还要多占显存等。因此相当部分PS3游戏宁可撕裂也不用tripple buffer。

引用:

原帖由 FXCarl 于 2012-9-21 02:43 发表
质疑，Doublebuffering 如果有垂直同步也不会有屏裂啊 …… 如果为了说避免跳帧而关闭垂直同步，很可能每帧画面都是裂的 ……
想想其实还是应该打开垂直同步才对，如果渲染负荷降低时还能降低 GPU 负担。
...

double buffer的问题在于SynchronizeToPresentationInterval会让CPU和GPU都wait到下一个VBlank
这样没有充分利用性能。在rendertime微小浮动时可能会造成帧数较大波动并降低流畅度（把CPU/GPU cycle给sleep了嘛），而且画面显示和操作之间的延迟也是存在的，尤其是在帧数较低的情况下。
当然如果每帧负载比较小，比如基本是恒小于16ms，那么用double buffer显然是没问题的。
现在的一些做法是手动处理，也就是根据渲染时间决定是否同步垂直，超过33ms就不使用，这也就是经常见到的‘低于30fps时出现撕裂’的原因。

[ 本帖最后由 hourousha 于 2012-9-21 09:43 编辑 ]

引用:

原帖由 tdka 于 2012-9-21 12:26 发表

并没有，三重缓冲延迟比双重低

事情不是这样。我们可以做一个简单的理想化的假设。
假设游戏主逻辑循环形如
read input->gamelogic->render->present。最后一步和同步垂直相关。屏幕刷新率60。只采用double buffer或tripple buffer，没有额外的Timer控制。
我们把read input->gamelogic->render的总时间叫做processtime，延迟Latency的定义为read input和最后present之间的差值。
对于processtime<16ms的情况，无论是D-Buffer还是T-Buffer这个latency是恒定的16ms，即刷新的时间间隔。
当processtime = 20ms时会怎样呢，我们来计算一下。设某时刻的时间为0，第n帧的read input时间表示为In，Render finish时间表示为Rn，Present时间表示为Pn
D-Buffer的情况简单如下
I1 = 0,R1 = 20,P1 = 33; I2 = 33,R2 = 53,P2 = 66……
因此延迟为33ms
TBuffer情况如下
I1 = 0,R1 = 20,P1 = 33;I2 = 20,R2 = 40,P2 = 50;I3=40,R3=60,P3=67；I4=60,R4=80,P4=83；I5=80,R5=100,P5=100
延迟基本在20-33ms之间浮动，总体比D-Buffer时低。
当Processtime = 30时
D-Buffer的延迟依然为33不变
T-Buffer情况如下
I1 = 0,R1 = 30,P1 = 33;I2 = 30,R2 = 60,P2 = 67;I3=60,R3=90,P3=100；I4=90,R4=120,P4=133；I5=120,R4=150,P4=150
可见此时的延迟在30-40之间浮动,总体比D-Buffer时高。

而实际情况则要更复杂，因为processtime每帧都是变动的。但结论就是T-Buffer会给input latency带来更多的不确定性。

[ 本帖最后由 hourousha 于 2012-9-21 14:19 编辑 ]