Dr.Venom Registered User

Join Date: Jul 2008 Location: Netherlands Posts: 485

Input latency measurements (and D3D11)



I did some additional input latency measurements and thought I'd collect them in this thread for future reference. These are objective input latency measurements comparing WinUAE to a real Amiga. For people interested in the methodology, it's summarized at the end of this post:



The purpose of this thread is that we get a reference of the actual input latency between a real Amiga and WinUAE on a fast PC, both attached to the same joystick and display hardware. With this:

any potential future input latency improvements in WinUAE can be objectively tested

potentially a comparison can be made between the latency of different Amiga Emulator implementations (WinUAE, FS-UAE, GroovyMAME's Amiga core, Retroarch core, etc..)

Any potential regressions between WinUAE versions could easily be tested for

There are three tests:

"Button 260" - checks for a button press near the end of a frame then waits for vsync and then turns screen yellow "Button 25" - checks for a button press at the beginning of a frame then waits for vsync and then turns screen yellow Turricun II "jump" - this measures the latency of a jump of Bren McGuire (yep that's his name ) at the start of Turrican II. This may be interesting as it's a real game example. The results are the number of Amiga frames of latency from button press to on-screen change. It's the measured average for a number of button presses.



The results:



"Button 260" :

Real Amiga 1200: 0,8 frames

WinUAE 3.5.0, low latency vsync - no buffering: 2,6 frames

WinUAE 3.5.0, low latency vsync - double buffer: 2,8 frames

WinUAE 3.5.0, vsync disabled, no buffering: 2,0 frames

WinUAE 3.5.0, vsync disabled, double buffer: 2,0 frames



"Button 25" :

Real Amiga 1200: 1,7 frames

WinUAE 3.5.0, low latency vsync - no buffering: 2,9 frames

WinUAE 3.5.0, vsync disabled, no buffering: 2,7 frames



Turrican II jump

Real Amiga 500: 2,2 frames

WinUAE 3.5.0, low latency vsync - no buffering: 3,7 frames



Using the debugger ("dj 6") with logging enabled it shows that Turrican II at the start reads input at line 273, which is late in the frame. Interestingly, when you move right towards the waterfall, input reading gets pushed even later in the frame, like at 312 and wrapping to the next frame.



Checking some other games (Hybris at line 255, Addams Family at line 256, Leander in-game at line 255, Jim Power at line 294), it seems safe to say that most games check for input late in the frame, which would suggest after the game loop.



Conclusion:

WinUAE's input latency in vsynced low latency no buffer mode is between 1,2 and 1,8 frames behind a real Amiga, depending on where the (emulated) Amiga reads its input. If it's late in the frame then latency tends more towards 1,8 frames of latency, if it's early it tends more to 1,2 frames of latency. Since most games seem to check input late in the frame, the additional input latency versus a real Amiga with games will tend more towards 1,8 frames.



Can this be lowered further? Not much. WinUAE is pretty much optimized already regarding video buffering and how it polls input (using rawinput and acquiring input at the moment the emulated Amiga reads it).



The only remaining option is the so called frame delay implementation. This could lower the latency versus a real Amiga by about 0,8 frames on a fairly fast PC, so to between 0,4 (1,2-0,8) and 1,0 (1,8-1,0) frames depending on whether the game reads input early or late in the frame.



A total input latency of 0,4 to 1,0 frames would practically be the holy grail. If you also feel strongly about that being a great addition to WinUAE, please let Toni now. Hi,I did some additional input latency measurements and thought I'd collect them in this thread for future reference. These are objective input latency measurements comparing WinUAE to a real Amiga. For people interested in the methodology, it's summarized at the end of this post: Latency tests - No difference between "No buffering" and "Double buffering" . That post also explains the button test.The purpose of this thread is that we get a reference of the actual input latency between a real Amiga and WinUAE on a fast PC, both attached to the same joystick and display hardware. With this:There are three tests:The results are the number of Amiga frames of latency from button press to on-screen change. It's the measured average for a number of button presses."Button 260" :Real Amiga 1200:WinUAE 3.5.0, low latency vsync - no buffering:WinUAE 3.5.0, low latency vsync - double buffer:WinUAE 3.5.0, vsync disabled, no buffering:WinUAE 3.5.0, vsync disabled, double buffer:"Button 25" :Real Amiga 1200:WinUAE 3.5.0, low latency vsync - no buffering:WinUAE 3.5.0, vsync disabled, no buffering:Turrican II jumpReal Amiga 500WinUAE 3.5.0, low latency vsync - no buffering:Using the debugger ("dj 6") with logging enabled it shows that Turrican II at the start reads input at line 273, which is late in the frame. Interestingly, when you move right towards the waterfall, input reading gets pushed even later in the frame, like at 312 and wrapping to the next frame.Checking some other games (Hybris at line 255, Addams Family at line 256, Leander in-game at line 255, Jim Power at line 294), it seems safe to say that most games check for input late in the frame, which would suggest after the game loop.WinUAE's input latency in vsynced low latency no buffer mode is betweenandframes behind a real Amiga, depending on where the (emulated) Amiga reads its input. If it's late in the frame then latency tends more towards 1,8 frames of latency, if it's early it tends more to 1,2 frames of latency. Since most games seem to check input late in the frame, theinput latency versus a real Amiga with games will tend more towards 1,8 frames.Not much. WinUAE is pretty much optimized already regarding video buffering and how it polls input (using rawinput and acquiring input at the moment the emulated Amiga reads it).The only remaining option is the so calledimplementation. This could lower the latency versus a real Amiga by about 0,8 frames on a fairly fast PC, so to between(1,2-0,8) and(1,8-1,0) frames depending on whether the game reads input early or late in the frame.A total input latency of 0,4 to 1,0 frames would practically be the holy grail. If you also feel strongly about that being a great addition to WinUAE, please let Toni now.