Intermittant Slow Down... How To Debug?
Author
Hi All,
I have a DirectX application which I have written in c++. Sometimes when I run it, it runs at 40fps, other times it will run at 10fps. When I profile it, it seems the extra time is spent inside directx. When I reboot it still runs slow, and there seems to be no reason for the change in performance.
How can I debug this? How can I tell what DirectX is doing internally? I build the debug version, but the profiler still does not show me what functions inside directx are being executed. I put the debug debug output level on max, but the only messages I get are a few redundant state changes, nothing major, not texture thrashing or anything.
Help!
Thanks
Rael
Make sure you're doing all the profiling with a release build AND the retail runtime -- it makes no sense to profile a debug build or against the debug runtime, since both mean your code has lots of validation checks and is unoptimized.
Try removing VSync if it's on. Make sure there are no applications utilizing transparent windows are open (e.g. post-it applications that add sticky notes to the desktop). Make sure no active tooltips are being displayed. Both interfere with Direct3D and cause a major slowdown.
If you don't have the DirectX symbols, download them -- where exactly is Direct3D taking most of the time?
Try removing VSync if it's on. Make sure there are no applications utilizing transparent windows are open (e.g. post-it applications that add sticky notes to the desktop). Make sure no active tooltips are being displayed. Both interfere with Direct3D and cause a major slowdown.
If you don't have the DirectX symbols, download them -- where exactly is Direct3D taking most of the time?
I used to play a game (the saga of ryzom, not to tell its name) for which the framerate dropped DRAMATICALLY (down to like 5 fps or so) whenever windows displaed its tool tip stuff like "xxxx is now connected" or "your computer might be at risk" or "updates are ready for your computer". You know, that suff in the bottom right corner of you screen. Right after those message had COMPLETELY disapeared (not just begun to fade out) the FPS returned back to normal (~60-70 or so). Never figured out why.
Janta
Janta
Try disabling different sections of your code while maintaining main game functionality. This should at least give you an idea where the main trouble areas are.
Don't forget about PIX. It will keep per frame per records, so when there's a sharp dip in the graphs, you can look to see if anything was notably different.
Author
Quote:Original post by Muhammad Haggag
Make sure you're doing all the profiling with a release build AND the retail runtime -- it makes no sense to profile a debug build or against the debug runtime, since both mean your code has lots of validation checks and is unoptimized.
Try removing VSync if it's on. Make sure there are no applications utilizing transparent windows are open (e.g. post-it applications that add sticky notes to the desktop). Make sure no active tooltips are being displayed. Both interfere with Direct3D and cause a major slowdown.
If you don't have the DirectX symbols, download them -- where exactly is Direct3D taking most of the time?
Thanks for the reply. I just downloaded the symbol files, but there is no instructions on how to install them. How do I add these to my project?
Thanks
Author
Nevermind, I found the option under tools to add a new location for symbol files. I am now getting d3d calls in the profiler.
It seems that inside d3d, most of the time is spent in ValidateTextureStageState, and within that, GetDeviceCaps. This gets called when I issue a SetTextureStageState.
Why is it querying the caps internally like this, and why is it taking so long? 13% of the application time seems to be spend inside d3d on the call GetDeviceCaps. This doesn't sound right.
Thanks!
It seems that inside d3d, most of the time is spent in ValidateTextureStageState, and within that, GetDeviceCaps. This gets called when I issue a SetTextureStageState.
Why is it querying the caps internally like this, and why is it taking so long? 13% of the application time seems to be spend inside d3d on the call GetDeviceCaps. This doesn't sound right.
Thanks!
Quote:Original post by Raeldor
It seems that inside d3d, most of the time is spent in ValidateTextureStageState, and within that, GetDeviceCaps. This gets called when I issue a SetTextureStageState.
Why is it querying the caps internally like this, and why is it taking so long? 13% of the application time seems to be spend inside d3d on the call GetDeviceCaps. This doesn't sound right.
Are you sure you're using the retail runtime? The retail runtime shouldn't be doing excessive checks -- that's what the debug runtime does.
(To change the runtime, go to Control Panel->DirectX)
Author
Wow. I have found out the cause of this, though I would appreciate any help to explain it.
It seems to happen when I remove the power from my laptop. My frame rate goes down from 40fps to 10fps. When I plug the power back in, it goes up. I have tried disabling cpu and pci power management, but it still happens.
Anyone shed some light on this?
Thanks!
It seems to happen when I remove the power from my laptop. My frame rate goes down from 40fps to 10fps. When I plug the power back in, it goes up. I have tried disabling cpu and pci power management, but it still happens.
Anyone shed some light on this?
Thanks!
Author
Found it! It seems the ATI chipset in my thinkpad has something called 'powerplay' which tries to cut down the amount of power the chipset uses. I guess one of the things it does is maybe reduce the clockspeed of the graphics chipset when the laptop is not plugged in?
No wonder the profiler wasn't helping me!
Thanks!
No wonder the profiler wasn't helping me!
Thanks!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
