An input lag investigation

[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.

[RealNC]

Maybe you have a frame limiter somewhere (RTSS or nvidia’s in-driver limiter) that messes with frame delay.

Also, I believe frame delay is a method to reduce vsync lag. Without vsync, frame delay does not make sense. What it does it run the emulator’s single-frame tick closer to the vertical sync time (“vblank”). That’s all it does. If there is no vsync, then it makes no sense to use it, I think.

I think this might be wrong. Frame delay could also use the requested emulator core FPS as the target to sync against, not just the vertical sync. Did anyone else measure lower latency with frame delay and vsync OFF?

[RealNC]

@burner

I just want to add that sync to exact content frame rate absolutely 100% does work even without V-Sync enabled

I just tested with vsync OFF, and even though sync to exact content framerate works, the result is jittery.

So I would say it doesn’t work. Yes, the FPS indicator shows “60.1” instead of “60” for SNES games. But without enabling vsync in RetroArch, animation is not smooth. It appears to me RA uses vsync for correct frame pacing. So even though the framerate is correct (60.1 instead of 60), frame pacing is not.

[RealNC]

I use a native g-sync display on Linux with an nvidia GPU. Frametime graph is flat and looks identical to vsync ON. But animation is jittery.

It’s easy to spot during the room transitions in Super Metroid with the Snes9x core, for example. The fast scroll animation when entering a door is 100% smooth with vsync on. With vsync off, I can clearly see jitter. It’s harder to spot with slower scrolling.

This is with the Vulkan driver. glcore is fine.

[RealNC]

@burner

Yeah I’d like to see a test showing that V-Sync is necessary or changes anything with VRR active.

Well, the Vulkan driver on Linux produces jitter without vsync.

[RealNC]

@burner

Vulkan locks the fps to 30 unless V-Sync is activated

It doesn’t do that here: