help using IDirect3DQuery9

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 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

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.

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?

Quote:

Original post by Wixner 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.

I would personally assume that NVPerfHUD is the correct timing - it can be tricky to get correct without accidentally affecting the results...

Quote:

Original post by Wixner 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?

Could 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.

Quote:

Original post by Wixner 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.

If 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...

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