Graphics Profiling

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 2009-05-12 11:29:30

I'm using Direct3D, and have a somewhat powerful card so I know my code is causing it to run slow somehow...

Fire Lancer 2009-05-12 11:33:13

Are you streaming video from a file.Are you including the audio component as well?

ChrisBD 2009-05-13 08:21:02

+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 2009-05-12 11:39:48

I have an ATI card, any chance that works with ATI cards somehow or does ATI have there own thing?

Fire Lancer 2009-05-12 11:44:41

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 2009-05-12 11:51:09

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 2009-05-12 13:10:22

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 2009-05-13 07:25:41

@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 2009-05-13 11:19:42

... 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 2009-05-13 11:33:34

@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 2009-05-13 15:38:22

+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 2009-05-13 15:24:19

"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 2009-05-13 20:48:39

+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 2010-04-27 16:27:38

ansaurus

tags:

views:

answers:

Graphics Profiling

related questions