Fuck off. I posted a video made with OBS. That not good enough for you? Seriously, fuck off.
1 Like
Yeah, I’ve tested a PAL SNES with LED rigged original controller and I also asked the author of Is It Snappy? to test his NTSC SNES. This was years ago. The input lag is still dependent on where you are located on the screen. Once you know the behavior of the real console and the internal latency of the specific game, the resulting lag is easy enough to calculate.
I didn’t have to adjust my method to fit my results. I know since previously how the real console performs, but wanted to show how/why I had setup the Pi 4 to perform the same. I did it the proper way and made an hypothesis of where the Pi 4 ”should be” given my settings. I then went on to test my setup and arrived at these results without having to ajust anything.
I’ve probably run thousands of input lag tests through the years (this is ”my thread”, as you may have noticed). I have a pretty good handle on it at this point.
1 Like
As i said, that’s not true, my setup run vulkan at 60fps without enabling vsync. Your 30fps issue might be a windows thing (i’m using linux, @RealNC too), i don’t know. Please reflect on your behavior and how you make fun of people who don’t experience your issues, toxicity isn’t welcome here, that’ll be my only warning.
On a sidenote, if there is really an issue preventing vulkan to run above 30fps on windows without vsync, that’s something that should be reported at https://github.com/libretro/RetroArch/issues
In the video he posted, the game was running at 60fps. There was no 30fps lock.
Yeah, it’s definitely a thing on Windows. Besides myself (with an Nvidia GPU) I’ve seen a few others report choppy framerates with vulkan and Vsync off in Windows. Mainly on Discord. I don’t experience any downside to having it enabled with Gsync, so it doesn’t bother me.
If that’s a RA bug and not something common to all vulkan applications running on windows, someone should definitely report this at https://github.com/libretro/RetroArch/issues
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
@vanfanel : Hi ! I’m sorry to hijack the topic but I’ve been following it for years 
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 
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.
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
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
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)
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.
Oh no, no war please
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.
Thanks a lot for the kind words, vanfanel. 
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:
- How does Vulkan + max swapchain 1 + no vsync not generate tearing? Isn’t this basically running single buffered?
- 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.
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!
Regarding the new Automatic Frame Delay setting, if this is enabled what should the Frame Delay setting be set to??
• 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.
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??
shouldn’t be an problem. That is, that’s what the automatic part does is reduces the number if it’s too high.
@hunterk What about the max_swapchains when using VSync on a non-G-Sync monitor? Which one is the best? 1, 2 or 3.