先Present()后Render()如何？

hdm2968

应该不错

rUIing

没看懂...
PRESENT()不就是翻页?

creamy_mami

楼主的那个的确是最好的顺序

rUIing

哦~看懂了,确实

冰峰传奇

说是这样说，
但是简单的这样做，没什么意义。
问题的关键在于为什么

Present()和EndScene()距离远一些，这样可以使CPU和GPU尽量并行工作。

另外cpu和gpu并行工作上，并不是简单的有定论的。

creamy_mami

简单说一下：

CPU和GPU在渲染过程中，多数时间是异步工作的。D3D层（Device接口）提交渲染指令放入Driver层维护的队列中，之后立即返回，GPU从队列中取出指令执行，只有在执行到Present的时候（实际上还有其他情况，先不讨论），CPU要等到队列中所有的指令执行完毕才会返回，强制同步一次，通常要等很久，所以我们要把这段等待的时间拿来做别的，通常是AI，或者是可见性判断之类，这样会把CPU空闲时间降到最低。

如果是这样的顺序
Refresh();
BeginScene();
Render();
EndScene();
Present();
不仅在EndScene到Present之间CPU会有很长空闲时间，在Present到下一个BeginScene之间GPU也会有很大空闲，对于AI比较复杂的游戏影响会很明显，对于简单的图形Demo影响不大

不知道说明白没

冰峰传奇

说是说明白了，但我还有些疑问。
present 翻页肯定要等艘有的渲染操作完成，这个很正常。
问题在于最后的一个draw的操作你再干什么。
如果是一个巨大无比的模型。。。那么显然要等等了。
但如果是一个很简单的操作呢？

另外
D3D层（Device接口）提交渲染指令放入Driver层维护的队列中，之后立即返回。
是这样的，可是这个队列最多能有多大？？
这方面的情况是怎样的呢。文档里好像没有提及阿。
如果这个队列满了，也显然是要停下来了。

冰峰传奇

做了大量测试兵查阅了相关文章，
结论是：
先Present()后Render()会有好处
的说法实在是非常幼稚（即使是大规模逻辑计算）。

标准流程中的
render()
present()
就是好的。

应该说present()和present()之间的距离远点比较好。

Liker

楼上真是高手，看来creamymami在分裂细胞4小组算是白混了