The standard way to work out what the bottleneck is is to give the GPU less work to do, and see if it goes any faster. If it does then you're not completely CPU bound. You need to do this while still making the same set of draw calls. There are various ways to do this, including:

- Reduce the screen resolution or render target size.

- Set a tiny scissor rectangle.

- Replace pixel / vertex shaders with simple ones.

Having said that, if you're looking at single frame spikes with D3D a common cause is using something (shader / texture / vertex buffer / etc.) for the first time. This is because D3D drivers are generally lazy and only fully initialize things on first use. While this saves on doing work for things you never use, in most cases it's really unhelpful. The workaround is to do a bunch of off screen draw calls on the loading screen that make use of every texture and shader. That means you don't have to wait for the driver to, for example, upload a bunch of textures to video RAM when the end of level boss appears.

In general profiling with vsync enabled isn't very useful, because the delays waiting for the vsync tend to hide the real performance. I'd recommend doing all profiling with vsync off.

Enabling triple buffering can hide even more performance issues than vsync alone, but it will also generally give a better experience than double buffering with vsync when the game is running slower than the refresh rate.

Also note that you want to profile an optimized build, which wasn't started with the debugger attached (starting with the debugger attached puts the Windows heap into a relatively slow debug mode).

What's the performance like with vsync off?

With vsync off it looks like your game is generally running fast enough. There's a few spikes where frames are getting close to 16ms which could be explained by my first post. Other than that it's running at about 8ms / frame.

I don't trust those CPU performance numbers. The vsync off numbers should have roughly the same CPU usage as with vsync on. My guess is that you're measuring the CPU time spent idle waiting for the GPU in those numbers. That generally happens in the Present() call.

With vsync off you have a couple of spikes, which are close to 3 times the normal frame time (~50ms). One possible explanation is that somehow the CPU and GPU were forced to synchronize on those frames. D3D buffers up to 3 frames worth of GPU commands when it's GPU bound, and forcing a synchronization will flush that queue (so the CPU gets blocked for 3 GPU frames). Forcing synchronization generally happens when you lock something that is in use by the GPU (vertex buffer / texture / etc). See http://msdn.microsoft.com/en-gb/library/windows/desktop/bb205132%28v=vs.85%29.aspx#Accessing for a D3D10 based explanation of that.

In addition allowing the GPU to get three frames ahead can give you extra lag that you may not want. You can use queries to prevent it getting so far ahead - you want two of them where you issue one and wait for the other on every frame, and then swap over. Note that you do want to allow it to get one frame ahead or you throw away lots of performance because that allows the GPU and CPU to work in parallel (and for SLI systems you should allow it to get two frames ahead). For a quick test Nvidia drivers also have a setting to control it called "maximum pre-rendered frames".