Sign in to follow this  
Wicked Ewok

Optimizing against calls to ntoskrnl

Recommended Posts

Wicked Ewok    144
Hey there, I have been looking at some performance issues of an application using directX. I've profiled it several times using both AMD code analyst and VTune, and a module called 'ntoskrnl' keeps popping up, with KiDispatchInterrupt() taking 15-20% of the whole application's CPU time. I've run this on several graphic hardware cards, including radeon 8500, gf3, gf4 and the fx5950. I've used nvidia perfhud on the tests with the 5950 and it showed the GPU/CPU hardly stalling, with steady spiking every couple of seconds. I would like to know if anyone has any ideas what causes the application to call KiDispatchInterrupt so much. What would be the most probable cause of this? too many DrawPrimitiveCalls? Too many texture switches? Is it something a little easier to fix? I've run across this problem once before, a while ago when I was doing my own rendering engine, but I have since forgotten what the problem was. I did eventually get my engine to stop stalling on ntoskrnl. Might it be bad profiling? (I have bad memory sometimes) Thanks

Share this post


Link to post
Share on other sites
Nik02    4348
All graphics calls go thru an interrupt queue channel (IRQ) allocated for the graphics card. The reason why interrupts get invoked so often is very likely the large number of graphics state changes and/or Draw*Primitive* calls.

-Nik

Share this post


Link to post
Share on other sites
Wicked Ewok    144
Thanks for the reply Nik. I think that was indeed the case with my last renderer. Unfortunate, however that even with batching pretty well implemented that this application still takes so much time on stalls. I wonder if dx9 engines like the cryengine used in farcry stalled as much. There seems to be a final way to really implement any dx9 style rendering, and it seems to me the application I am testing has achieved that more or less for what it does. It does get decent framerate on middle-ground hardware. With 500+ DPC calls(which cannot be reduced due to shaders and textures) it seems that there will always be stalling on modern engines with high content pipelines.

Share this post


Link to post
Share on other sites
HippieHunter    130
To my Knowlege, whenever you lock something or switch threads the os is switched to kernel mode. More than likely its is being caused, "directly" by the driver. Indirectly by Locking VertexBuffers, moving Textures into Video Memory from system memory. Things like this are a good case aginst using Managed flags on your DirectX Resources. So you can actualy know when something is being loaded into memory and when its actualy being unloaded, ect.

So yeah I dont think it's so much the change states as it is the texture, VertexBuffer, IndexBuffer and shader changes. Yeah those sound like state changes but are more specific, so as not to include changes in texture filtering, Alpha testing ect.

Share this post


Link to post
Share on other sites

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