English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 16 April 2018, 09:19   #221
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 22,997
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.
Toni Wilen is online now  
Old 20 April 2018, 13:49   #222
buckrogers
Registered User
buckrogers's Avatar
 
Join Date: Feb 2005
Location: Australia
Age: 41
Posts: 100
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?
buckrogers is offline  
Old 20 April 2018, 16:22   #223
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 22,997
Quote:
Originally Posted by buckrogers View Post
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
Toni Wilen is online now  
Old 20 April 2018, 18:03   #224
mdrejhon
Chief Blur Buster
mdrejhon's Avatar
 
Join Date: Mar 2013
Location: Toronto, Canada
Posts: 39
Quote:
Originally Posted by buckrogers View Post
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!).
mdrejhon is offline  
Old 21 April 2018, 00:40   #225
buckrogers
Registered User
buckrogers's Avatar
 
Join Date: Feb 2005
Location: Australia
Age: 41
Posts: 100
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?

Last edited by buckrogers; 21 April 2018 at 01:10.
buckrogers is offline  
Old 21 April 2018, 03:25   #226
buckrogers
Registered User
buckrogers's Avatar
 
Join Date: Feb 2005
Location: Australia
Age: 41
Posts: 100
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).

Last edited by buckrogers; 21 April 2018 at 04:00.
buckrogers is offline  
Old 22 April 2018, 06:28   #227
mdrejhon
Chief Blur Buster
mdrejhon's Avatar
 
Join Date: Mar 2013
Location: Toronto, Canada
Posts: 39
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.

Last edited by mdrejhon; 22 April 2018 at 06:33.
mdrejhon is offline  
Old 22 April 2018, 11:33   #228
buckrogers
Registered User
buckrogers's Avatar
 
Join Date: Feb 2005
Location: Australia
Age: 41
Posts: 100
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.

Last edited by buckrogers; 22 April 2018 at 11:49.
buckrogers is offline  
Old 23 April 2018, 06:09   #229
mdrejhon
Chief Blur Buster
mdrejhon's Avatar
 
Join Date: Mar 2013
Location: Toronto, Canada
Posts: 39
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)

Last edited by mdrejhon; 25 April 2018 at 04:04.
mdrejhon is offline  
Old 23 April 2018, 09:36   #230
buckrogers
Registered User
buckrogers's Avatar
 
Join Date: Feb 2005
Location: Australia
Age: 41
Posts: 100
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.
buckrogers is offline  
Old 12 June 2018, 19:24   #231
mdrejhon
Chief Blur Buster
mdrejhon's Avatar
 
Join Date: Mar 2013
Location: Toronto, Canada
Posts: 39
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.

Last edited by mdrejhon; 12 June 2018 at 21:53.
mdrejhon is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Photos and/or measurements of Amiga 500 bLAZER request.Other 144 16 October 2018 01:40
A method for further improving latency (input lag) in FS-UAE Dr.Venom support.FS-UAE 4 12 September 2017 16:49
Optimizing DirectX apps for low latency input and longer battery life Dr.Venom support.WinUAE 2 24 April 2017 09:40
What are the measurements of Amiga 1200 case screws Tallrot support.Hardware 9 15 June 2016 10:04
A1200 and B1230 Voltage Measurements for Dummies? Jarin support.Hardware 2 23 January 2014 10:02

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:58.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.07798 seconds with 14 queries