MrShoor's input lag investigation and solution

[Chebmaster]

My fellow board member MrShoor from gamedev.ru wrote an interesting article in Russian https://habr.com/post/308980/
It investigates input lag - a subject extremely touchy for first person shooters and fighting games.
There he shows that, Vsync or no Vsync, GPU at high loads can sit rendering up to 4 frames concurrently, resulting in a frame arriving at the screen up to 4 1/60s intervals later than you sent it to the video card.

He then shows this using detailed graphs and says that even companies making AAA games often neglect this problem and no API has a built-in solution to it despite the problem being 10 years old.
He then provides 3 different hacks to achieve the same goal: nip this problem in the bud by forcing a CPU/GPU sync. The one that is available in any graphical API, including OpenGL, is generating a 2x2 mip of the render buffer on the GPU, then reading it by CPU.

The test executable (including sources for Lazarus) could be found at https://github.com/MrShoor/InputLagR...leases/tag/0.0
Usage: increase GPU workload until FPS drops to 15..20, then try rotating the cube using the right mouse button
Compare responsiveness without lag reducing and with the 3 methods provided.

I tried it and the difference was *radical* on my i5/HD3000 (a laptop with integrated graphics). Not only that, but chip temperature stayed at 68C with lag reducing on but started growing with it off and reached 72C before the cooling fan switched to a higher speed with a strained whine.

So not only are you making your game more responsive by forcing a CPU/GPU sync each frame, you make it environmentally friendly too.

P.S. I miscommunicated. One of the graphs (an overloaded GPU) shows the true horror: GPU renders one frame in 4 vsync intervals while command buffer contains data for more than 3 frames. What you send to the GPU now would reach the screen 16..20 Vsync intervals later. That's one third of a second worth of input lag! And that's horrible!

[SilverWarior]

I don't speak Russian so I'm not able to read the contents of that article but after playing a little bit with this test executable I'm noticing several problems which contradicts with your explanation of the article:

1. When I run test application and have GPU load slider all the way to the left (the least GPU load) it is reaching 147 FPS. This means that there is no Vsync enabled. I have 60 Hz LCD monitor which means that there shouldn't be more than 60 FPS.
   Also while the GPU load slider is set to minimum test application is maxing out the main thread. So in case of real game this would cause lag on all CPU processing tasks, like physics for instance.
2. If I do as you ask and increase GPU load so that FPS drops down to around 20 I can notice considerable lag when rotating the cube without any lag reduction method selected. The load of the main thread now drops down to about 3.54 % of entire CPU load (approximately 25 % load of single CPU core).
   Lag becomes much less noticeable if I select any of the lag reduction methods. But if I chose lag reduction method "Query event" test application again maxes out the main thread entirely. Other two methods doesn't seem to have much effect on CPU usage.
3. But if I set the GPU load so that test application is reaching 60 FPS I barely notice any or no lag even when no lag reduction method is selected. GPU at this time is at 100% load.
   If I select "SetMaximumLatencyFrame(1)" lag prevention method I don't notice any difference. My GPU usage still stays at roughly 100%.
   If I select "Query Event" lag prevention method I actually notice slight lag probably because test application is again maxing out its main thread. I also see slight decrease in GPU usage of about 4%. I suspect this might be caused because of CPU bottlenecking in this case.
   And if I select "GenerateMips" lag prevention method again I don't notice any lag. And now my GPU load has dropped for about 6% and CPU load stay around 3.5%
4. And if I max out the GPU load there is a huge lag as expected In fact the lag becomes so big that the whole Windows UI starts lagging not just the test application.
   But what seems strange to me is that even with max GPU load choosing "Query event" lag prevention method still maxes out the main thread of the test application. So using this lag prevention method is probably not a god solution due to high CPU loads all the time.

Now how can I test this with Vsync enabled? I don't want to force Vsync for this test application using my graphics drivers since they might affect the results in unexpected ways (not sure if forcing Vsync through drivers only enables Vsync or does something more).

PS: My computer specs are:
AND FX 8350 Eight Core CPU running at 4 GHz
Radeon R9 270 GPU runing at 975 MHz
My computer is running Windows 7 64 Bit

[Chebmaster]

Now how can I test this with Vsync enabled?

No idea, sorry. This thing uses Direct3d 11 but I have ever only studied OpenGL.

is reaching 147 FPS. This means that there is no Vsync enabled

Huh, I haven't noticed because it only reaches 39 fps on my laptop (and dies if I move the slider more than a tiniest silver to the right).

But if I chose lag reduction method "Query event" test application again maxes out the main thread entirely.

Hmm, system dependent, then. No such thing @ Win7 64 + i5 2450M + HD 3000.

Only the mipmap method is available for OpenGL anyway.

[de_jean_7777]

Under heavy load, the input lag is visibly reduced on a win 10 machine. Might eventually implement something like this for myself.