Unfortunately there are a bunch of problems.

1. The number returned from D3DQUERYTYPE_OCCLUSION differs depending on which vendor made your graphics card, and can even differ across drivers from the same vendor. ATI returns what the D3D spec says, but NVIDIA returns a different value (the one from the OpenGL spec IIRC). Furthermore, different revisions of the drivers return values conforming to different specs. And that's just the big 2 vendors, for some of the others I wouldn't trust the value I got back to make any real sense on its own.

TIP: the best and most compatible way to use D3D occlusion queries is to treat the values returned as relative. When your application starts up, draw a single quad that exactly fills the whole screen, do an occlusion query for that, store the value (Total). Then when you use occlusion queries normally after that, divide the value returned by the stored total so that you always get "what percentage of of this draw is visible?" instead of some arbitrary number.


2. Actually related to #1 (and part of the reason for the difference between vendors), remember to take anti aliasing into account - super sampled isn't the same as multi sample, and the number of samples and type have a direct affect on fill rate.


3. Occlusion queries [only reliably] tell you how many pixels are visible on the screen (or at least some value relative to that), not necessarily how many were actually rendered.

So if I render a single 10x10 quad at location 200,200 on the screen then do an occlusion query which gives me a return value of 1593 (remember, the return can be complete nonesense taken on its own! ;o).

Now assume Z testing/Z buffering is disabled and I draw a single (silly) mesh that has 100 10x10 quads all at location 200x200 on the screen and do an occlusion query. The value I get back is 1593 again, but the GPU has rasterized 100x more pixels.


4. How much real fill rate is used by a polygon depends on a lot more than how many pixels from that polygon made it to the screen! Enabling more texture channels can use some, Gouraud vs flat shading can affect it, whether or not the frame buffer blend is a read-modify-write will affect it, how many pixel shader instructions are used will affect it, etc...


5. If you need accurate numbers (to write a benchmarking program for example), speak to the hardware vendors directly. Many GPUs have hardware counters that would allow them to support things such as D3DQUERYTYPE_BANDWIDTHTIMINGS internally, but the hardware vendors have decided not to expose those to D3D in their drivers (it's a low priority since most people in the world don't need that functionality). For NVIDIA hardware, get NVPerfHUD (that uses the hardware counters). The IHVs may know of a 'special' way to get at the counters directly if its essential for your app to know.


6. What is it you're really trying to achieve? Do you need an absolutely accurate value for the amount of fillrate consumed by rendering? Or do you just need some sort of relative value ("this mesh used 0.01% of the available fillrate")?

[Edited by - S1CA on March 10, 2007 12:41:16 PM]