Considerable Input Lag Compared to Other Windows Emulators

RetroArch General
#1

In the Windows port of RetroArch I notice a fair amount of input lag compared to other emulators (Mednafen and Kega Fusion are two I tested against) with Vsync on with either of my displays at 60hz. I tried the option to turn off desktop composition since I’ve heard that is supposed to help, but I didn’t notice a difference. Turning off Vsync puts it on par, but that creates too much tearing. At 120hz on my monitor it’s about as low as Mednafen (both emulators with Vsync on), but running at that refresh rate I get stuttering with any emulator I’ve tried.

Nestopia is the only other Windows emulator I’ve ran where the input lag was as noticeable to me.

I’m running Windows 7 64-bit, RetroArch 0.9.9-wip2 and using a Saturn USB pad to test.

#2

You’re not seeing input lag, but video driver lag. Graphics drivers are notorious for buffering too much for sake of performance (to score well in benchmarks), but that’s not something we can fix as we don’t have fine grained control over buffers.

Try different drivers (GL fullscreen and D3D9) and fiddle around with driver settings in control panels.

EDIT: Also, using logic like “but it works in emulator X” does not help (non-constructive). If you think there is a bug in RetroArch you have to explain why the code is wrong and how it can be fixed.

NOTE: These threads tend to get very “religious”, subjective and completely non-constructive from past experience. If there is any sign of shit, I’ll lock and delete posts instantly.

#3

The D3D video driver is worse input lag-wise than OpenGL, but becomes a bit better with Max Prerendered Frames set to 1 in the Nvidia control panel. OGL is still better, but not improved by that driver setting.

I’ve seen a few threads complaining about lag in the PS3 or Android ports, but none for Windows specifically. I’m not a coder so the only frame of reference I have is other emulators. Mednafen seems easiest to compare to since it’s open source and there are a few libretro cores based on it, so I would assume one of the devs would be somewhat familiar with that emulator’s code and be able to see how it does glvsync for comparison.

Input lag is a hell of an annoying thing since only some people seem to notice it at all and there are so many factors that affect it. It’d be a lot easier if I could deal with all the tearing without Vsync on.

#4

I haven’t seen you mention your GPU so far - or the graphics driver you’re using. Crucial information to know when talking about issues like this at any rate.

Like maister said, you are at the mercy of whatever kind of voodoo magic your binary blob GPU driver is doing behind the scenes. We can do nothing about it. On PC you don’t have any kind of fine grained control over your GPU (like you do on a PS3 through libgcm and on systems like Wii/Xbox 1/360 - where you can set up your own command buffers and do your own custom swap implementations instead of Direct3D’s default).

The way OpenGL works as an abstraction layer is that you just have to ‘assume’ that the graphics vendor did the best possible job on making sure you get the best performance possible for whatever rendering path they’re traversing you down to. Unfortunately, a lot of the time, that turns out to be not the case - at all - and ‘optimizing’ drivers for GPU benchmarks (as maister alluded to earlier) by doing even more buffering on the side only makes things even worse potentially.

The only way to ‘avoid’ being constrained by your GPU drivers’ behavior in terms of graphics buffering would be to run RetroArch in KMS (Kernel Mode Setting) on Linux since we can do manual fine-grained buffering on KMS like we can a console.

#5

Ahh, sorry, meant to mention that in the last post. I have a GTX 570 running 314.22 drivers.

Edit: Playing around with the Refresh Rate option in RetroArch, I discovered setting it to 59.000000 helps quite a bit. Much closer to Fusion’s performance, but not quite as good. And it stutters ever couple of frames at that setting.

Hmm, tried it on my Samsung 60hz tv with the 59 setting and it actually seems a bit better than Fusion there. My monitor is a 120hz capable (though I’ve been doing the testing in 60hz mode) BenQ xl2420t for comparison.

#6

Yes, if you set refresh rate too low, you’re pushing frames at a slower rate than your monitor refreshes, so you are always sitting there with empty buffers on your GPU, and thus, better latency, but stuttering.

Read this: http://www.altdevblogaday.com/2013/02/22/latency-mitigation-strategies/

EDIT: I am experimenting with GL_ARB_sync (3.2 core, available via extensions), but don’t expect miracles … No emulator I know of uses it at least. Seems to do something on MESA at least, gl-sync branch: https://github.com/Themaister/RetroArch/tree/gl-sync This might look like glFinish(), but glFinish() is often implemented as a no-op in drivers and not guaranteed to work … :v

Set video_hard_sync to true in config, and you should see in log:


RetroArch: Querying GL extension: ARB_sync => exists
RetroArch: [GL]: Using ARB_sync to reduce latency.
#7

How does the latency with GL_ARB_sync compare with KMS?

#8

KMS already did this implicitly as swap_buffer is implemented as page-flipping and you have to lock the front buffer surface beforehand, requiring a GPU sync.

If you build with make PERF_TEST=1 you should see PERF counters in log. On KMS, gl_fence takes < 1ms because there isn’t much to sync.

On X11, it spent ~10ms per frame (depending on emu core), possibly to actually synchronize to VBlank. When you swap buffers, you don’t really synchronize to VBlank in CPU code, the swap is just queued up for later for performance … The fence strategy recommended by Carmack seems to really sync, but can’t know for sure.

Can’t say I notice any improvement on my laptop, but I never really perceived any lag in Linux anyways. That’s why all this is so much voodoo. Very easy to claim noticing a difference, hard and tedious to objectively prove.

EDIT: FS-UAE appears to have a million options to deal with this stuff actually.

#9

For now, setting it at 59.60hz seems a good enough balance between latency and the occasional stutter, but I look forward to testing out any new sync methods you implement.

#10

Try this build: http://www.sendspace.com/file/kp5q06 (Win64) Set video_hard_sync in config as described. Make sure you’re using a “sane” refresh rate that is as correct as possible.

#11

Trying to launch that exe through Phoenix or the cmd line I get:

Edit: Realized it was because I was running the 32bit version. Using that exe with the 64bit version I get an error about libwinpthread-1.dll missing though.

#12

Ye, built that one from my Windows partition … This should work though: http://www.sendspace.com/file/v2oxxt

#13

Yep that works. And it’s a big improvement for me! Even in RGUI I can feel the difference moving up and down in the menu with video_hard_sync on compared to having it off. So now I get smooth, stutter free gameplay and low input lag (seems just a touch lower than Fusion, actually).

#14

Nice. Don’t think D3D9 has this possibility, so I guess OpenGL on Windows still has a purpose then.