Strange CPU stall in DX10
I was stress-testing different renderer designs (forward, deferred and light pre-pass) when I came across to this weird behavior. I noticed that sometimes rendering a frame took a longer time than usually, without any apparent reason. The test scene contained 100 objects which were illuminated by using 200 lights. In one test rendering a frame took normally about 23 ms, but suddenly the frame time increased to 96 ms and the following two or three frames took only something like 5 ms. This happened even if the scene was kept static (nothing was moving at all).
I noticed that IDXGISwapChain::Present() was responsible for the major slowdown. I know that DX10 flushes its command buffer when Present() is called so I needed to investigate further what was causing the delay. I used PIX for that purpose and I was able to see a noticeable stall in the CPU timeline. Here's a screen shot from PIX:
It can be easily seen from the screen shot that the GPU is having normal processing times but somehow the CPU is stalling for several frames. The GPU was quite a lot behind the CPU before the slowdown so I was thinking if there is something like a synchronization between CPU and GPU. I also noticed that the red bars in the GPU timeline occurred when the stall happened. I read from PIX's documentation that the red color corresponds to a situation where a resource isn't available. But what would be causing this? I'm not doing any vertex/index buffer or texture locking; only updates are done for constant buffers by the DX10 effect system. The DirectX debug runtimes are not giving any warnings or errors either.
Do you have any idea what's going on here?
I can't tell exactly from your screen-shot but the swapchain will block if it is 3 or more frames ahead of the GPU. Is this what you are seeing?
Well it may be. At least it sounds quite logical to this situation. But if that is the case, why is the swap chain getting so much ahead of the GPU? Am I doing something wrong? The slowdown is really noticeable on the screen, so it's very annoying.
I let the program run for 3 minutes, and I saw that the slowdown happened only 4 times. After 70 seconds, there wasn't any slowdowns at all. But it would be nice to get rid of those slowdowns entirely.
I let the program run for 3 minutes, and I saw that the slowdown happened only 4 times. After 70 seconds, there wasn't any slowdowns at all. But it would be nice to get rid of those slowdowns entirely.
Yes, it happens with all 3 renderer designs. Here's a screen shot from PIX showing the timeline for all the three renderers:
I have noticed this to happen only if the scene is so heavy that the frame rate drops below 50 fps. Although I haven't tested with PIX to be sure that the dropdown is not happening with bigger frame rates.
I have noticed this to happen only if the scene is so heavy that the frame rate drops below 50 fps. Although I haven't tested with PIX to be sure that the dropdown is not happening with bigger frame rates.
I have the same thing happening right now, and have been unable to track it down. Not sure how many machines you have access to, but it happens on some machines for me, and not others. In fact, given identical hardware, I've seen it both happen and not, which makes it a pain to track down.
I saw another post with a similar problem and it ended up being SpeedFan running in the background and not the actual program. I haven't been able to find the magical program running on my PC, but it would explain why it doesn't happen 100% of the time, even on identical hardware. I was doing some speed tests on a command-line app the other day, and with no randomness, I could get 130ms or 190ms. That also makes me believe it might be another program running.
Personally, I'm not quite satisfied until I can put an end to these random spikes. I'm simply telling you this because it's quite random in my case, and everything else I've looked into didn't fix it. Best of luck finding the problem.
I saw another post with a similar problem and it ended up being SpeedFan running in the background and not the actual program. I haven't been able to find the magical program running on my PC, but it would explain why it doesn't happen 100% of the time, even on identical hardware. I was doing some speed tests on a command-line app the other day, and with no randomness, I could get 130ms or 190ms. That also makes me believe it might be another program running.
Personally, I'm not quite satisfied until I can put an end to these random spikes. I'm simply telling you this because it's quite random in my case, and everything else I've looked into didn't fix it. Best of luck finding the problem.
gekko, your answer was quite helpful. I've been doing some further investigations on this issue and I saw that this doesn't happen only in my test program. The same kind of spikes took place even if I was using DX10 SDK's Skinning10 sample. Even Call of Juarez DX10 Benchmark had the same issues and it was clearly noticeable on the screen causing a sudden shake at times. Maybe it is some program on the background like you suggested, but could it be a graphics driver issue? I have NVIDIA GeForce 8800GTX (older one) and my driver version is 196.21.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement