views:

374

answers:

5
+2  Q: 

Graphics Profiling

Ive got an application which drops to around 10fps. I profiled it with xperf which showed my app was using just 20% of the CPU, with none of my methods using a larger than expected amount of that 20%.

This seems to indicate that the vast drop in fps is because the graphics card isnt able to keep up with rendering the frame, resulting in my program stopping while it catches up...

Is there some way to profile what the graphics card is up to and work out what my program is telling it to do thats slowing it down, so that I can try to improve the frame rate?

A: 

Are you developing for Windows? If so avoid using Video for Windows as this will limit you in the manner that you describe. Use DirectX instead.

ChrisBD
I'm using Direct3D, and have a somewhat powerful card so I know my code is causing it to run slow somehow...
Fire Lancer
Are you streaming video from a file.Are you including the audio component as well?
ChrisBD
+3  A: 

For debugging / profiling graphics, try Nvidia PerfHUD

NVIDIA PerfHUD is a powerful real-time performance analysis tool for Direct3D applications.

There is also an ATI solution, called 'GPU PerfStudio'

GPU PerfStudio is a real-time performance analysis tool which has been designed to help tune the graphics performance of your DirectX 9, DirectX 10, and OpenGL applications. GPU PerfStudio displays real-time API, driver and hardware data which can be visualized using extremely flexible plotting and bar chart mechanisms. The application being profiled maybe executed locally or remotely over the network. GPU PerfStudio allows the developer to override key rendering states in real-time for rapid bottleneck detection. An auto-analysis window can be used for identifying performance issues at various stages of the graphics pipeline. No special drivers or code modifications are needed to use GPU PerfStudio.

You can find more information and download links here:

Evil Activity
I have an ATI card, any chance that works with ATI cards somehow or does ATI have there own thing?
Fire Lancer
ok thanks, Ill check it out when I get home since the download page appears to be https and my colleges network seems to not allow https :(
Fire Lancer
A: 

No need to guess. Just pause it a few times under the IDE, and it will show you exactly what it's waiting for.

Mike Dunlavey
Hows that tell which graphics area is causing the slowdown? I'm pretty sure all the methods like DrawPrimitive and Unlock, etc return almost instantly, with directX/GPU sticking work that needs doing into a buffer untill there ready to do it. With the program then having to wait if I try to start a new frame before they have emptied the buffer and finished doing the commands it contained?
Fire Lancer
@Lancer: The way it works is simple. Assuming it is slower than it could be, that means it is spending some fraction of time (50% say) in states that could be eliminated. The state consists primarily of the extended program counter, namely, the call stack. So if you sample the call stack once, the chance you won't see it doing the unnecessary thing is 50%. If you sample 10 times, the chance you won't see it is 1/1024. You will see it on roughly 50% of samples. Now maybe it's not as simple as that, but maybe it is. So good luck.
Mike Dunlavey
... If you look at each layer of the call stack, you will probably find a function call showing up on multiple samples that you never thought would account for much time, but it does. If you can figure out how to avoid making that call, the time you will save is approximated by the fraction of stack samples that contain it. Since you report heavy slowness, it should be really obvious.
Mike Dunlavey
@Lancer: Forgive me if I add to my prior comments. Maybe, or maybe not, your code is waiting for dX. If it is, the stack samples will show it doing that. Then it could be either that the slowness is happening in its buffer, or that you're invoking it more often than you need do. In the former case, you at least know that's where the problem is. In the latter case, you will see calls somewhere on the stack that could be done less often. If samples show you are NOT waiting for dX, then again you will see such calls. If you don't, then you are probably fully optimal.
Mike Dunlavey
+1  A: 

Also, check out this article on FPS:

FPS vs Frame Time

Basically it talks about the fact that a drop from 200fps to 190fps is negligible, whereas a drop from 30fps to 20fps is a MUCH bigger deal. For better performance measuring, you should be calculating frame time rather than FPS.

You never told us what your fps is or what the program is doing at all, so your "vast drop" might not be a big deal at all.

For DirectX, there is PIX for profiling the CPU and GPU operations. It can give very detailed info, and might be worth looking into.

Hope that helps!

JPhi1618
"Ive got an application which drops to around 10fps" I think 10fps on a fairly high end computer is something to make a big deal about...
Fire Lancer
+1  A: 

You can try using dxprof (search in google). It's lightweight app that draws real-time bars, each bar corresponding to one DirectX event (such as draw-call or resource copy). You can freeze the bars and check calls stack to find out where the draw-call originates from.

Kirill