An input lag investigation

[Tatsuya79]

Did some more tests.

In short, d3d11 is similar to glcore and vulkan with gsync, around 30ms.

More surprising, in windowed mode, bottom of the screen, it’s on win7 aero is enabled, gsync enabled for fullscreen mode only, same fceumm smb run ahead 1 frame (to get a 1 frame minimal internal lag):

windowed glcore default 11 10 9 11 9 8 10 9 12 11

10 = 42ms

windowed hardsync 0 frame (in case it does anything for nvidia drivers) 7 12 8 8 8 9 10 8 11 11

9.2 = 38ms

windowed vulkan 9 12 7 9 9 10 9 10 9 7

9.1 = 38ms

Around 40ms while fullscreen without gsync was giving 84ms (probably triple buffering with default nvidia drivers settings)…
Aero isn’t so bad in the end, most probably because my default monitor refresh is 120hz (or gsync helping with screen composition).

[Tromzy]

So, it means that with my Gsync monitor, I don’t need Frame Delay ?

[Tatsuya79]

Yes, you can drop it back to 0.

[GemaH]

Something must have changed because Duke Nukem 3D on Beetle Saturn + gsync monitor felt way more laggy to me than the same game on my real Saturn + CRT. Although i am still on RA version 1.9.6.

[GemaH]

I can’t measure the lag on the real machine. All i can say is that it didn’t feel as sluggish. I could feel the difference is what i’m saying and it was definently not a placebo.

I even tested the beetle emulator on a CRT monitor and it wasn’t much different than the gsync monitor, so the extra lag doesn’t seem to be from the screen.

I think the emulator is adding about 3 frames of lag on top of everything. Im basing this on Sonic Jam and EWJ2 vs the same games on Genesis with GenesisplusGX. All games have 1 frame of lag on GenesisplusGX but 3 or 4 frames on Beetle Saturn.

[GemaH]

Im not arguing the Saturn might have higher input lag than the Genesis. But the Saturn emulator definently has higher input lag than the real console.

Also, the input lag in the Mupen core seems to be on par with the real console. Some games have up to 4 frames of lag but others like Smash Bros have zero lag, which means the enulator doesn’t add any additional lag.

But i haven’t found a Saturn game that has less than 3 frames of lag on Beetle Saturn, which makes me think it adds that amount in all games no matter what.

[aorin1]

@burner

I think someone would just need to test a few of the same games on their Saturn console with the OEM controller hooked up to a CRT and compare to previous gen and to RetroArch

This is exactly what I was thinking earlier today, I’m not sure the console has this amount of input lag. It would be a definitive way to tell the difference.

[trnzaddict]

I am confused now, I thought vulkan was supposed to have the lowest input lag of all the video drivers? Your tests show GL is more responsive and DX11 is as well?

Weird.

[hunterk]

it’s all very driver-dependent. vulkan and d3d11 are usually similar.

[Awakened]

@burner

In general, the video driver isn’t a big difference except avoid Vulkan, which seemed to add anywhere from 1-3 frames extra of input lag; it seemed to be like skipping frames or something, I’m not sure.

If you have have Vsync off in RetroArch with Vulkan, you don’t get proper frame pacing, so you need to leave it on. I don’t think there’s any benefit turning it off for other video drivers either. On Nvidia cards people recommend setting Vsync on globally in conjunction with Gsync, so that games never go above your refresh rate and tear (I usually leave in game Vsync on too unless that particular game has some issue with it on). However, doing that will disable fast forwarding in the D3D drivers in RA, so you can set the retroarch.exe profile to use “Application Controlled” to get around that. I’ve never seen recommendations for AMD hardware VRR settings, so not sure what’s best there.

Borderless window is usually bad for Gsync support too, since Nvidia’s windowed mode Gsync often doesn’t work right or at all. Exclusive or flip model fullscreen modes are the best with Nvidia hardware.

[RealNC]

@burner

I am never going to be using V-Sync as I have a FreeSync monitor

V-Sync is required in retroarch for proper VRR.

[RealNC]

https://www.libretro.com/index.php/upcoming-retroarch-1-7-4-sync-to-exact-content-frame-rate-ideal-for-g-syncfreesync-users/

Note:

Keep V-Sync active in Settings -> “Video” , it won’t work with it disabled.

[RealNC]

I don’t know if something changed since then. But vsync doesn’t have any negative effects with VRR since the display refresh rate is higher than the target FPS of the emulator. Well, at least with g-sync. I don’t know if freesync works differently, but with g-sync, vsync doesn’t add any latency whatsoever when FPS is lower than maximum display Hz and it protects against temporary tearing in case of FPS hiccups.

There’s really no reason to disable it. I haven’t dived into the source code of how RA uses vsync, but it wouldn’t surprise me if it’s used for correctly syncing video and audio and audio time stretching.

[Tatsuya79]

Retroarch isn’t your average PC game, it does stuff in a particular way.

All your results are really suspicious, I assume frames are randomly skipped, be it on execution or video recording / media player next frame counting.

Frame delay being inoperative when using VRR is the only thing I noticed too.

[Ryunam]

@burner

For example, a game like Dark Souls 2 SotFS actually gets 4 in-game frames lower input lag in borderless (you have to use something like Fullscreenizer since there is no borderless option) than full-screen.

This is entirely off-topic, but can you expand a bit on this latency difference that you have observed with Dark Souls 2? I’m playing that right now and I’m using Fullscreen + V-Sync OFF + Scanline Sync with RTSS to minimize latency. It’s working nicely so far, but now I’m wondering if there’s an even better way to shave off some extra frames.

@burner

I have issues with Vulkan freezing anyways, and with the frame skipping and higher input lag, I think I will just not use it unless I have some need to for better performance.

Speaking of your issues with the Vulkan driver in RA, ever since the bug with the RTSS layers got resolved in the last beta versions of the app (see here for further reference: https://github.com/libretro/RetroArch/issues/9668), I have not noticed any oddity with the frame pacing. That being said, I’m not using a VRR screen and I keep V-Sync active with RA, so it could be that there is still some inherent issue with Vulkan and variable refresh rate situations.

[vanfanel]

@burner

What OS/APIs are you using? I found that smallest input lag is possible on GNU/Linux in KMS/DRM mode, Vulkan video, max_swapchain=1, no vsync, ALSA audio with 32ms or smaller buffer.

[yuuyuubaishu]

I agree.There is just with poor performance using kms.In face lakka uses KMS,too

[GemaH]

Sync to exact content frame rate is a godsend.

However it needs to autodetect if the panel you are using is gsync/freesync or a regular 60hz.

I have 2 screens and everytime i switch i also have to manually turn the feature on or off. Both screens will stutter if you don’t have the correct setting, which is ON for the 240hz gsync monitor and OFF for the 60hz TV.

[Brunnis]

I’ve actually done quite a lot of testing with Frame Delay and it always seemed to produce pretty much exactly the expected result (i.e. input lag reduced by the corresponding number of ms). I did all my testing with the RetroArch gl video driver and vsync on. No idea what’s going on in your tests. 12 ms should be easy to detect with a 240 FPS recording. How many recorded samples do you use for producing a result? I usually use at least 20 samples to get a sufficiently stable result.

[Tatsuya79]

14ms average seems REALLY short.