What causes the frame rate to drop down in games?

Discussion in 'Architecture and Products' started by Ameen, May 22, 2010.

  1. Ameen

    Newcomer

    Joined:
    Mar 30, 2010
    Messages:
    4
    Likes Received:
    0
    Hello,

    I was wondering about the FPS issues! Let's say I have a game that is running at 30 FPS, now that means that each frame must take around 33.33 milliseconds on screen.

    Does that mean that I've around 33.33 milliseconds to do all my game calculations and that includes physics, AI.. etc. or does that mean I've around 33.33 milliseconds to draw the next frame before flipping frames.. or does it mean both..?

    My question is what is the things that causes the frame rate to drop down..?

    Thanks guys!
    Ameen
     
  2. catisfit

    Regular

    Joined:
    Oct 27, 2007
    Messages:
    638
    Likes Received:
    0
    It means both. The next frame won't be much different if you haven't run all your AI, physics etc in the meantime as the game state won't have changed!

    You need to run all game systems then redraw everything inside 33.3ms (16.6ms for 60fps) to get the next frame to the screen on time.

    Slowdowns usually occur due to the complexity of each scene being different, so it's mostly a graphical issue. When there's lots to draw/high visibility/a lot going on then you can exceed your frame budget, and not get the next frame drawn in time. When this happens the framerate will drop.

    1) if you're vsynced the framerate drops in multiples of 1/n, so possible framerate for a 60fps double buffered vsynced game are 60fps, 30fps, 20fps, 15fps. This is because the output stalls waiting for the new frame and the old frame remains on screen until the new frame is ready.
    2) if you're not vsynced then the frame will tear, as only the part of the screen you've managed to draw will be updated, the other part will stay as the previous frame as you haven't updated it yet. This means the framerate doesn't drop as noticably as when vsynced (you could have an instantaneous effective framerate of 59.9fps, for example) but it introduces a tear where the two frames don't match up which can be visually distracting.

    You can implement a dynamic framebuffer to scale back the rendering demands when the game detects that the framerate is suffering, which I believe is a great compromise but is non-trivial to implement. The alternative (and how 99% of games work) is to make sure the most complex scenes can be rendered inside the frame budget, which means for most of the other scenes there's spare capacity in the frame budget which could have been spent on a few more pixels/effects to improve the overall IQ.
     
  3. Ameen

    Newcomer

    Joined:
    Mar 30, 2010
    Messages:
    4
    Likes Received:
    0
    Thank you so much for this satisfying answer!
     
  4. sebbbi

    Veteran

    Joined:
    Nov 14, 2007
    Messages:
    2,924
    Likes Received:
    5,293
    Location:
    Helsinki, Finland
    It's also important to note that the CPU does not wait for the GPU after each draw call (and vise versa). Both do their processing at the same time (so both can use full 0.33 ms to finish their work, the time budget is not split in half). The GPU runs asynchronously by executing commands from a command buffer. The CPU starts processing the next frame slightly before the GPU has finished rendering the frame. This way there is always commands to process in the GPU command buffer, and the GPU never has to wait for the CPU (in the most optimal case).

    CPUs with multiple cores (all new PC processors, PS3 and Xbox 360) can naturally use 0.33 ms of processing time on all of their cores. The total CPU time required by a single frame is the time used by the core with the longest processing time. So it's crucial to load balance the work well to get most performance out of the multicore CPUs. For example in some really physics heavy scenes (lots of things breaking up at once), the CPU core processing physics might cause some frame dropping.

    In current generation games the most common causes for performance drop spikes are graphics (usually heavy particle effect overdraw) and physics (usually lots of complex things happening simultaneously). It's often difficult to predict that the next frame will be more complex than the previous one, so using a simplified graphics / physics model is often not feasible.
     
  5. IdaGno

    Newcomer

    Joined:
    Jul 27, 2007
    Messages:
    11
    Likes Received:
    0
    thinking is hard! - Barbie

     
  6. Ameen

    Newcomer

    Joined:
    Mar 30, 2010
    Messages:
    4
    Likes Received:
    0
    I see now!

    But wow, you must construct a whole frame in this show period of time!
    Any ideas how to developers figure out their frame budget of their engines..?
     
  7. Davros

    Legend

    Joined:
    Jun 7, 2004
    Messages:
    15,845
    Likes Received:
    3,053
    they benchmark
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...