Input latency measurements (and D3D11)

[Toni Wilen]

http://www.winuae.net/files/b/winuae.7z

Implemented lagless vsync mode (https://www.blurbusters.com/blur-bus...or-developers/)
Replaces old low latency vsync mode.

What does it do? It reduces input latency from usual 20ms-40ms+ to less than 5ms! (or even less)

This is experimental test version with following requirements and restrictions:

- Low latency vsync (with or without 50/60 switching)
- Display panel refresh rate must be selected (50 or 60). It must not be "default".
- Cycle-exact or approximate CPU speed only.
- Fullscreen only.
- Direct3D 11 only.
- Does not (can not) support black frame insertion or frame doubling = use only standard 50Hz or 60Hz modes. (or up to 85Hz or so )
- Sound syncronization is not updated yet.
- Due to above, missed frames/glitches will happen randomly.
- Native mode only.
- Amiga display to monitor position mapping must be border to border vertically (or close enough) or you may see tearing lines.
- Uses CPU polling only. (It should sleep if time between slices is long enough)
- Does not gain anything from G-Sync.

Current features:

- Input is read after each slice.
- Default is 4 slices which makes max input latency about 6ms. (Assuming quality "gaming grade" USB input devices that use <=1ms USB rate.)
- Because output is shader based, outputting each slice requires full render pass each time. It technically means same as rendering screen 4 times the frame rate. (for example 50Hz output requires rendering 200 frames) -> don't enable any extra shaders unless you have powerful GPU. Most likely requires GPU with on-board RAM (discrete GPU) because this mode increases VRAM bandwidth requirements heavily. Or reduce resolution.
- Add config file "gfx_frame_slices=<number of slices>" if you want to test other values, minimum is 3.

It passes my standard Pinball Dreams input latency test playability test perfectly. Ball/flipper response feels wrong even with 1 frame of input latency.

[Retro-Nerd]

Impressive. This new lagless Vsync/double buffer is pretty much as smooth and responsive as Freesync/single buffer without Vsync.

[Toni Wilen]

Small update. Original vblank rendering was still active, making one extra useless rendering pass + possibly caused random tearing.

[Dr.Venom]

Just tried the winuae.7z, but I'm encountering some things that make me unsure whether it's active at all.

I need to select "low latency vsync" right?

It seems to sync to my real refresh rate of my LCD monitor. When I run it on my default 60hz LCD setup, everything is sped up to 60hz (music, game speed etc), the log also report vsync=60.000hz.

Also when I enter a ridiculous number of slices, like "gfx_frame_slices=4000" I get the same result as with the default (like above).

Is there anything in the log to verify that the slice method is active and working?

Edit: this is on a setup with NVidia GTX 1070.

[Toni Wilen]

Of course it uses monitor refresh rate, it is vsync (weirdly done vsync but still a vsync) and can only work if Amiga refresh rate matches monitor rate.

max slice count is limited to 99.

Refresh rate must be selected in display panel. It must not be "default". (added to previous post)

[Dr.Venom]

Ah, my bad.

Just tried it with 50hz screenmode and it works like a charm! I need to test more, but first impression with default number of slices and slices at 10 is that input latency is insane .

Great stuff, thanks for implementing . Will have to do some more testing with different setups and I hope coming weekend with a CRT setup.

[Dr.Venom]

Originally Posted by Toni Wilen

Current features:
- Add config file "gfx_frame_slices=<number of slices>" if you want to test other values, minimum is 3.

I did some testing with a different setup with integrated graphics (for which low latency vsync works without issues) but it can't keep up when using the slices method, even when lowering this to 3.

Is there a particular reason you're limiting the number of slices to 3? I'm asking because the "compatability" with older hardware / integrated graphics (portables etc.) would increase by quite some margin when using less slices than 3.

Technically it should even work up to 1 right?

Originally Posted by Toni Wilen

- Input is read after each slice.

Just out of interest, is the timing of reading the input when using say 4 slices, much different now than with low latency vsync in 3.6.1?

[Toni Wilen]

Originally Posted by Dr.Venom

I did some testing with a different setup with integrated graphics (for which low latency vsync works without issues) but it can't keep up when using the slices method, even when lowering this to 3.

It is too early for that.

Is there a particular reason you're limiting the number of slices to 3? I'm asking because the "compatability" with older hardware / integrated graphics (portables etc.) would increase by quite some margin when using less slices than 3.

Technically it should even work up to 1 right?

Because current quick implementation requires, start, middle and end being separate slices.

Just out of interest, is the timing of reading the input when using say 4 slices, much different now than with low latency vsync in 3.6.1?

It depends on when program reads input. Latency can be much smaller if input is read later than during vblank or input is read in "real time" (for example keyboard input may be processed instantly when key is pressed if keyboard read uses interrupts)

[Dr.Venom]

It depends on when program reads input. Latency can be much smaller if input is read later than during vblank or input is read in "real time" (for example keyboard input may be processed instantly when key is pressed if keyboard read uses interrupts)

Great, that's a good improvement..

Just juggling thoughts.. Maybe some part of the methodology of this partial frame updating /slicing could be applicable to the non vsync mode as well?

I.e. by only applying the slicing and mid-frame updating, without the host beam racing part, non-vsynced mode could potentially get closer to real hardware response too?

[Toni Wilen]

Originally Posted by Dr.Venom

Just juggling thoughts.. Maybe some part of the methodology of this partial frame updating /slicing could be applicable to the non vsync mode as well?

It would cause moving tearing lines equaling number of slices.

[Retro-Nerd]

So with G-Sync/Freesync and this new lagless Vsync we've reached the optimum for now? Or is there still room for a few ms less lag in other tasks inside emulation. What do you think is smallest over-all input lag we could reach these days? Best case scenario, with a modern PC/monitor and decent input devices.

[Rotareneg]

I am getting a steady vsync tear near the top edge of the screen when using this new version. However, I'm not sure if I'm just setting something wrong as I'm not entirely clear on what "Amiga display to monitor position mapping must be border to border vertically (or close enough) or you may see tearing lines." means. Do you mean that one should adjust scaling so that (assuming a regular 320x200 screen) the image should fill the actual display with no gaps, or that the entire overscan area should also be on screen and not scaled off the edge of the display?

Attached is the config and logs from my desktop.

[rare_j]

Is new lagless vsync dx11 only?
Does new lagless vsync add siginificantly to cpu load compared to 'old' low latency vsync mode?

If answer to either of these queztions is 'yes', then is there any possibility to keep the option of 'old' low latency vsync mode?

[Toni Wilen]

New update:

- Debug background colors added, shows exact position of slice changes. (Position where tearing happens if timing is wrong)
- Now also Direct3D9 compatible (Windows 7+ only)
- Stability improved.

Originally Posted by Retro-Nerd

So with G-Sync/Freesync and this new lagless Vsync we've reached the optimum for now? Or is there still room for a few ms less lag in other tasks inside emulation. What do you think is smallest over-all input lag we could reach these days? Best case scenario, with a modern PC/monitor and decent input devices.

I am not sure but I guess it is something like 2ms max in optimum situations.

Variable sync (g-sync/etc) also improves it slightly because display output starts immediately when program does Present() call. Normal displays still need to wait for vblank period to end.

Originally Posted by Rotareneg

I am getting a steady vsync tear near the top edge of the screen when using this new version.

This should be fixed now.

However, I'm not sure if I'm just setting something wrong as I'm not entirely clear on what "Amiga display to monitor position mapping must be border to border vertically (or close enough) or you may see tearing lines." means. Do you mean that one should adjust scaling so that (assuming a regular 320x200 screen) the image should fill the actual display with no gaps, or that the entire overscan area should also be on screen and not scaled off the edge of the display?

Scaling should be so that monitor's topmost line matches first max overscan visible Amiga line (and same for bottom line).

It does not need to be exactly right, especially when using small number of slices.

(This will become automatic later)

Originally Posted by rare_j

Is new lagless vsync dx11 only?
Does new lagless vsync add siginificantly to cpu load compared to 'old' low latency vsync mode?

If answer to either of these queztions is 'yes', then is there any possibility to keep the option of 'old' low latency vsync mode?

1) No. 2) currently yes, later: most likely almost no.

[rare_j]

Originally Posted by Toni Wilen

1) No. 2) currently yes, later: most likely almost no.

Great work!

[RealNC]

I thought I'd never see the day where emulators on an LCD monitor would match real hardware latency. Great job!

Now if we could convince AMD and NVidia to allow front-buffer rendering in non-VR mode, I think this method would work even better.

[DamienD]

I haven't had the chance to try this out as yet but...

Well done Toni!!!

...this is the one main thing that "real" Amiga users complain about when using emulation and now you've found a solution without the need for expensive hardware

[Rotareneg]

Just tried the new version and, strangely enough, it seems to run slightly better on my laptop which is using the integrated Intel HD Graphics 4000 on the Core i5-3230M CPU than on my desktop with an older i7-860 and GTX 760 video card. On the laptop the debug color bars are rock steady, with only the occasional glitch, but on my desktop the bars jitter constantly, although there doesn't appear to be any visible tearing in the actual emulated display.

Oh, and turbo mode seems to be disabled in this version when using low latency vsync.

[Toni Wilen]

I didn't find the solution, I only implemented it This is holy grail for emulation latency! Supposedly impossible to do..

There is still something unexplained going on.. I see bottom slice color appearing in the very top of screen even when topmost present-call is guaranteed inside vblank period.

Test with sound disabled, it should remove all large (as in more than +-10 pixel) random jitter but it does not..

Warp mode should already work (and works even better now). Fastest possible CPU still won't work, it is always the biggest problem..

Slice count 2 (from 3) is now supported.

[Retro-Nerd]

One thing wasn't clear enough to me though. Can i leave Freesync enabled while the lagless Vsync is running? Or should i disable it in the AMD driver.