Input latency measurements (and D3D11)

[Retro-Nerd]

Fastest possible CPU mode is now supported (native only, RTG is not yet supported). At least it seems to work with randomly chosen whdload games.

Looks fine for me too in "Fastest possible CPU" mode.

[Toni Wilen]

Originally Posted by Rotareneg

Here's a 40 second video showing how the bottom slice wraps around to the top when on adaptive power management vs prefer maximum performance mode.

Interestingly your video shows noticeably less glitches and much more "stable" glitches (same amount of lines visible, no big random changes) in top of the screen compared to my tests, even in adaptive mode.

Which (again) confirms it is not emulator specific but probably something related to driver/GPU model/generation or Windows version.

[Rotareneg]

My laptop is running Windows 10 Home on a Core i5-3230M with the integrated GPU (Intel HD Graphics 4000.) When using the built-in screen it hardly jitters as all, but has a fixed wrap-around of the last slice:



When using an external monitor it has the same wrap-around, but also has a bit of jitter.

[Zarnal]

Very impressive on same winuae config and laptop :

Beta :

[ Show youtube player ]

WinUae 3.6.1

[ Show youtube player ]

Thank you.

Edit 04/04 :

Invalid Videos (color bars flashes quickly)

Sorry.

[Dr.Venom]

Originally Posted by Toni Wilen

Interestingly your video shows noticeably less glitches and much more "stable" glitches (same amount of lines visible, no big random changes) in top of the screen compared to my tests, even in adaptive mode.

Which (again) confirms it is not emulator specific but probably something related to driver/GPU model/generation or Windows version.

If that's the case it may be worthwhile to check the CPU and GPU clock frequency in realtime and see how they behave when running WinUAE with beam racing vsync. E.g. whether they are high and stable (fixed) or whether they are (still) dynamically scaling during runtime.

If you install MSI Afterburner including its Rivatuner statistics server in combination with HWInfo64 you can show show both CPU and GPU clock frequencies in realtime in an overlay (GPU clock frequency overlay can be set in HWInfo64 sensor settings -> OSD (RTSS) Tab). The RivaTuner Statistics Server must be running alongside with HWInfo64 to show the values in the OSD overlay.

[Toni Wilen]

I don't think even lowest possible GPU frequency makes 1080Ti slow enough to not be able to render and flip frames 3 times in one frame

It happens even if I poll until vblank starts and then immediately present() new frame. Normal vblank period should be much more than large enough for simple page flip operation. Even whole screen rendering pass takes less time! (only few lines max) It looks like driver or GPU just decides to do nothing at all during vblank. It is also only first slice (slice after vblank) that jumps, other slices are much more stable. Vblank period seems to be special.. GSync on or off makes no difference.

[mdrejhon]

Originally Posted by Rotareneg

When using an external monitor it has the same wrap-around, but also has a bit of jitter.

Jitter is harmless as long as there's an offset to keep jitter above the emulator frameslice-rendering boundaries.

The required offset is much smaller than frameslices, and we have a mandatory lag of minimum 1 frameslice (with a jitter margin centered between 1 frameslice ago and 2 frameslice ago). So moving the jittering further up the previous frameslice, means you're only adding 25% more latency to a 1-frameslice.

I've sent an email to Toni to ask for more info about offset handling.

[Toni Wilen]

Another update. Final emulation pass that writes to output texture was not called before each slice D3D rendering so changing number of slices didn't actually affect latency.. Oops

Warning: breakage possible because major internal graphics handling rewrite is underway to support multiple Amiga monitors as separate Windows windows. (For example to have native and RTG/Video port graphics adapter screen visible simultaneously)

--

Problem is only vblank slice which is very random (as I said, previous slice color appears randomly at the top of screen even if I present it during last 50 lines!), I don't see how offset is going to help (it would be HUGE offset..). All other slices are nearly perfect. I am 100% sure this is hardware/driver/something unknown specific because your explanation sounds like you have stable offset, similar to above video.

[mdrejhon]

Originally Posted by Toni Wilen

Problem is only vblank slice which is very random (as I said, previous slice color appears randomly at the top of screen even if I present it during last 50 lines!), I don't see how offset is going to help (it would be HUGE offset..). All other slices are nearly perfect. I am 100% sure this is hardware/driver/something unknown specific because your explanation sounds like you have stable offset, similar to above video.

I have much more jitter for the top, definitely!

More of my experimentation in last 24 hours in separate beam-racing experiments:
-- My system seems to be happy with a 0.1ms-0.5ms time offset before VBI. Which means 75 lines at 180 KHz horizontal scanrate (1080p with an intentionally large VBI -- Vertical Total 1350, used for reducing strobe crosstalk on a BenQ XL2720Z) is equal to ~0.4ms of input lag. The required offset varies based on horizontal scanrate, so I've switched to a time-based offset. So it's ~0.25 frameslice at low-frameslice granularity (600 frameslices per second) while it may be 2-3 frameslices at high-frameslice-rate (3600 frameslices per second)
-- But yes, the top slice is quite fiddly. So (my discovery...) is it seems best practice may be a time-bsaed offset for the first pageflip (numbers like 0.5ms or 1.0ms) rather than a line-based offset. That may mean that you may be flipping while the raster is still in the previous frame (but that's harmless, if you're rasterplotting the first frameslice onto the old framebuffer), especially on a high-refresh-rate display with small VBI's. But that works fine without artifacts provided you're reusing the framebuffer. My focus as of late is to know (or predict) the timestamp of the first scanline, and then time-offset based on that. That way, I'm VBI-size independent and I can safely flip wraparounds (e.g. framebuffer containing first frameslice + rest of buffer old frame, can be safely flipped while the raster is still in the previous refresh cycle).

(...Still doing frameslice beam racing experiments in my software to discover quirks...)

[Rotareneg]

Originally Posted by Toni Wilen

Another update. Final emulation pass that writes to output texture was not called before each slice D3D rendering so changing number of slices didn't actually affect latency.. Oops .

Ah, that explains things! Last night I played around with various breakout clones and was getting a bit confused as the low latency vsync still felt a bit laggy.

I just tried the new version and the difference is like night and day when using my laptop built-in screen. For me the easiest way to get a quick feel for the latency is just to load workbench and move the mouse cursor around in circles real fast. With the new version and low latency vsync the emulated cursor feels perfect, no different than the cursor in Windows itself.

When output to my TV (connected via HDMI to the laptop) there's a bit more latency for some reason when using WinUAE. The Windows mouse cursor itself has no noticible latency on the same screen.

[Toni Wilen]

When output to my TV (connected via HDMI to the laptop) there's a bit more latency for some reason when using WinUAE. The Windows mouse cursor itself has no noticible latency on the same screen.

Does the TV have "game" (low latency) mode?

[Rotareneg]

It does not. I checked with a camera that has a 220 FPS mode and it appears that the external monitor image is delayed by about 2 frames (or 1/30s) compared to the internal screen, and that's both with the Windows desktop and in WinUAE.

My desktop (with an Asus VS239H monitor) also seems to have a little more latency than my laptop's internal display. It's clear the low-latency vsync is working noticeably better than regular vsync, but it just doesn't feel as "instant" as the laptop display.

Perhaps there's a bit of extra latency introduced when using HDMI/DVI, perhaps including HDCP, that isn't present with an integrated display, seperate from any other lag the display itself might present.

[lordofchaos]

Forgive me for sounding ignorant on this latest breakthrough, but will there be any real tangible differences for those that still have modest (old) PC set-ups? I`m still using an I5-2500K with GeForce GTX 750 Ti. Just curious.

[Toni Wilen]

Originally Posted by Rotareneg

It does not. I checked with a camera that has a 220 FPS mode and it appears that the external monitor image is delayed by about 2 frames (or 1/30s) compared to the internal screen, and that's both with the Windows desktop and in WinUAE.

LCD TVs generally have 40ms+ latency unless they have "game" mode.

Originally Posted by lordofchaos

Forgive me for sounding ignorant on this latest breakthrough, but will there be any real tangible differences for those that still have modest (old) PC set-ups? I`m still using an I5-2500K with GeForce GTX 750 Ti. Just curious.

Yes. Any GPU with integrated VRAM probably works fine. Mid/low end(?) CPUs with integrated GPU may not have enough memory bandwidth causing slowdowns.

If colored background bars are mostly stable (not randomly flashing like some 8-bit tape loaders ) = it works.

[Rotareneg]

Just measured again and that TV is around 50-60 ms behind the laptop's internal display. I primarily use that TV for watching videos anyway, so I'm not surprised I never noticed the latency on it.

I did notice a two issues with the latest test version with file modification date of ‎April ‎02, ‎2018, ‏‎2:28:13 PM.

Turbo mode is glitchy with low latency vsync on: Only part of the display will update while turbo is active, and when turning turbo off that part of the screen will be left glitched until it's updated, like moving the emulated mouse cursor over the area in Workbench.

Also, WinUAE is crashing when I try to access the output settings, which happens even without loading any config. Attached is the dump file.

[Toni Wilen]

Originally Posted by Rotareneg

Turbo mode is glitchy with low latency vsync on: Only part of the display will update while turbo is active, and when turning turbo off that part of the screen will be left glitched until it's updated, like moving the emulated mouse cursor over the area in Workbench.

Fixed, but it still can cause odd side-effects. (Ignore new narrow color bars)

Also, WinUAE is crashing when I try to access the output settings, which happens even without loading any config. Attached is the dump file.

Can't duplicate and dump files are useless until official beta. Most likely related to ongoing multiamigamonitor changes.

[mdrejhon]

Originally Posted by Rotareneg

Perhaps there's a bit of extra latency introduced when using HDMI/DVI, perhaps including HDCP, that isn't present with an integrated display, seperate from any other lag the display itself might present.

Nope. It's buffer/processing lag in many HDTVs.
HDCP adds less than 1ms of lag nowadays, it's not even worth mentioning here.

Originally Posted by Rotareneg

When output to my TV (connected via HDMI to the laptop) there's a bit more latency for some reason when using WinUAE.

That's normal due to TV latency. That said, new beam racing mode should give the lowest possible emulator latency though -- lower lag than any other non-beam-raced options.

Beam racing actually races the cable scanout, not the panel's scanout. We have no control over what the display does to the pixels that arrives over the cable. Some displays just unavoidably buffers the pixels for one reason or another (e.g. HDR or overdrive processing, etc). Some gaming monitors can laglessly process overdrive (real time line buffering processing) but not all monitors on your desktop do this. But some of mine do!

Panel scanout lag can be different from cable scanout lag. Emulator beam racing only nearly zeros-out the cable scanout lag. I have some external (HDCP compatible) gaming displays that actually has bufferless operation, and only has 3ms lag between software API call and pixels hitting my human eyes (for beam-raced software).

I know that the BenQ XL2420 & XL2720 series (144Hz monitor I have) and the BenQ RL2455HM, RL2460HM (60Hz monitors), all do lagless 60 Hz synchronous scanout (cable scanout == panel scanout at 60Hz) so you'll get the true lagless operation with the new "Lagless VSYNC (Beam Racing)" mode. Unfortunately I also discovered the BenQ XL2540/2546 doesn't do synchronous scan mode in 60Hz, only at 240Hz, but then again you can simply beam-race at 240Hz instead (beam-racing 1 in 4 refresh cycles, or beam-racing a GSYNC/FreeSync refresh cycle), as long as your host CPU is fast enough to run WinUAE CPU at 4x velocity in "1/60sec emulator time" surges every 1/240sec.

Later this year, Blur Busters is beginning new input latency tests that also tests for synchronous scanout capabilities. Monitors that does synchronous unbuffered (or line-buffered processing) scanout will have no lag between pixel delivery (on the cable) and pixel display (on the panel).

There are multiple sources of lag in monitors
1. Absolute lag (lag between pixel delivery over cable + pixel display)
2. Scanout lag (normally only an issue for traditional VSYNC ON method, not for beam racing or VSYNC OFF)
2. Scanout lag asymmetries in the Y-dimension (caused by scan conversion, e.g. converting a 1/60sec scanout signal to a 1/240sec scanout on certain panels that can only be fast-scanout. So you need to partially pre-buffer a slow scanout signal for a fast-scanout-only panel).
3. Buffering lag (full frame buffering, line buffering, and partial scanout buffering)
4. GtG lag (pixel response). Human eyes sees the first photons from the pixel once the pixels has transitioned a little, even 10%, so a 2ms GtG panel pixel may be noticed in less than 1ms, for the bright transitions (e.g. Black->White)
5. Lag asymmetries caused by GtG asymmetries in different colors (laggier greys on VA panels, for example)
6. ULMB/LightBoost strobe backlight lag (panels are refreshed in traditional LCD scanout in total darkness, then flashed all-at-once after scanout)
7. Etc, etc, etc, etc, etc, etc, etc, etc, etc, etc / etc^2 / etc^etc / etc * 10^(number of atoms in universe) [...] [...]

I am one of the few people in the world who understands why input lag numbers varies between different websites -- their numbers are legitimate but for different reasons. And I meet with other lag testing websites too. Also lag tests often inherently have a sync bias (a VSYNC ON bias, versus a VSYNC OFF bias). I have also commissioned a peer reviewed researcher to analyze competitive-gamer reaction times too.

So believe me -- I know my "input lag" stuff here. Click the links if you do not believe me -- I wrote all those content/articles at all those links.

Beam racing equallizes TOP/CENTER/BOTTOM lag (Leo Bodnar Lag Tester, a "VSYNC ON" lag tester) to be equal to TOP. Meaning BOTTOM == TOP. If TOP has 4ms of lag, the BOTTOM also has 4ms of lag too, thanks to the magic of beam racing. For 60Hz fixed-Hz modes, Input lag of beam racing has up to approximately 1/2 refresh cycle less lag than the main lag number you see on DisplayLag.com because DisplayLag.com usually measures CENTER lag only.

That means 10ms DisplayLag.com for the best LCDs is actually as little as 2-3ms lag -- TOP(2ms)/CENTER(2ms)/BOTTOM(2ms) -- with fine-slice-granularity beam racing. If you see "9ms", "10ms", "11ms", "12ms" for CENTER on the DisplayLag.com website, that's your signal that the display is probably lagless with beam racing. This is because 1/2 of a refresh cycle (1/2 of 1/60sec) = 8.3ms. Yep. Now you understand. If a display can refresh CENTER in only 10ms with a VSYNC ON lag tester (like Leo Bodnar), yes that's essentially a lagless LCD. That's 8.3ms + LCD GtG. So those numbers are a dead-giveaway (thanks to Mathematics 101) -- that tells you it is a lagless LCD with no buffer delay. Only GtG lag. Very beam-racing-friendly. With beam racing, yes, you'll get your beautiful 2ms CENTER and 2ms BOTTOM lag with those "CENTER 10ms lag" panels.

Leo Bodnar Lag Tester has these variables:
Refresh Rate = 60Hz
Sync Method = VSYNC ON
Stopwatch Start = VBI
Stopwatch End = Screen location (Top, Center, Bottom), at roughly the 50%-90% point of GtG curve

So Leo Bodnar Lag Tester (which many sites use) only gives you 60Hz VSYNC ON lag test results. (Incidentially, that's why CS:GO players prefer TFTCentral lag test results -- they use SMTT 2.0 which is a 1000fps VSYNC OFF two-display-differential technique, and more representative of VSYNC OFF CS:GO gameplay. VSYNC OFF zeros out the scanout gradient, since there's zero scanout lag in the first scanline adjacent to a tearline).

Bottom line, what this means is beam-racing beats the "CENTER" and "BOTTOM" numbers output from a Leo Bodnar Lag Tester.

For fast-scanout modes on fast-scanout compatible displays such as variable refresh rate beam racing (e.g. "60Hz" refresh cycles scanned-out in 1/240sec), the input lag of beam racing can fall even further -- this "cheat" can result in an emulator with less lag than the original machine (technical explanation how it's possible here).

Again, I hate to repeat this like a broken record, but I know more about display lag mechanics than most of you think -- In my small circle, I am almost considered an Einstein in this territory .... Again, I meet with other lag testing websites too, and I understand why input lag numbers varies between different websites. Those numbers aren't lying. They're simply different stopwatch start signals and stop signals, that's all.

Nothing has less input lag than properly implemented beam racing (at theoretical scanline-granularity, or one-scanline-tall slices -- once front buffer rendering becomes re-enabled by NVIDIA). Not even Force GPU Sync. Not even delay-input-reads. Properly implemented VRR-compatible single-line beam racing is the holy grail of emulator latency, full stop.

Also, to emulator developers! 3 emulator authors have joined the fantastic emulator-developer discussions occuring in Page 4, 5, 6, 7 of that Blur Busters Forums thread. I'll also be releasing my source code in a few weeks (it's called the "Tearline Jedi" demo) -- it'll be a cross-platform Beam Chasing Sandbox for beam chasing newbies. (Repeat after me: "VSYNC OFF tearlines are just rasters!")

[mdrejhon]

Originally Posted by lordofchaos

Forgive me for sounding ignorant on this latest breakthrough, but will there be any real tangible differences for those that still have modest (old) PC set-ups? I`m still using an I5-2500K with GeForce GTX 750 Ti. Just curious.

GTX 750 Ti is fast enough for beam racing. I don't know how many slices but it should be beam racing friendly at least at the 4-slice or 6-slice granularity -- that's still up 75% less lag than the next-lowest-lag VSYNC method -- at least for games that does input reads very late into the refresh cycle.

If you have an NVIDIA GPU, then the I5 should far more than plenty fast enough for 60Hz beam racing. Beam racing is more GPU and memory bandwidth dependant. That said, even slower shared video memory still does 6-frameslice granularity just fine. Even just 4 slices still can reduce bottom-of-screen input reads lag by ~75% for unbuffered laptop LCDs.

[lordofchaos]

Originally Posted by Toni Wilen

Yes. Any GPU with integrated VRAM probably works fine. Mid/low end(?) CPUs with integrated GPU may not have enough memory bandwidth causing slowdowns.

If colored background bars are mostly stable (not randomly flashing like some 8-bit tape loaders ) = it works.

Originally Posted by mdrejhon

GTX 750 Ti is fast enough for beam racing. I don't know how many slices but it should be beam racing friendly at least at the 4-slice or 6-slice granularity -- that's still up 75% less lag than the next-lowest-lag VSYNC method -- at least for games that does input reads very late into the refresh cycle.

If you have an NVIDIA GPU, then the I5 should be plenty fast enough for 60Hz beam racing. Beam racing is more GPU and memory bandwidth dependant. That said, even slower shared video memory still does 6-frameslice granularity just fine. Even just 4 slices still can reduce bottom-of-screen input reads lag by ~75% for unbuffered laptop LCDs.

Thanks for the info, this is great news!

[mark_k]

With winuae.exe from 2 April I can get a stable display with 10 slices in full-window mode. (Today's winuae.exe is a little different.) Full-screen mode allows significantly more slices, presumably due to it needing less memory bandwidth.


Could there be any scope for reducing GPU memory bandwidth as this feature is refined? That could allow lower-end systems to benefit from this feature, and higher-end ones to use more slices.

DXGI 1.2 supports partial presentation, see Enhancing presentation with the flip model, dirty rectangles, and scrolled areas on MSDN. With that you'd use DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL or DXGI_SWAP_EFFECT_SEQUENTIAL and specify the dirty rectangle to be the just-rendered strip. (DXGI_SWAP_EFFECT_DISCARD might work as well, if Windows allows it. Since we don't care what's in the rest of the display, just the current strip.)

Also, could partial texture updates help? Use ID3D11DeviceContext::UpdateSubresource() to partially update the texture? Or maybe use multiple textures, one for each strip. Before each Present() you'd only update one texture.

Is there any way to visualise how much GPU bandwidth is being used, in real-time? (That can co-exist on-screen with WinUAE preferably.)