Game optimizations

[Boop]

I play a lot of games with the lowest settings possible for low input lag and consistent frame times. In games such as Diabotical, Quake, Valorant, Overwatch, I will typically see around 30-60% GPU usage, but not see a single core or thread on my CPU at 80%+ usage. I have no problems maintaining 300+ fps in most cases, but what prevents the game from taking advantage of the remaining system resources? I guess ram speeds and possibly storage could be another bottleneck in this scenario.

Apologies if this seems like a dumb question. Really just trying to get a deeper understanding.

[jorimt]

I play a lot of games with the lowest settings possible for low input lag and consistent frame times. In games such as Diabotical, Quake, Valorant, Overwatch, I will typically see around 30-60% GPU usage, but not see a single core or thread on my CPU at 80%+ usage. I have no problems maintaining 300+ fps in most cases, but what prevents the game from taking advantage of the remaining system resources? I guess ram speeds and possibly storage could be another bottleneck in this scenario.

Apologies if this seems like a dumb question. Really just trying to get a deeper understanding.

High utilization is great, but so long as the given game doesn't have a serious internal bottleneck, more overhead is even better.

If utilization is too high on the GPU-side, your system becomes GPU-bound and system latency increases. On the flip-side, if utilization is too high on the CPU-side, it can throttle itself and plummet frametime performance.

What's important in your use case (where performance is prioritized over visual fidelity), is that you're reaching an acceptable framerate for your given resolution/refresh rate.

30-60% GPU and ~80% CPU utilization (I assume with uncapped V-SYNC off) is actually more ideal than not.

As for why this occurs, it's system and game dependent. But for one, since you're reducing all the graphical effects to minimum, it's leaving most of the work to the CPU. In this case, you should only worry if the CPU usage is in the 20's. If you were pushing the GPU by upping graphical effects, this would typically reverse, e.g. GPU would be in the 80's to 100%, and the CPU would be in the 30%-60% range (depending on the core count, and whether you had a form of HT enabled).

[Boop]

One example of a game allowing you to use 100% of a CPU core is Quake Live. If you set cvar "com_idleSleep 0" then the game will lock a single CPU core at 100% the entire time for the game thread.

Description of the command: com_idleSleep (0: full cpu usage while waiting for next frame, 1: (default) lower cpu usage if there's time available between frames, 2: same as 1 with debugging output)



I'm assuming modern game engines are more efficient and would rather have your cores idle between frames to save on power. In the case of Quake Live, using "com_idleSleep 1" causes your FPS to jump around a lot more and not stay locked at 250fps like it would when using "com_idleSleep 0".

[RealNC]

I implemented something like this a couple months ago (for a RetroArch emulation core.) When you need to either time something, or wait for another thread/core to finish its work, you have basically two choices. Sleep for a certain time period or until the other thread has finished, or check the current time or the other thread's status over and over again to determine if enough time has passed yet or the other thread has finished.

Sleeping puts the CPU core to... sleep. That means the power management of the CPU core kicks in. The CPU core doesn't wake up instantly though after the CPU load rises again. It can take some time. This results in FPS fluctuations.

If you don't sleep but instead run code that constantly checks if it's OK yet to resume, then this will prevent the CPU from powering down. The code itself that does the checking is preventing the CPU from powering down because the CPU has to constantly run that code. Thus, less FPS fluctuations as the CPU is constantly operating in its fastest power mode.

Games usually don't want to prevent the CPU from powering down, so they choose the sleep method. This is because this really only becomes a big issue if the game is very light on the CPU, and thus you get high FPS anyway. FPS fluctuations at very high framerates isn't really an issue. If the game is heavy on the CPU, then it doesn't have much time to power down anyway.

Edit:

An additional factor that results in some FPS fluctuation with code that sleeps is the timing itself. When you want to sleep for, say 3.7ms, you usually don't get to actually sleep for that exact amount of time. That's because the operating system itself doesn't provide the timing accuracy. Windows for example can support an accuracy of 0.5ms at best, but usually it's difficult to even reach that. Windows (or Linux, or macOS) aren't real-time OSes. There is going to be some fluctuation in the timing accuracy, so this alone adds a bit to frametime fluctuations, and thus FPS fluctuations due to these timing inaccuracies in the whole chain from the game itself to the OS and drivers.

If you don't sleep but instead run code that constantly checks, the timing accuracy is greatly increased, because you're measuring the time yourself rather than rely on the operating system's timing.