Page hits in DX

Hey everyone

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




Answer this question

Page hits in DX

  • rclakin

    I can't say for sure - "lots of page faults" isn't a very specific place to begin hunting from - but it sounds like it may be down to paging of resources from system RAM to video RAM (in the managed pool)

    What sort of things are you rendering, and how do they use resources (textures, VBs, IBs, etc)


  • pipemx

    By "lots of page hits" I mean a normal frame has anywhere from 600-900 page hits. A spiked frame has upwards of 12,000.

    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

    Ken Noland wrote:
    By "lots of page hits" I mean a normal frame has anywhere from 600-900 page hits. A spiked frame has upwards of 12,000.
    Very curious. I'm at a loss for ideas as to what DX could be doing that's touching that much data in a frame - on a 1GB machine I assume you're not getting low on memory so it must be visiting data spread across memory rather than repeatedly pulling in/out the same set of pages.

    I wonder if perhaps you're running something else that is doing this - like a virus scanner

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

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

    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.
    Right. These back up the notion that resources aren't being paged around and it's not that side of things.

    I tested on three other machines and could visibly see the spike in game.
    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

    Thank you for your very well written response. Page hits is what I meant to say, and yes, I do mean default pool usage.

    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

    Also, by page hits, I really mean "page hits per second" since tha tis the only measurement I can get.

    Anyone know of a way to get the precise amount of page hits per frame


  • Page hits in DX