I’ve been experiencing some severe framerate drops that seem to stem from DX. I built a real simple embedded profiler and started debugging the app to see where these “spikes” were coming from. I wrapped all DX calls within the profiler and sure enough I noticed right away that the spikes were originating from the DX calls. I started up DX Pix to see if that would tell me anything and sure enough I was seeing the drop in framerate in Pix as well, but I also noticed that the drop in framerate also correlated to an increase in page hits. Timing on these page hits seem to appear once every full second.
The primary machine I am testing on is:
Dual Core 3.2 GHz, 1.0 Gig RAM
NVIDIA GeForce 6800(Consistent across multiple drivers)
The odd thing is that in windowed mode it is much more apparent then in fullscreen mode. Our app does not distinguish between windowed and fullscreen and so none of the calls being made from our app are modified (with the exception of creating the device).
I’ve been trying to track down this problem and build a solution around it that wouldn’t involve rewriting our current method of handling spacetime. When these spikes occur they cause a leap in our spacetime which then appears as a leap in game when the next frame is processed. We work off a fixed framerate model and so processing should be evenly distributed, but this is causing “hiccup” issues.
Are there any known issues with DX that cause page faults to occur this frequently

Page hits in DX
rclakin
What sort of things are you rendering, and how do they use resources (textures, VBs, IBs, etc)
pipemx
We have a basic rank buffer management system that checks to ensure that the amount of textures stored on the card do not exceed the cards available texture mem, and the same goes for vertex bufs, index bufs, and shaders.
We have mixed samples with various storage specifiers. Some vertex bufs are stored as static and remain on the card while other vertex bufs are stored in managed buffers. I tried mixing that up a bit to see if managed buffers were causing the problem but I had no success. I switched all create calls to static and still saw the page hits.
In NV_PerfHud I can see that the page hits are *probably* coming from DX management since I don't see any spikes on the driver or the GPU. Texture mem on the card is barely being used(25 meg out of 256) and AGP mem only has a fraction of what it can hold(8 meg out of ). The sample that I am running off of is very minimal to try to see if I can track this whole thing down, yet I'm still seeing spikes.
I ran a couple other examples to see if this was localized to our app. I started up a copy of Eberly's WildMagic game engine and sure enough, I saw the spikes there too. The same holds true for some of the more complex samples from NVIDIA.
I tested on three other machines and could visibly see the spike in game.
By the way, thanks for your quick reply!
-Ken Noland
ProNovice
I wonder if perhaps you're running something else that is doing this - like a virus scanner
How are you getting the "available" memory on the card If it's using GetAvailableTextureMem, be aware that you should not use that function for fine-grained decisions (like whether to page something in or out of VRAM) - the notes on the function's page in the SDK explain this.
Also, why are you using your own system instead of letting D3D and the driver do it for you via the managed pool Or do you just mean that you're hinting on resource usage (via Resource::PreLoad)
You mean Default pool resources Hmm, ok. If you're successfully creating all your resources in the Default pool then you're not running out of video memory, so it can't be that side of things.
Right. These back up the notion that resources aren't being paged around and it's not that side of things.
Veeery interesting. Given that they don't spike on machines in general - at least, I don't have any problems with any of the samples on my machine - it seems like it must be something that those machines have in common, either in hardware or software/environment.
(BTW: "page hits" and "page faults" are not interchangable terms - they're actually opposites.)
sspotts
I'm currently on vacation and so I'm a couple thousand miles away from my main machines so I can't test this immediately, but I do remember when I have SysInternals Proc Explorer open I can see that the page hits are coming from the app itself. If that is accurate or not is something I personally do not know.
In linux there is a way to determine page hits on an app, but I haven't been able to find a way in win32 yet. Is there a way
Zano
Anyone know of a way to get the precise amount of page hits per frame