Is my frame time too high?

I think you should not focus on micro-benchmarking api calls you cant change anyway. Just add some real work and only worry when you get below the refresh rate of your monitor. First make the whole thing work, then profile, then optimize.

Is my frame time too high?

Is it preventing you from hitting 60fps? No, then it isn't an issue.

The time taken to render an empty frame is completely meaningless.

Once you get above, a few hundred I don't think the time is meaningful anyway since I do not see why hardware, DirectX or drivers would put any effort into it, e.g. the driver or MS could literally have something like:

HRESULT IDXGISwapChain::Present(UINT SyncInterval, UINT Flags)
{
    //MS Dev: This function takes 0.5ms in the best case or 2000FPS if no other work is done.
    //Some of the code is not great and perhaps it could be made 0.4ms, allowing 2500FPS
    //but since from 60FPS (16.6666ms) that extra 0.1 just gives you 60.04FPS why bother?
    ...non-optimal code...
}

Kind of reminds me of that Valve OpenGL faster than D3D thing at some speed where noone really cares and not having a useful 120FPS or below example (e.g. if OpenGL could actually get me 120FPS 3D and the best D3D code only 90FPS then I might care).

So wait you're worried that your essentially blank window is running at 1600 fps instead of 5000 fps?

Why? That's really a weird time to be worried about anything performance wise.

I'm not really micro-benchmarking as such, I'm just making sure the calls I am making are the right ones. The main reason is that I have two engines - one which was a terrain work in progress that purely just renders terrain and uses DXUtil. Using that (and their inbuilt FPS/frame time function), I seem to be able to render my entire terrain (which is a relatively complex mipmapped terrain of 4096x4096) as fast as 1.25fps. When I'm not looking at the terrain (it uses a quadtree), I get down below 0.5ms/frame.

My other engine which is my 'real' engine doesn't have the terrain and has just some test objects. But even with no objects, my raw frame time is well above 0.6ms. I was just wondering if the DXUtil framework was doing anything special - it isn't as far as I can see.

Data that's collected from profiling non realistic situations isn't often useful.

If your target framerate is 60, then your frame time budget is 16.6ms. If you're then profiling something with a frame-time of 0.6ms, that's a situation that's different to your target by a factor of 27 times. The amount of error that's going to be present when you interpret your data with regards to your 60fps target, is likely to be around the same factor.

In other words, add all the other features, then profile again. It's possible that in your micro-benchmark, the stuff you're testing is taking 0.6ms / 4% of target, but in an actual realistic benchmark, it only takes 0.06ms / >1% of target, or it begins taking 2ms / 12% of target... Always do performance tests with a real workload.

The behaviour of Present in particular is highly dependent on the amount of GPU work that's being performed. Micro-benchmarks aren't likely to be meaningful.

Apart from what's being said above (i.e. this benchmark is pretty useless):

The GTX560M has a theoretical raw fillrate of 18.6 GPS (which does not account for stalls, DRAM speed, driver work for allocation and such, OS scheduling, and other things), and a theoretical peak memory bandwidth of 40GiB/s.

You are attaining a fillrate of 3.3 GPS times 3 including DWM, respectively 9.9 GPS, and you are touching and copying 39.8GiB/s of memory.

In other words, you're attaining 50% of the theoretical raw maximum fillrate and practically 100% of the memory bandwidth.

Considering the fact that your CPU (being a mobile CPU in a laptop) almost certainly does not run anywhere close to its peak frequency with only one thread being busy this is a really awesome result. What else do you want?

Also note that glClear doesn't exactly "clear" the screen as such. Looping over each viewport pixel is slow, so the driver optimizes it with hardware flags: when the pixel in question is actually needed, that's when the "clear" happens. The practical upshot is that measuring glClear by itself isn't actually meaningful as a "frame".

I seem to be able to render my entire terrain (which is a relatively complex mipmapped terrain of 4096x4096) as fast as 1.25fps. When I'm not looking at the terrain (it uses a quadtree), I get down below 0.5ms/frame.

This is a much more genuine benchmark, and, at a guess, I'd say you're CPU-bound. I'm guessing you're using ~33.6M triangles, which on a 560M should be easily interactive, if not fully realtime. On my 580M, a naïve implementation (no quad strips and in immediate mode via display list) runs at 8.5 fps. With 4096 quad strips, I already get 44fps worst case.

You need to do some heavy processes in that render loop. Then you'll see if that frame rate is going to hold.

Some really interesting replies guys, thanks. I made a mistake in one of my posts, my terrain renders in betwern 1.25ms and 2ms, not 1.25FPS as I said - that really would be super slow! I think my terrain is ultra efficient so no problems there.

The main point of my post was that DXUTIL seems to be able to render nothing faster than I can.

I know I shouldn't be profiling yet, but when the engine is fully loaded and I'm nearing that 16.6ms, I may need that extra bit and I was just curious as to whether DXUtil does something special.

Thanks

The main point of my post was that DXUTIL seems to be able to render nothing faster than I can.

as a framework, one would expect it to be no faster, and possibly slower than the minimum required straight forward code.

I was just curious as to whether DXUtil does something special.

Its just a framework for writing directx games. inside, its just directx calls, wrapped up in a "on this event" callbacks type architecture.

you can take a look at the code in it for stuff you're working on to make sure you're making the correct calls.