# Is my frame time too high?

This topic is 1650 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi all

I was just checking the raw frame time of my engine (with no draw calls being sent to the card, only Present, etc) and I'm currently running at about 0.60ms (roughly 1666fps).

I'm using a laptop which is an Intel Core i7-2670QM @ 2.20GHz with 8GB on Windows 7.  My video card is running at 1920x1080 and is a GeForce GTX560M with 4GB mem.

When it comes down to it, I'm not really doing an awful lot more than just clearing the z and colour buffers and a present.

Does this sound too high?  I've read previously about people getting crazily low frame times, like 0.2ms and below.

##### Share on other sites

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).

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites

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?

##### Share on other sites

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.

Edited by Geometrian

##### Share on other sites

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

##### Share on other sites
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

##### Share on other sites

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.