[slimDX] Direct3D9 FrameStatistics
Author
Hi,
I'm new in the slimDX use. I would like to use FrameStatistics on DIRECT3D9 (XP station), but i dont kwow how to declare it in my c# VS2008 prog. Could somebody help me to get an example or a short tips.
Many thanks
Author
Thank's for your answer
1) In C++ DX9 the hierarchie is :
IUnknown
IDXGIObject
IDXGIOutput
2) The property is :
IDXGIOutput::GetFrameStatistics
3) The accessed struct is :
DXGI_FRAME_STATISTICS
typedef struct DXGI_FRAME_STATISTICS {
UINT PresentCount;
UINT PresentRefreshCount;
UINT SyncRefreshCount;
LARGE_INTEGER SyncQPCTime;
LARGE_INTEGER SyncGPUTime;
} DXGI_FRAME_STATISTICS, *LPDXGI_FRAME_STATISTICS;
I have interest with SyncRefreshCount. This field shoul help me to know if a VBLANK has occured since my last call.
1) In C++ DX9 the hierarchie is :
IUnknown
IDXGIObject
IDXGIOutput
2) The property is :
IDXGIOutput::GetFrameStatistics
3) The accessed struct is :
DXGI_FRAME_STATISTICS
typedef struct DXGI_FRAME_STATISTICS {
UINT PresentCount;
UINT PresentRefreshCount;
UINT SyncRefreshCount;
LARGE_INTEGER SyncQPCTime;
LARGE_INTEGER SyncGPUTime;
} DXGI_FRAME_STATISTICS, *LPDXGI_FRAME_STATISTICS;
I have interest with SyncRefreshCount. This field shoul help me to know if a VBLANK has occured since my last call.
Quote:
1) In C++ DX9 the hierarchie is : ...
DXGI is not part of D3D9. It was added with D3D10 and underpins the API from 10 onward, but is not usable with D3D9 code.
As far as I know there is no equivalent structure to DXGI_FRAME_STATISTICS in 9. There are bits and pieces of interesting information -- for example, D3DRASTER_STATUS -- but I don't know of any D3D9 API to get the equivalent to the sync refresh count.
Author
Thanks for your explanation.
1) So far i know, DX10 can't be run on XP station. Is that done ?
2) As you probaly know, D3DRASTER_STATUS say only thas VBLANK is in process giving as a return value the number of HSYNC line in refresh. This is not realy usable to know if a new VSYNC is done since a preceding test. This VSYNC info could be help me to save CPU time avoiding to call Device.Present and also flip on screen.
An Idee to do that ?
I wish you a free of bug day !
1) So far i know, DX10 can't be run on XP station. Is that done ?
2) As you probaly know, D3DRASTER_STATUS say only thas VBLANK is in process giving as a return value the number of HSYNC line in refresh. This is not realy usable to know if a new VSYNC is done since a preceding test. This VSYNC info could be help me to save CPU time avoiding to call Device.Present and also flip on screen.
An Idee to do that ?
I wish you a free of bug day !
Quote:
1) So far i know, DX10 can't be run on XP station. Is that done ?
D3D10 cannot be used on XP.
Quote:
2) As you probaly know, D3DRASTER_STATUS say only thas VBLANK is in process giving as a return value the number of HSYNC line in refresh. This is not realy usable to know if a new VSYNC is done since a preceding test.
Correct, the raster status does not contain sufficient information to make any kind of determination about whether you have missed a blank.
Quote:
This VSYNC info could be help me to save CPU time avoiding to call Device.Present and also flip on screen.
An Idee to do that ?
I wish you a free of bug day !
I don't understand why you need to bother with this, it is an unnecessary attempt at optimization. You can likely achieve what you want by setting the presentation parameters to wait or immediate as needed to achieve the results you want.
Author
"Wait" waste to many time 1/60 s (with a 60 Hz screen). "Immediate" put some flip on the screen, but with your help i decide to test InVBlank. I will give you the result on this thread.
Thank's for all.
Thank's for all.
There's also the DoNotWait flag to Present, which might do what you want. Although I'd recommend against it, personally.
Quote:
"Wait" waste to many time 1/60 s (with a 60 Hz screen). "Immediate" put some flip on the screen, but with your help i decide to test InVBlank. I will give you the result on this thread.
Thank's for all.
Again, I don't see what this is going to get you. What are you going to do on the CPU if you are in the blank period? If you are going to continue processing something else, just do it without regard to the blank and let the card deal with it. If you are going to wait for the blank, then again, tell the API to wait for the blank. You're reinventing the wheel in a suboptimal fashion.
Author
Quote:
What are you going to do on the CPU if you are in the blank period?
I will try to explain to you but my english is a bit limited to do that.
This is not the blank period the problem, but the fact that Present with PresentInterval.Default wait for it (VSYNC) locking my prog during this time witch can be arount 16 ms (60 hz). In the same time i move sprite on screen, i also show video with direcshow/sound (25 fps), compute the future sprite to draw, check for keyboard and RS232. If i waste time to wait the good time to draw directshow slow down (sound is hashed). If i use PresentInterval.Immediate the screen flip.
But the good news is that testing inVblank before to present the flip disapear.
I thank you all for your help and your interest.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
