为什么direct的present竟然可以花费20NS还多？

小陈00

用的时候也不知道把程序哪个地方给改了一下，
在标准的游戏循环里（就是PEEKMESSAGE做的那种）只是用空的present
在WINDOW模式下面居然花费了20ns多。。。可怜我的c1800+fx5200跑空的present都只能跑到50FS ：（ 为啥喃？
我用的创建DEVICE的代码是D9 SDK的TUL（英文单词写不起，向导）的原版代码拷贝下来的。（后来为了调试，代码被栓得和SDK的一模一样还是慢）
经检测 创建出来的 SWAPCHAIN的各项数据 和一个正常D9程序的数据一样。 可是为啥她能这么慢喃？我都调试3天，快钱驴计穷，哪位救救我啊/。

源代码之光

有这样的情况，就是空跑，可能会超速，造成fps不准确
你的时间测试软件是什么？

小陈00

不会超速啊，才50FS怎么超速。。。。。
我是这样测的时间。。。。。。
gettickcount
present
gettickcount
为了进一步的精确我什么东西都没有渲染，只是PRESENT白的后端。
渲染了presnet花的时间也是一样的
在我的C1800+FX5200下面present花费了20ns??
后来害怕测一次不准，采取了多次测的方法
这样
gettickcount
10次present
gettickcount
结果就花费了200NS。。。
还有时间应该是测对的，因为我用的是DEBUG版的DXRUNTIME，如果不向后端缓存写东西的话，DX自己默认要填如一些XXX颜色，看颜色变化速度也能知道FS很低。。。。。
以前用一台366的机器时也出现过这种情况，弄的366机器跑白的present FS都只能上到20多了，后来被逼的没办法重写了一遍代码，就没有问题了。可是应该说重写的代码和出问题的代码是没有区别的，因为都是直接从出问题代码COPY过去的，最多顺序上有些区别，当时只是觉得奇怪，却发现不了问题，也就算了。
改天借个U盘把出问题的代码考上来，帮忙看看啊

小陈00

经过了又一天漫长的调试 。。。。。。
机器配置（　Ｃ１８００　ＦＸ５２００　）所用编译器为ＶＳ２００３（我用过最烂的编译器！）

为了避免引入自己的错误代码，现在改为试用ＤＸ９ＳＤＫ　tul??(这个英文写不起啊。就是那个向导）
的实例代码进行调试，该代码在　ＳＤＫ　的ＳＡＭＰＬＥ目录下面可以找到。

唯一自己引入的代码是
ＧＥＴＴＩＣＫＣＯＵＮＴ
ＰＲＥＳＥＮＴ
ＧＥＴＴＩＣＫＣＯＵＮＴ
料想这个也不能对ＤＸ的工作产生不良影响？

用我那个该死的２００３对ＤＸ９的示例代码编译过后present花费近２０ＮＳ的问题依然存在。
当将示例代码改为创建ＤＸ８后，就是将接口声明为８，ＣＲＥＡＴＥ那里改为８，速度既恢复正常。
ＤＸ８编译下来白的ＰＲＥＳＥＮＴ是８００多ＦＳ，而９编译后是５０ＦＳ。。。

在调试过程中发现一个奇怪的现象

在ＤＸ８下面如果一个renderloop里只有一个ＰＲＥＳＥＮＴ时，象这样
ＧＥＴＴＩＣＫＣＯＵＮＴ
ＰＲＥＳＥＮＴ
ＧＥＴＴＩＣＫＣＯＵＮＴ
不会产生阻塞现象（姑且称为阻塞）
当一个renderloop包含３或３个以上present时,这样
ＧＥＴＴＩＣＫＣＯＵＮＴ
ＰＲＥＳＥＮＴ
ＰＲＥＳＥＮＴ
ＰＲＥＳＥＮＴ
ＧＥＴＴＩＣＫＣＯＵＮＴ
会随机产生一些阻塞（阻塞时间为１６ns)

而Ｄ９下面renderloop里只有一个ＰＲＥＳＥＮＴ时，就会产生阻塞了。而且有些时候还往往能跳到１６Ｘ２去
Ｄ９下面present花费的时间大致像这样
一个　present 0 0 0 0 0 0 0 16 0 0  0 0 0 0 0 0 0 16 15 0 0 0 0 32 0 0 0 0 0 0 16 0 0 0
两个present １６　１６　１６　１６　３２　３２　３２　０　０　１６　１６　３３　１５　０　０　０　０再往上就更厉害了
而Ｄ８下面present的时间即使一个ＬＯＯＰ里包含８，９个present阻塞的情况也不常发生
Ｄ８下８个present的情况　0 0 0 0 0 0 0 16 0 0  0 0 0 0 0 0 0 16 15 0 0 0 0 15 0 0 0 0 0 0 16 0 0 0

那位达人给我讲讲ＤＸ　对于这个ＳＷＡＰＣＨＡＩＮ的处理机理啊，阻塞的时候必定是ＤＸ在内部对于ＣＨＡＩＮ进行安排，可是怎么能够花到１６ＮＳ如此之多呢？而且Ｄ９下面阻的凶的时候也是以１６ＮＳ为因数向上跳的
可以看出这１６ＮＳ是由一个固定的过程调用的，是哪个过程呢？

现在按我来想问题可能出在ＶＳ２００３上，记得２００２ＶＳ的调试界面和Ｄ９都整合了，可是偏偏到了２００３里调试界面却又不支持了。但好象２００３又支持一些２００２的调试Ｄ９的功能，会不会是这种混乱把超级调试断点代码含进了２００３编译的Ｄ９里？产生的ＸＸ？可是想一想又不象啊，即使是我编译出release版本速度还是一样慢。。。。那可能是啥原应？
另外我的机子运行ＳＤＫ里面编译好的示例速度是正常的。

源代码之光

你的fps可能不准，建议用tune软件测试以下函数时间，这才是正道
你那么测，很可能会超速

小陈00

不是啊，不是啊，不是超速啊，同样的代码在D8下面是完全正常的，再说50FPS 和800FPS是用眼睛都可以看出来的啊？direct 的 DEBUG RUNTIME 是自己要对后端缓冲乱加颜色的，50 和800的画面真的区别很大啊~看花纹都可以认出来~~~~~再说我后来怕自己被测准用了10个present速度都降到几FS了 还会超速？再说速度都慢到那个程度了我又怎么会看不见，D9下面稍微加一个大点MESH就跑求不动了，还超了毛的速啊，我调试几年程序了，不要再说我调超速了嘛，我都快被这个问题逼疯了。

小陈00

我日他妈外国人的MMX啊，外国人太凶了，我才去gamedeV发了一下就弄对了，日，以后结婚一定要找外国人，我太爱外国人。。。。
外国人真是好动西啊。。。
The reason for this is may be that when you are creating your D3D device, one of the variables in the "presentation info" struct is not set right. In DX9, you should set the &quotresentationInterval" parameter of the D3DPRESENT_PARAMETERS struct that you pass to IDirect3D9::CreateDevice to D3DPRESENT_INTERVAL_IMMEDIATE. If you don't, your frame rate will be locked to the refresh rate of your monitor.

I think that the reason DX8 seems to perform better is that D3DPRESENT_INTERVAL_IMMEDIATE was the default back then, but not in DX9.

Hope this helps,
neneboricua

小陈00

The system timer runs at approximately 10ms.
Windows Me/98/95: The system timer runs at approximately 55ms.
Windows NT 3.1: The system timer runs at approximately 16ms.

我爱美国人。。。。。。