Input latency measurements (and D3D11)

[Toni Wilen]

D3D GetRasterStatus() probably will be supported later (It was already used in "old" low latency vsync).

DirectDraw: totally pointless. (Unless you really want to support Windows 9x/ME where it actually is "direct". WinUAE has not supported it for ages)

I know lack of extra information and non-waiting vblank can be worked around but it does not fit very well with emulation logic (without extra ugly complexity I don't want to do) when in fastest possible CPU mode (and especially if CPU idle is also enabled). It will work but it can cause more glitches.

[buckrogers]

Thank you to mdrejhon and Toni for this advancement. Forgive my ignorance as I have not the patience to begin to understand the physics. Can someone please provide a lay persons summary in terms of hardware recommendations to take advantage of beam-racing, for those without the hardware to test for themselves? From the thread and original blurbusters dev article I have been able to gather:

1. I5-2500K with GeForce GTX 750 Ti is sufficient, and I take it that any LCD monitor running at 50 or 60hz will suffice, and I assume panels with lower input lag (TN) are better than others (eg., IPS). How would the input lag compare here with original Amiga on a 60Hz CRT or vs option 2 below?

2. Beam-racing can also work with variable refresh rate (VRR) compatible monitors (free-sync, g-sync) at 120Hz or 240Hz. The optimum solution as of current writing would be a monitor capable of 240Hz VRR with fast CPU 4 GHz+ i7 (faster surge execute cycles) and fastest GPU available, for 12ms less input lag than the original Amiga on a 60Hz CRT.

3. Also works with CRT monitors but without the reduction in lag beyond an original Amiga on a 60Hz CRT that comes with option 2.

Is that an accurate summary?

From a bang for buck perspective, how do options 1, 2 @120hz VRR, 2 @240hz VRR plus 1080Ti compare and will I enjoy Turrican 2 that much more?

[Toni Wilen]

Originally Posted by buckrogers

Thank you to mdrejhon and Toni for this advancement. Forgive my ignorance as I have not the patience to begin to understand the physics. Can someone please provide a lay persons summary in terms of hardware recommendations to take advantage of beam-racing, for those without the hardware to test for themselves? From the thread and original blurbusters dev article I have been able to gather:

1. I5-2500K with GeForce GTX 750 Ti is sufficient, and I take it that any LCD monitor running at 50 or 60hz will suffice, and I assume panels with lower input lag (TN) are better than others (eg., IPS). How would the input lag compare here with original Amiga on a 60Hz CRT or vs option 2 below?

2. Beam-racing can also work with variable refresh rate (VRR) compatible monitors (free-sync, g-sync) at 120Hz or 240Hz. The optimum solution as of current writing would be a monitor capable of 240Hz VRR with fast CPU 4 GHz+ i7 (faster surge execute cycles) and fastest GPU available, for 12ms less input lag than the original Amiga on a 60Hz CRT.

3. Also works with CRT monitors but without the reduction in lag beyond an original Amiga on a 60Hz CRT that comes with option 2.

Is that an accurate summary?

From a bang for buck perspective, how do options 1, 2 @120hz VRR, 2 @240hz VRR plus 1080Ti compare and will I enjoy Turrican 2 that much more?

1: CPU usage requirements are not larger, it may only appear so because for stable operation busy wait must start earlier. (because 1-2ms is the shortest time you can normally wait). Only real extra work is texture copy to VRAM and only modified part is copied.

GPU requirements are larger, the more slices, the more GPU power needed. (Whole "scene" is rendered as many times as number of slices/frame) but unless you have extra shaders enabled, any non-ancient GPU should be fast enough.

2: Technically it reduces lag but it also increases CPU requirements 2x+ because emulated frame must be finished now faster than real-time. This is not yet fully supported. ("VRR Monitor DON'T TOUCH" checkbox enables it but it is not yet supported) It may also require larger sound buffers because emulated world is more "out of sync" with real world during single frame.

Someone else can answer other questions

[mdrejhon]

Originally Posted by buckrogers

1. I5-2500K with GeForce GTX 750 Ti is sufficient, and I take it that any LCD monitor running at 50 or 60hz will suffice, and I assume panels with lower input lag (TN) are better than others (eg., IPS). How would the input lag compare here with original Amiga on a 60Hz CRT or vs option 2 below?

2. Beam-racing can also work with variable refresh rate (VRR) compatible monitors (free-sync, g-sync) at 120Hz or 240Hz. The optimum solution as of current writing would be a monitor capable of 240Hz VRR with fast CPU 4 GHz+ i7 (faster surge execute cycles) and fastest GPU available, for 12ms less input lag than the original Amiga on a 60Hz CRT.

3. Also works with CRT monitors but without the reduction in lag beyond an original Amiga on a 60Hz CRT that comes with option 2.

1. CPUs won't be limiting factor. GPUs will be. But a GTX 750 is more than enough to beamrace 5 and 10 frameslices per refresh cycle. Probably 10! Latency is a minimum of one frameslice for this lagless VSYNC ON (beam raced tearingless VSYNC OFF). If you can do 10 frameslices per refresh cycle at 60Hz, you are doing 600 frameslices per second. So you have 1/600sec emulator lag in this situation.

NOTE: Assuming you're using bufferless scanout LCDs (aka most TN LCD gaming monitors), the USB poll rate and LCD GtG are other additional latency factors, but they can be brought down to roughly a millisecond apiece.

2. Beamracing works with any VRR Hz of any Hz at least double the emulator. Does not need to be evenly divisible. So a 144Hz VRR monitor is good. You'll be doing "60Hz" beamraced scanouts that are beamraced at 1/144sec velocity, once every 1/60sec. (60Hz beamracing can also technically be made to work with fixed-Hz 60Hz, 120Hz, 180Hz and 240Hz (beamraces every X refresh cycles).

3. You can get pretty darn close to duplicating the original sublatency of an Amiga by using a CRT and a high-frameslice-throughput GPU -- probably to a sub-millisecond accuracy. My GeForce GTX 1080 Ti can do over 7000 frameslices per second so that can be theoretically 100 frameslices per Amiga refresh cycle (just a few scanlines!).

[buckrogers]

Thank you gentleman. While on the topic of CRTs and modern GPUs and using beam-racing, mdrejhon are you using a utility or custom driver to select lower resolutions with your 1080ti? This is highly relevant to anyone chasing the holy grail of lag free WINDOWS based emulation on a CRT.

I take it that one can use Calamity's CRT Emudriver to select low res options with an R9 (and perhaps higher) but what does an Nvidia user do? Does toastyx's CRU allow for the use of low res options of the kind applicable to amiga users, such as 640x576 50p, 640x512 50p, and 60p equivalents, for Nvidia cards?

[buckrogers]

The deal breaker here is getting an analogue signal to a CRT from a modern GPU. Moving forward all AMD and Nvidia options will no longer have analogue output. Therefore stand alone GPU options seem to be limited to the following and their predecessors:

GTX 980ti GDDR5 6GB
Memory Bandwidth (GB/sec) 336
DVI-I output

R9 270 GDDR5 2GB
Bandwidth: 179.2 GB/s
Memory Clock: 1400 MHz, 5600 MHz effective
DVI-I output

Best integrated is AMD Radeon RX Vega 11 but memory performance is system dependent. As per mdrejhon's blurbusters article: Requires graphics card with high pageflip rate capability (fast graphics RAM, not integrated GPU).

[mdrejhon]

It's possible to manufacture an adaptor that converts HDMI to VGA in practically realtime (<0.25ms lag).

We'll probably be quite fully reliant on adaptors, so we might as well make adaptors as lagless as possible (only one micropacket max lag).

DisplayPort/HDMI Micropacketing usually are only one scanline or so (though my Zisworks 4K120Hz display uses a 6-scanline rolling window at 1.2GHz dotclock dual-DisplayPort -- as an extreme firehose example requiring somewhat bigger rolling-buffer micropacket windows). Either way, adaptor lag of <0.1ms is possible if you have the right circuit and rolling few-scanline buffering. At 135KHz scanrate, a 6-line rolling buffer is only 6/135000ths of a second. So adaptor lag can be extremely low in a HDMI-to-VGA conversion step, if you're doing it as bufferlessly as possible.

The timings conversions can be practically 1:1, anyway, since it's the exact same Custom Resolution Utility Timings & Resolution for both HDMI and for VGA, so doing a straight conversion without scan-converting the signal. And keeping your own scan formulas (e.g. doing proper VESA GTF CRT-compatible timings on the digital side first....and not letting the adaptor doing it). Many adaptors scan convert by inserting larger blanking intervals, and that adds buffering delay, but it is totally unnecessary and fundamentally the practically lagless (near passive adaptor) is what you want. Just buffering delay of only a few micropackets, and be done with it -- and you've got very sub-millisecond delays.

I don't know what the exact transceiver lag (the HDMI/DisplayPort transmitter-receiver lag) but it's likely less than 1ms for both ends totalled. I'm able to go from API-to-photons in less than 3ms, including LCD GtG on some dispays, and RTINGs tested 3-to-4ms over digital for several gaming monitors which is the full chain including LCD pixel response. That's GPU-to-photons latency! Remember different lag testers have a VSYNC ON bias (e.g. Leo Bodnar) and a VSYNC OFF bias (e.g. TFTCentral.co.uk SMTT method). Only the VSYNC OFF bias lag tests will properly reveal adaptor lag. Current transceiver lag is probably under 1ms(ish).

So, it is possible to make this a moot issue, especially with beam racing.

Eventually, Blur Busters plans to do adaptor-lag testing (This is a 2019 project for me), so keep tuned.

[buckrogers]

Excellent. Speaking of HDMI to vga adaptors:

https://shmups.system11.org/viewtopic.php?f=6&t=59860

I just remembered I have a hd fury 3 somewhere (and an Extron but recall it as introducing some lag) that I will test with a modern NVidia or Radeon and toastyx's CRU in the coming weeks. Hopefully I can get Amiga authentic resolutions working on a crt with beam-racing.

[mdrejhon]

You should be able to get subframe latency with a HDFury with a CRT + WinUAE beamraced VSYNC.

The million yen question will be whether it'll passthrough authentic resolutions, but I can confirm my GeForce 1080 Ti HDMI output is capable of weird refresh rates like 50Hz and 240Hz with crazy signal timings, so not a problem with custom rez and custom blankings over HDMI. Certainly it is not HDMI spec modes but every GeForce/Radeon HDMI outputs in the last many years are 100% CRU flexible and I can push CRT blankings (e.g. CVT, GTF) out of my HDMI.

So all it needs is a 1:1 adaptor conversion to preserve original CRT timings. The problem is adaptor preserving the custom mode 1:1. Many don't.

_____

P.S. Offtopic, but new sneak preview of my beam racing demo (Tearline Jedi) -- [ Show youtube player ]
This is only a demo but has the programming techniques necessary to teach programmers about beam racing. Which will help them better understand Lagless VSYNC (beamraced tearingless VSYNC OFF)

[buckrogers]

On the topic of using CRTs, according to toastyx the author of the Custom Resolution Utility (CRU), if the monitor doesn't have an EDID, you're better off with an NVidia because AMD's driver has bugs with non-EDID monitors. Otherwise, either should work fine. I assume this only applies to non-PC CRTs such as the sony pvm and bvm pro monitors.

[mdrejhon]

To update you all,

About the open source code I promised for raster-register-free cross platform beam racing (Which can be useful to emulator authors):

My Tear Line Jedi rasterdemo will be opensourced once I decide if I should try to submit it to a demoscene party first. They require I submit before I opensource, so thus a little delay since some people are asking me to submit it to a demoscene first.

The videos of the Tearline Jedi rasterdemo has gotten some rave comments by the retro demoscene so far (at least for the brilliant "tearlines-commandered-as-rasters" technique, but not for the ugly graphics) and this is encouraging me to consider a submission first. So I'll give that a honest try first.

Here's the relevant BlurBusters Forums thread and the pouet.net Demoscene Forums thread recruiting a volunteer programmer for co-credit.

In those threads, I have posted a new video to hopefully finally recruit a demoscene volunteer: The first cross-platform real-raster Kefrens bars generated by GeForce/Radeon GPUs on both PC/Mac.



Real-raster Kefrens Bars on standard GPUs via an abuse of standard API calls. I intentionally glitch it near the end by dragging around a window, which screws around the raster timings. Yes, those are real-time raster-generated pixel rows crammed through overkill VSYNC OFF standard APIs at 8000 frame slices per second. Each framebuffer is 1 pixel row, at 8000 framebuffers per second, with tearlines dividing each Kefrens Bars pixel row.

It's way overkill for emulator use, but it demonstrates some really neat raster-realtimeness. The pixel rows are hitting the graphics port output as little as 1/8000sec after the Present() API call (Direct3D) or glutSwapBuffers() API call (OpenGL). Looks identical with Direct3D/OpenGL and PC/Mac.