Hi,
Is there a final answer on Input Lag GL vs Vulkan on Windows 10 ? Is it hardware dependant (ATI vs Nvidia) ?
Thank you
Bubs
Nope, no final answer yet. New tests should be done on both AMD and Nvidia hardware with the latest drivers. Unfortunately, I now have very little time for such tests and I no longer have any (modern/supported) AMD GPUs.
1 Like
Brunnis for 240p output on rpi3, do you recommend dispmanx and some frame delay to get input lag as low as possible? What about USB polling rate, could that effect things as well?
I haven’t personally used 240p output, but the same setting recommendations should apply, i.e. DispManX for lower input lag. Frame delay will provide an improvement as well, but may not be feasible if you run any kind of demanding workload. Higher USB polling rate will improve the input lag, if you can get it to work reliably (I haven’t tested it myself).
Do you know how to change the usb polling? My friend is trying to do it now. Is it something in Retroarch itself?
FYI this is now controllable with the HW bilinear filtering option (video_smooth). can be removed in original post 
I saw it posted somewhere that if you are using hard gpu sync, there’s no reason to touch the frame delay settting. Is that true or is there still a use for frame delay on conjunction with hard gpu sync?
Thanks! I see hunterk made an edit about that.
Those settings are not related to each other. Frame delay will still work the same, whether hard GPU sync is used or not.
[quote=“Bahn_Yuki, post:478, topic:4407, full:true”] Do you know how to change the usb polling? My friend is trying to do it now. Is it something in Retroarch itself?[/quote] No, sorry. I haven’t dabbled with that yet.
@Brunnis: I think I have found a way to cut a frame of input lag with GLES on the Raspberry Pi using the Broadcom graphics stack (dispmanx+GLES). It comes from this idea I had and talk with popcornmix of Pi kernel fame:
I would like you to test this new idea, I have a RetroArch repository with it’s implementation here:
I have also uploaded a test binary (for Pi3) here, in case you don’t go into the building process:
So, Brunnis, can you apply your magical LED & camera equipment and test vs plain dispmanx, etc? Simply use the GL driver: should have the same ammount of lag than the plain dispmanx driver now. Thanks!
2 Likes
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.