Sign in to follow this  

help using IDirect3DQuery9

This topic is 4202 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

This topic is 4202 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this