12
\$\begingroup\$

I have been unlocking the framerate in MonoGame via:

this.graphics.SynchronizeWithVerticalRetrace = false;
base.IsFixedTimeStep = false;

And using it as a basis for how efficient I am updating and drawing in the game.

At a resolution of 240 x 160 with nothing being drawn or updated except a frame counter I get an FPS value of 9,000 to 11,000 FPS.

If I add all my code back in it drops down to about 1,100 FPS.

Is this a good indication that my code is significantly slowing the GPU down (10x), and should I be concerned? The game is going to run at 60 FPS so I'm still pretty far away from that, but at what point in the unlocked frame rate should I be concerned?

GPU: AMD FirePro W5000 (FireGL V)

Improve this question
\$\endgroup\$
2
  • 1
    \$\begingroup\$ As a side note: In your development path, I would suggest you keep your target FPS in debug as well as in release; something could run well in release but could be slow as hell in debug, which is really not useful :) \$\endgroup\$
    – Vaillancourt ♦
    Sep 30, 2015 at 21:46
  • \$\begingroup\$ Not really. Other answers answer this well, but the main point is that most of the heavy lifting will be done by your graphics card using hardware acceleration. Unless you're doing work in the same thread as the graphics (you shouldn't be), then there's no reason for for FPS to be impacted by your code - within reason - at all. \$\endgroup\$
    – Dan
    Oct 2, 2015 at 7:23

2 Answers 2

Reset to default
30
\$\begingroup\$

Only crudely.

First, FPS is a not a linear measure. The difference between 11k FPS and 9k is extremely small (0.0000201 seconds per frame). But the difference between 60 and 2060 FPS (a 2k FPS delta, the same that exists between 11k and 9k) is 0.0161 seconds... much larger. It can thus be dangerous as a performance metric simply because large differences may or may not be that bad.

Using time-per-frame instead is a little easier to reason about, but even then it's still a very broad view of the situation. It just tells you how many seconds one frame of the game takes. It doesn't tell you why, unless you look at a large increase in frame time immediately after adding or enabling one particular feature.

It can be a basic barometer for deciding it's time to do more in-depth profiling. It's particularly bad to use FPS to determine if you are CPU or GPU-bound; GPU profiling isn't so easy as measuring time on the CPU (which is where your timing and FPS-computation code probably is).

As for when you should be concerned... well, you said yourself the game was targetting 60 FPS. If you start dipping near or below that, then you probably need to start thinking more carefully about your performance issues. Until then, I'd focus on making everything work and then worry about making it fast.

Improve this answer
\$\endgroup\$
3
  • 6
    \$\begingroup\$ +1 for the last sentence. Premature performance optimization is, in my opinion, a pretty bad practice (speaking from experience). \$\endgroup\$
    – sirdank
    Oct 1, 2015 at 12:08
  • 1
    \$\begingroup\$ c2.com/cgi/wiki?PrematureOptimization - Recommended read on the subject \$\endgroup\$
    – Machinarius
    Oct 1, 2015 at 20:49
  • \$\begingroup\$ Not always, if you have a high end machine and it gets around 80 FPS, then it would be good enough on your machine, but if you wanted to target lower end computers, they might only get 15 FPS, Ideally, it would be best to do your testing on a machine with the minimum specs you want to target, but failing that, optimizing it for your machine may optimize it for theirs too. Of course, if it runs fast enough on your low end machines, then there is no reason to spend extra effort to optimize further, especially at the risk of increased bugs. \$\endgroup\$
    – Programmdude
    Oct 2, 2015 at 10:53
5
\$\begingroup\$

I don't see why you couldn't use it! Keep in mind that you may have to code differently to account for the differences between fixed/variable timestep, so if you're planning on making it fixed when you release, you'll need to make adjustments. See this article: http://rbwhitaker.wikidot.com/time-steps

Is this a good indication that my code is significantly slowing the GPU down

Could be the CPU as well. I'd recommend periodically running Visual Studio's built in profiler (or whenever you see a large framerate drop) to find hot spots in your code.

should I be concerned?

That obviously depends on the hardware you're targeting. You'll need to test your code against the lowest minimum requirement machines you're willing to support. If it runs at least 60 there, then I wouldn't be too concerned.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .