An input lag investigation

RetroArch General
#963

Hello again, Brunnis

It’s a pleasure reading you again. Your reports are most welcome here, and they are like fresh air now that certain toxic individuals are trying to pollute this much needed thread with strange Windows/NVidia findings (pure nonsense if you ask me, because a closed source driver on a closed source OS makes anything impossible to be diagnosed, who cares about a fully-closed ecosystem? Who knows what absurd software is it running?).

That said, since we both used to make the most of our Pis in the past, have you tested the Vulkan driver? It’s getting mature and it’s indeed faster by now. Using RetroArch with Vulkan, you can safely disable VSYNC (no special g-sync monitor needed or anything, your old trusty one will do, and you won’t get any tearing) and set max_swapchain to 1. Remember that: Vulkan, VSYNC OFF, max_swapchain=1. Magic, really. Use latest MESA for this (2.3.0 as of this writting). Keep using ALSA for audio, and you can also take the audio latency down to 32ms, use 44100Hz audio and adjust internal audio rate on the emulators accordingly (in FBNeo, for example) so no internal audio resampling has to be done.

You will be surprised by the results with regards to performance and input lag in out beloved working-class microcomputer!

If you need any help for MESA building etc, ask and I will humbly try to help as much as I can. You are the original master in the input lag front testing.

2 Likes
#964

@vanfanel : Hi ! I’m sorry to hijack the topic but I’ve been following it for years :wink: Am currently using RA from a common Linux distro / x86. I’m wondering if it’s possible to use the KMS version of RA without disabling the X server (or Wayland) ?

Also, on this very machine, I’ve just tried Lakka (regular X86 PC, amdgpu Vega 8, open source drivers) and, I do get a smooth scrolling with no VSync / swapchain 1 / vulkan, and it automagically switches to the right frequency, that’s great (50 Hz on the Amiga for instance) - while on X I have to add cores overrides and cannot disable vsync, etc. But there are tons of graphical artifacts and the display explodes in a couple of mins (flickering lines / green screen / black screen). Probably related to the amdgpu driver.

So much progress lately ! (runahead, auto frame delay, KMS, vulkan, improved cores…) Not sure I need my FPGA machine anymore.

Cheers :slight_smile:

#965

Thank you for pointing that out. I do hope that people learn not to rely on closed sourced software, because of reasons such as that. We should make Open-source hardware & software a priority, why keep bending over and troubling ourselves with closed-source bs.

Also what exactly is everyone gauging their their results on? It seems like some are using a flawed way of going about it. I wish this issue was properly addressed, but now it has a toxic air to it here instead of a community working together to solving a problem. I can’t even follow this thread anymore because it’s been devolved into misinformation and bickering.

We should be providing as much technical specifications and info for our findings. You can’t properly troubleshoot an issue with a lack of info.

#966

Hi! I don’t consider your comment a hijack at all, since KMS/DRM is supposed to be the low-latency enviroment by default, and this thread is about low-latency enviroments (which of course can’t be guaranteed or replicated on a sane way on a closed system, so even if someone has low latency results on Windows with an NVidia driver, it has no importance or meaning because it’s an empty achievement no one can technically replicate because we lack any meaningful information, as @Joystick2600 pointed out).

That said, KMS/DRM and X11 are mutually exclusive: you can run a KMS/DRM program on a different TTY, however, without killing the X11 server.

Wayland uses the same interfaces to access the hardware that KMS/DRM uses, so you should have the same latency on Wayland that you would get on KMS/DRM, I guess.

Wayland is great for desktop systems and KMS/DRM is for embedded-like GNU/Linux scenarios, where a machine runs RetroArch or any SDL2 games (SDL2 also supports KMS/DRM but libretro/RetroArch is WAY better for emulation) and nothing more.

So, if you want to have a desktop on the same system installation where you use your emulators, use Wayland. If you are like me and don’t need a desktop system to play, use KMS/DRM. That’s what I can recommend you :slight_smile:

About FPGAs, well, I love both RetroArch on KMS/DRM on a system booting in 1 second without ANY services (only GNU/Linux makes it possible!) but I also love FPGA solutions. Hardware replication is beyond awesome, even if for playing MegaCD all you need is a Pi4 with RetroArch on KMS/DRM and a single buffer configuration without vsync.

@Joystick2600 Let’s reconduce this important thread then! It seems the Windows/NVidia person polluting it has got tired at last. If we ignore toxic people, it can be a great source of information again, now that sir @Brunnis is at it again!

1 Like
#967

The lowest latency environment tested is on a Windows PC, it’s as simple as that. This is just dependent on your settings and your hardware configuration, so the notion that this “can’t be guaranteed or replicated on a sane way on a closed system” is absurd.

The elitism in here is honestly quite embarrassing, especially when Linux is not yet a realistic or viable option for general gaming, and only accounts for about 1% of the gaming market (according to Steam surveys)

#968

This isn’t about elitism, this is about you trolling someone for no reason, aside from being narrow-minded.

And who cares about what steam says ? Who talked about general gaming ? Linux is a very popular platform for emulation, especially with all the linux-based projects born over the last decade (lakka, retropie, recalbox, …) and sbc devices (raspberry pi, odroid, …). RetroArch is also available on lots of other platforms (macos, old and new consoles, smartphones, tablets, tv box, …). I wouldn’t be surprised if windows users were actually a minority as far as retroarch usage is concerned.

#969

Oh no, no war please :wink:

As for Linux & gaming, well, it’s never been as viable as it is today – and I’ve been gaming on Linux only for 20 years. But of course there will always compatibility issues, sub-optimal use cases. But well, still, it’s incredible as it is now IMHO.

I’m pretty sure my life would have been easier if I has remained on “the other side”, but, I think it made sense at least.

#970

Thanks a lot for the kind words, vanfanel. :blush:

I did a quick test with vulkan on Lakka a while back, but had some kind of issue. Can’t really remember what, but I think it was something major like getting a black screen when trying to run snes9x… Anyway, this sounds quite intriguing. A few questions:

  1. How does Vulkan + max swapchain 1 + no vsync not generate tearing? Isn’t this basically running single buffered?
  2. Regarding using 44.1kHz, would this make any difference for NES/SNES emulators? (sorry, haven’t really dug into any audio stuff). Is the main reason for doing this to spare precious CPU cycles?

I’ll likely check this out, but it may take a while due to everything else going on these days.

#971

Hi Brunnis!

Vulkan is better suited for exact framerate control, so my theory is that the emulation is running exactly at the framerate of the videomode in use, so there’s no need for vsync. Try it with current stable MESA, my tests a while back didn’t give me SO good results as they give me now.

As for 44100Hz audio, it saves resampling time so it allows for lowest latencies on the Pi4, at least on my tests here.

Keep me informed on your tests with Vulkan + max_swapchains=1 + no vsync, I am sure you will be surprised as I was!

#972

Regarding the new Automatic Frame Delay setting, if this is enabled what should the Frame Delay setting be set to??

#973

• if you set “Frame Delay” to 0 and “Automatic Frame Delay” to ON, the starting point of the delay that is applied to the new frame will be half your “frame period”. For instance, on a typical 60hz screen with a frame time of 16.7 ms, the initial value applied will be “8”, as in 8 milliseconds of delay. Afterwards, if drops or hiccups are detected in the video performance, this value will be reduced dynamically until it reaches a stable point;

• if you set “Frame Delay” to any value higher than 0 and “Automatic Frame Delay” to ON, the starting point will be the delay value that was manually set. For instance, if “Frame Delay” is set to 10, the initial amount of delay for the processing of the new frame will be 10ms. Then, it will be adjusted downwards in case any framerate drop is detected;

So, if you want max frame delay, set it to something very high, like 15. Setting it to 0 will do a maximum of 8 ms, which is honestly probably fine, too, except for the very fastest cores (like gambatte) that can manage even higher.

#974

Thanks, i was having it set to 4 but wasn’t sure if it was having more of a detriment effect or not.

What would the side effect be if it was set too high and the system could keep up??

#975

shouldn’t be an problem. That is, that’s what the automatic part does is reduces the number if it’s too high.

#976

@hunterk What about the max_swapchains when using VSync on a non-G-Sync monitor? Which one is the best? 1, 2 or 3.

#977

1 is the fastest, but some drivers just straight-up won’t give it to you, and even if you get it, you might have stuttery scrolling.

#978

Which is the best of both worlds? The one that gives acceptable input lag and no stuttering, is it 2?

#979

Try it with 1 (your driver may give you 2 anyway :man_shrugging:) . If it’s too stuttery, change it to 2.

#980

Whats the max_swapchain option?, wheres that located and what does it do?

#981

It’s in settings > latency, but it’s only visible with drivers that expose it (vulkan and d3d11/12 IIRC). It controls the maximum number of images that can buffered, which–as with most buffering–is a tradeoff between latency and quality (in this case, smooth scrolling).

1 Like
#982

I have absolutely no idea of the technical aspects behind this great feature, but would it be possible to implement something that makes it increase the frame delay value as long as the game runs without sound crackling or lagging ? For example, if frame delay was set to 0 and automatic frame delay to ON, the starting point would be 8, but as long as the game runs fine, it would go up to 9, then 10, etc. until it reaches the point were it starts lagging ?