That sounds awesome, vanfanel! Unfortunately, I won’t be able to test this right away. I have my Pi loaned out at the moment and I’m also very short on time since I became a father (of two!) a few months ago and also have a lot going on at work. I’m not saying that I won’t test it, just that I might not be able to do it for several weeks… 
Hey Brunnis! Congratulations on the family growth! 
Don’t worry, test it when you can, no hurries.
Thanks!
In the meantime: If you have a phone or other camera with at least 240 FPS recording, you can get some decent results by filming the controller from the side (in front of the screen) while quickly tapping a button. I also found out yesterday that there’s an iPhone app called “Is It Snappy?” that makes it possible to pretty quickly make the frame analysis on the video and calculate the resulting lag directly on the phone.
By the way, if this works, the regular GLES driver and max_swapchain = 2 will provide the same input lag as dispmanx and max_swapchain = 3. However, performance will be much worse for the former case than the latter. And dispmanx can of course provide a further decrease in input lag by also using max_swapchain = 2.
At least that’s my understanding, correct me if I’m wrong.
Does the new upsteam higan sfc core have an extra frame of latency compared to the other SNES cores? I assume it doesn’t have Brunnis’ fix, but I’m just curious if anything changed upstream or if the way maister did the port was better latency wise.
If it does, I hope the retroarch core can add in Brunnis fix if it’s not to difficult.
It has more lag yes, just like before the fix.
It won’t be getting any core changes from us, as we don’t want to cause any trouble/resentment/whatever.
And please don’t go hassle byuu about it. He’s made it clear that it’s as responsive as it possibly can be (and he’s not interested in hearing otherwise) and others on his forum have blamed libretro in general and the v094 libretroization in specific for any unnecessary latency (despite all of Brunnis’ changes touching core files and not the libretroization), so we’ll just have to accept it as it is. There’s always snes9x, if needed.
EDIT: sorry, this post seems to have caused some misunderstanding, which was exactly what I was trying to avoid. I’m not saying Higan has any issues with latency. See Brunnis’ explanation a few posts down for a potential explanation of the discrepancy. Higan is a great program on its own, and I’m excited that we were able to come together and make it available for RetroArch users, as well. I didn’t want something this minor to derail our partnership by having well-meaning users open old wounds, but it seems I’ve done that on my own inadvertently. Oh well 
Yeah, that’s fine, I’m just happy to have an upstream core. I was testing the 105 accuracy core with hard sync frames 1 on MMX2 and SMW with frames 0 vs. both on Mercury Balanced with frames 0 and I don’t think I could personally feel/see a difference on my monitor.
It’s always good to have more options 
You should see if you feel a difference with Snes9x 0 frames and 8+ frame delay.
Yeah, I agree that we shouldn’t try to get the “lagfix” into the higan core. The memory of my thread over at byuu’s forum last year is still far too fresh in my memory to want to engage in anything like that again.
The extra lag definitely comes from the higan implementation. The thing is, though, that it doesn’t seem to matter in higan standalone, due to the fact that it doesn’t run the emulation in discreet frame chunks like RetroArch. Although I’m not into the details of the implementation, I believe it instead runs the emulator for x number of lines, exits and syncs time, runs another x number of lines, etc. By running the emulation closer to realtime, higan standalone doesn’t run as far ahead as it would if it was just generating a single frame as fast as the system allows. This means that the point at which the emulator signals a ready frame isn’t as critical as when you’re only syncing on frame boundaries.
Just curious, what snes emulator do you use mainly now snes9x or mercury?
I use snes9x. The reason for that is that it allows me to use additional frame delay to improve input lag. I haven’t found any noticeable inaccuracies in the games I play, so I think it’s an okay tradeoff.
Ya you’d need a very powerful cpu to use 8+ frame delay on any version of higan. At least snes9x and higan share the same LLE audio.
@Brunnis: Let’s say we have both “GLES on dispmanx” and “plain dispmanx”. With max_swapchain=2 in both cases, and assuming the “GLES on dispmanx” driver has a working max_swapchain=2 implementation. Are you saying “GLES on dispmanx” will have an additional frame of latency on that case? I don’t understand why: that should not happen, because “GLES on dispmanx” waits for vsync to happen after it issues a flip. No way one more frame of lag would be introduced.
I did a new implementation of “max_swapchain=2” and it’s now merged. That’s the one you should test: mainline RetroArch with “GL” driver and “max_swapchain=2”. I am almost 100% sure you will find the same input lag as in “plain dispmanx” with max_swapchain=2. That or there’s something here that I am missing 
Also, I would say performance is the same.
Maybe I’m confusing things… Dispmanx + GLES with max_swapchain = 3 isn’t the same as using the old BCM GPU driver as I’ve done in my previous tests? Just trying to understand the terminology. Because the BCM driver seems to have an additional frame of built-in latency, that, for example, is not there on plain Dispmanx or VC4.
This is an example of how it has looked in previous tests I’ve done:
- BCM (GLES): 7 frames
- Dispmanx + max_swapchain = 3: 6 frames
- Dispmanx + max_swapchain = 2: 5 frames
- VC4 + max_swapchain = 3: 6 frames
- VC4 + max_swapchain = 2: 5 frames
@Brunnis would you mind editing your last post in order to clarify a few things about the data?
- what game & emulator core are those frame numbers for (yoshi’s island and snes9x2010 i presume?)
- does VC4 refer to the (still) experimental mesa opengl driver or the kernel drm driver?
- Those numbers are just an example of the relative differences, but, yes, they are typical values that I saw when testing Yoshi’s Island with Snes9x2010.
- The DRM driver.
-Yes, “Dispmanx + GLES” = “GLES using the old BCM driver” (Sadly still default on Raspbian… I HATE that fact).
-With the latest RetroArch GIT, I have forced the driver to wait for vsync after issuing a flip. I believe in your test results, of course, but as things are now, there should NOT be any more input lag frames on “Dispmanx + GLES” than in “plain Dispmanx”. All with max_swapchain=2, of course.
Are there any new recommendations for minimal Lag on a Pi2 or Pi3 with RetroPie? Or are these still valid:
- video_driver = “dispmanx”
- video_vsync = true
- video_threaded = false
- video_frame_delay = 0