help using IDirect3DQuery9
Author
Hi. We're having some severe performance-issues with our current project, and I've been the one assign the task of pinpointing the bottlenecks
For this, I was planning to use IDirect3DQuery, but it seems that my GF6800GT cannot create any query except the D3DQUERYTYPE_OCCLUSION so I thought I'd turn here for some help. What is required to support the other D3DQUERYTYPE's? Am I doing wrong? Do I need some special drivers etc?
I'm not sure about the Query stuff, I'm pretty sure my FX5200 supported more than just occlusion, but I'm not sure about that one.
I'd recommend you try either NVPerfHUD, or PIX. After all, that's what they're there for.
I'd recommend you try either NVPerfHUD, or PIX. After all, that's what they're there for.
I ran into this issue recently; I'm pretty sure your hardware should handle D3DQUERYTYPE_VCACHE and D3DQUERYTYPE_EVENT as well. Maybe one other, but I seem to remember its only 4-5 of the total.
Typically its NOT the hardware that is limiting you - its the drivers. Grabbing the instrumented drivers should enable more (if not all) queries I think. Problem is that instrumented drivers are slower (which can mask retail performance problems) as well as out of date unless you're a registered developer (which is one of the hardest challenges out there [lol])...
Older 79.70 instrumented drivers are available here (from this page).
Alternatively, you might want to skip the hassle with queries and dig into NVPerfHUD and/or PIX.
hth
Jack
Typically its NOT the hardware that is limiting you - its the drivers. Grabbing the instrumented drivers should enable more (if not all) queries I think. Problem is that instrumented drivers are slower (which can mask retail performance problems) as well as out of date unless you're a registered developer (which is one of the hardest challenges out there [lol])...
Older 79.70 instrumented drivers are available here (from this page).
Alternatively, you might want to skip the hassle with queries and dig into NVPerfHUD and/or PIX.
hth
Jack
Author
Quote:Original post by sirob
I'm not sure about the Query stuff, I'm pretty sure my FX5200 supported more than just occlusion, but I'm not sure about that one.
I'd recommend you try either NVPerfHUD, or PIX. After all, that's what they're there for.
Yeah, I've used NVPerfHUD alot - great application - but it seems that I can get more information from the general queries, like bandwithtimings and such.
jollyjeffers: I'll try those drivers on my GF6600GT tonight.
Author
Hmm.. Another day and another day fighting performance problems.
Using the instrumented driver, NvPerfKit reports that my gpu has a 35msec idle time and 4ms time in the driver each frame, but NvPerfHud reports that i've got a 12ms drivertime and a 6ms cpu-waits-for-gpu time. It seems weird that two similar applications from the same vendor can differ this much.
Anyway, analyzing these values, it seems that our applications spends a little bit too much time in the driver; to many direct3d SetXXXXXXX calls, right? Aside of this, we've got a material system that enforces multipass-rendering, even for multi-texturing so we really got a vertex-count overhead.
So if'd report that we really need to implement singlepass multitexturing and improve our statechanges, i'd be right, right?
Using the instrumented driver, NvPerfKit reports that my gpu has a 35msec idle time and 4ms time in the driver each frame, but NvPerfHud reports that i've got a 12ms drivertime and a 6ms cpu-waits-for-gpu time. It seems weird that two similar applications from the same vendor can differ this much.
Anyway, analyzing these values, it seems that our applications spends a little bit too much time in the driver; to many direct3d SetXXXXXXX calls, right? Aside of this, we've got a material system that enforces multipass-rendering, even for multi-texturing so we really got a vertex-count overhead.
So if'd report that we really need to implement singlepass multitexturing and improve our statechanges, i'd be right, right?
Quote:Original post by WixnerI would personally assume that NVPerfHUD is the correct timing - it can be tricky to get correct without accidentally affecting the results...
Using the instrumented driver, NvPerfKit reports that my gpu has a 35msec idle time and 4ms time in the driver each frame, but NvPerfHud reports that i've got a 12ms drivertime and a 6ms cpu-waits-for-gpu time. It seems weird that two similar applications from the same vendor can differ this much.
Quote:Original post by WixnerCould well be; either NVPerfHUD or PIX can tell you how many of what calls you're making for a given frame (or frames), so that might be worth checking out.
Anyway, analyzing these values, it seems that our applications spends a little bit too much time in the driver; to many direct3d SetXXXXXXX calls, right?
Quote:Original post by WixnerIf you had a high vertex load then you'd be seeing a much higher "cpu-waits-for-gpu" percentage. How many Draw**() calls are you making - that could easily be a bottleneck with the method you described...
Aside of this, we've got a material system that enforces multipass-rendering, even for multi-texturing so we really got a vertex-count overhead.
One other thing to consider if your application is stalling on Present() (after the command queue fills up and you've got CPU-waits-on-GPU) is to use the D3DPRESENT_DONOTWAIT flag and do some CPU-only work whilst you're waiting on the GPU...
hth
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
