|
Ultra Low Input Lag (10ms less!) via fixed-refresh 60Hz G-SYNC for emulators
#316328 - 10/24/13 12:01 PM
|
|
|
G-SYNC is a variable refresh rate technology announced by NVIDIA, running dynamically at 30Hz->144Hz. Monitor refreshes immediately upon Direct3D frame presentation, instead of waiting till the next VSYNC. Before, 60Hz monitors needed 1/60sec to transmit the refresh from the GPU to the monitor. Not anymore. In a G-SYNC monitor, the frame transmission time is always 1/144sec, even during 60fps.
Apparently, this makes it possible to do ultralow input lag 60Hz for emulators!
For developers, it is actually very simple to run G-SYNC at a fixed refresh rate: Basically, emulator runs at 60fps@60Hz, but with frame transmission times of 1/144th of a second from GPU to display. In G-SYNC mode, you just simply do Direct3D Present() 60 times a second accurately (based on QueryPerformanceCounter()), and viola! G-SYNC 144Hz running at 60fps@60Hz.
1/60sec frame transmission to monitor = 16.7ms (traditional VSYNC at 60Hz)
1/144sec frame transmission to monitor = 6.9ms (G-SYNC)
Input lag reduction = almost 10ms
To Emulator Users: Tell your emulator creators, link to this post.
To Emulator Creators: It's a very simple programming change to emulators:
- A command line option or mode that ignores VSYNC, and instead uses microsecond-accurate timer to call Direct3D Present(). This allows the emulator to control a G-SYNC monitor's immediate refresh (e.g. 50Hz or 60Hz). The emulator briefly runs as fast as possible for 1/60sec (surged emulation execution) then frame is immediately delivered as fast as possible to the monitor (in 1/144sec) without waiting for VSYNC. Rinse and repeat 60 times a second. Low input lag bliss.
Mark Rejhon
Blur Busters Blog | Blur Busters Forums
Edited by Blur Busters (12/25/13 07:59 PM)
|
|
|
Stiletto |
|
They're always after me Lucky ROMS!
|
|
|
|
|
|
Reged: 03/07/04
|
|
Posts: 6472
|
|
|
|
|
|
Send PM
|
|
|
Too slow, hot shot.
[Re: Blur Busters]
#316330 - 10/24/13 03:18 PM
|
|
|
http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Board=mamechat&Number=316104
FYI: It seems to be only on Windows, and only on nVidia, so it falls outside MAME's "must be portable" scope... but no doubt when the hardware reaches developer hands, someone will play with it. No doubt AMD will come up with a competing technology, though it may be a while because nVidia "scooped" them and already has monitor mfg. partnerships.
- Stiletto
|
|
|
|
Re: Ultra Low Input Lag (10ms less!) via fixed-refresh 60Hz G-SYNC for emulators
[Re: Blur Busters]
#316332 - 10/24/13 03:38 PM
|
|
|
That is a great news for me, and the Nvidia Fans too.
|
|
|
|
Re: Too slow, hot shot.
[Re: Stiletto]
#316333 - 10/24/13 03:41 PM
|
|
|
I wouldn't count it out from showing up on Linux fairly quickly, with how Valve is pushing the Steambox/SteamOS line.
I'm hoping nVidia learned from the PhysX fiasco. Locking down PhysX as hard as they did almost killed adoption of the technology, and I suspect GSync will fail the same way if they pull the same stunt.
Implementation in MAME, well, that remains to be seen. I wouldn't count it out even if it were a Windows-only technology, though, because it has the potential to be quite important for preservation.
|
---
Try checking the MAME manual at http://docs.mamedev.org
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Too slow, hot shot.
[Re: Stiletto]
#316335 - 10/24/13 05:15 PM
|
|
|
> FYI: It seems to be only on Windows, and only on nVidia, so it falls outside MAME's
> "must be portable" scope...
I'll be surprised if it isn't supported in Linux as well; Nvidia's Linux drivers are built from the same codebase as the Windows drivers, and they're a launch partner for the SteamBox.
Mac is likely to be the odd one out since Apple writes their own GPU drivers to try and guarantee identical behavior across GPUs and prevent GPU makers from cheating.
|
|
|
|
Re: Too slow, hot shot.
[Re: Firehawke]
#316337 - 10/24/13 06:34 PM
|
|
|
As far as I understand, I think there's nothing special to implement on the MAME side. As it is now, just running with -throttle -nosyncrefresh -nowaitvsync -notriplebuffer already makes D3D Present() to be called with the D3DPRESENT_INTERVAL_IMMEDIATE flag. You should only make sure that a Gsync capable video mode is chosen for the desktop.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Too slow, hot shot.
[Re: Calamity]
#316340 - 10/24/13 07:52 PM
|
|
|
> As far as I understand, I think there's nothing special to implement on the MAME
> side. As it is now, just running with -throttle -nosyncrefresh -nowaitvsync
> -notriplebuffer already makes D3D Present() to be called with the
> D3DPRESENT_INTERVAL_IMMEDIATE flag. You should only make sure that a Gsync capable
> video mode is chosen for the desktop.
Yup, that's what I thought too.
|
|
|
|
Re: Too slow, hot shot.
[Re: Calamity]
#316351 - 10/25/13 02:49 AM
|
|
|
> As far as I understand, I think there's nothing special to implement on the MAME
> side. As it is now, just running with -throttle -nosyncrefresh -nowaitvsync
> -notriplebuffer already makes D3D Present() to be called with the
> D3DPRESENT_INTERVAL_IMMEDIATE flag. You should only make sure that a Gsync capable
> video mode is chosen for the desktop.
Good news, then MAME would already be GSYNC-ready. Plus, you get to play those 53Hz midway games and 60.1Hz at their true rates.
Note: I presume MAME has a Direct3D full screen mode, to avoid the desktop compositing input lag?
|
|
|
|
Re: Too slow, hot shot.
[Re: Stiletto]
#316352 - 10/25/13 02:52 AM
|
|
|
> http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Board=mamechat&Number=316104
Good one.
But that other post actually doesn't explain the concept of accelerated frame delivery/accelerated scanout (e.g. 60Hz refresh scanout in 1/144sec). No input lag calculations over there.
Inevitably, people are going to say "Yawn. Another useless proprietary technology goes down the toilet" unless they realize G-SYNC actually accelerates individual frame delivery times/scanout times to the screen. Major input lag reduction. Then they change their tune and say "Man, that sounds good and useful. Wish it wasn't proprietary".
|
|
|
|
|
It is a shame this tech couldn't be done entirely in software. I can deal with buying a new monitor or a gfx card, but both a the same time are gonna hurt! I'll also need to wait till this trickles down to midrange gfx cards.
|
|
|
|
Re: Damn
[Re: DiodeDude]
#316363 - 10/25/13 10:18 AM
|
|
|
> It is a shame this tech couldn't be done entirely in software. I can deal with buying
> a new monitor or a gfx card, but both a the same time are gonna hurt! I'll also need
> to wait till this trickles down to midrange gfx cards.
It can be done in software, and has been.
|
I do all that stuff even without a Joystick 
Soft-15kHz, cabMAME, For Amusement Only e.V.
|
|
|
Examples?
[Re: SailorSat]
#316364 - 10/25/13 11:18 AM
|
|
|
I mean, totally software, works with standard monitor, gfx card.
|
|
|
|
Re: Examples?
[Re: DiodeDude]
#316365 - 10/25/13 11:40 AM
|
|
|
> I mean, totally software, works with standard monitor, gfx card.
winuae low latency vsync
MAME (with vsync and throttle)
there also was a direct3d example for triple buffering without vsync.
While I can see the impact on "mordern" games (designed with unstable framerates in mind) and mid-range gaming rigs, i still don't see the big deal for emulation use.
You can ran MAME at 120Hz or 144Hz with "classic" double buffering (and throttle) anyway.
|
I do all that stuff even without a Joystick
Soft-15kHz, cabMAME, For Amusement Only e.V.
|
|
|
Re: Examples?
[Re: SailorSat]
#316366 - 10/25/13 01:32 PM
|
|
|
Quote:
1/144sec frame transmission to monitor = 6.9ms (G-SYNC)
Well, if this is how the thing actually works, then this technology is pure smoke. I thought the monitor would really show the frame as soon as it's signaled by the video card, at any arbitrary rate (between a range). If it's simply 6.9ms granular then there's nothing to see here, I agree SailorSat, you can definitely do the same thing by triple buffering on a 144 Hz monitor (I mean real triple buffering of course, not the fake circular frame queue implementation in DirectX), they would be just moving the triple buffering inside the monitor board. I want to believe they're doing it the right way so let's be prudent.
|
|
|
|
Re: Examples?
[Re: Calamity]
#316387 - 10/25/13 08:43 PM
|
|
|
> 1/144sec frame transmission to monitor = 6.9ms (G-SYNC)
>
> Well, if this is how the thing actually works, then this technology is pure smoke. I
> thought the monitor would really show the frame as soon as it's signaled by the video
> card, at any arbitrary rate (between a range). If it's simply 6.9ms granular then
Not granular. You can have any intervals between frames, as long as it's >= 1/144sec (6.9ms).
The point I am making is...
All monitors, running at 60Hz, have ALWAYS taken 1/60sec (= 16.7ms) to transmit the frame to the display. CRT, LCD, DLP, plasma. Even your 120Hz monitor configured to 60Hz mode. See high speed video. Top-to-bottom scan.
High speed video of CRT: http://www.youtube.com/watch?v=zVS6QewZsi4
High speed video of LCD: http://www.youtube.com/watch?v=nCHgmCxGEzY
Observe how all of them take 1/60sec to "paint" the image from top the bottom? Exactly. Frames have never been delivered "instantaneously" all at once to the displays. Never has been before. For over 75 years, back to the first televisions, we've always had finite speed delivery of images to the screen. Yes, it's dissapointing.
So you see, G-SYNC revolutionizes frame transmission times, by decoupling the scantime from the refresh rate. Instead of 60Hz frames taking 1/60sec to scan top-to-bottom.
You get 60Hz frames taking 1/144sec to scan top-to-bottom. Frame delivery times are revolutionized by G-SYNC. Someday, we might even have instantaneous frame delivery times (Direct3D Present() instantaneously shows whole image to your human eye balls, in 0ms) -- we're not there yet -- but reduction of 16.7ms scanout at 60Hz on all 60Hz displays in history, is greatly reduced to a mere 6.9ms scanout at 60Hz on G-SYNC.
Instead of scanout being dependant on refresh rate (e.g. 60Hz having 1/60sec scanout, 85Hz having 1/85sec scanout, 100hz having 1/100sec scanout), all refresh rates (50Hz, 60Hz, 100hz, whatever), now all have 1/144sec scanout! That's another reason makes G-SYNC so revolutionary for emulators, from an input lag perspective!
______
The faster frame delivery time is another advantage in addition to the variable refresh rate.
So, yes, it is already what you thought it was earlier, but *even* better.
For emulators:
(1) G-SYNC advantage #1: variable refresh rates controlled by Direct3D Present(). 50Hz, 53Hz, 60Hz, 60.1Hz is easy. Zero speedups/slowdowns.
(2) G-SYNC advantage #2: faster frame delivery/scanout. 60Hz frames delivered to monitor faster over the cable, and painted onscreen, than any past display running 60Hz.
(3) G-SYNC advantage #3: stutter elimination (16.8ms won't cause you to miss VSYNC, it'll refresh right away)
Edited by Blur Busters (10/25/13 09:08 PM)
|
|
|
|
Re: Damn
[Re: SailorSat]
#316388 - 10/25/13 08:45 PM
|
|
|
> It can be done in software, and has been.
Not for G-SYNC's technique, advantages for emulators:
(1) G-SYNC advantage #1: variable refresh rates.
Refreshes can begin immediately. Instead of using VSYNC ON, you display the frame immediately upon Direct3D Present().
(2) G-SYNC advantage #2: faster frame delivery, no matter what refresh rate
When you're using refresh rates less than G-SYNC's top refresh rates, the frame delivery times are still at full speed. Frame delivery accelerated compared to older monitors of the same refresh rates. e.g. 60Hz on G-SYNC is scanned-out faster than 60Hz on old monitors.
(3) G-SYNC advantage #3: stutter elimination during missed VSYNC's
If you're late and miss a goal time (e.g. taking 16.8ms instead of 16.7ms) the monitor can begin refreshing the frame immediately, without forcing you to wait until the next refresh cycle.
Edited by Blur Busters (10/25/13 09:07 PM)
|
|
|
|
Re: Examples?
[Re: Blur Busters]
#316396 - 10/25/13 10:31 PM
|
|
|
> Frames have never been delivered "instantaneously" all at once to the
> displays. Never has been before. For over 75 years, back to the first televisions,
> we've always had finite speed delivery of images to the screen. Yes, it's
> dissapointing.
Thanks Mark, yes I know that trasferring the picture information to the screen is actually a *process* that consumes time, those are very basic concepts. Now I see what you meant about the 6.9ms frame transition to monitor, you're talking about a bandwidth limitation. I understood you were suggesting the monitor was actually working at a fixed rate of 144 Hz, so unless an integer quotient of that frequency was used, say 36 or 72, you'd still be in a situation where some frames would be on screen twice as long as others. On the other hand, I see no reason why it couldn't work as you say, with truly arbitrary non-granular frame spacing. Indeed, LCD monitors don't need to be "refreshed" like CRT monitors, and I consider the fact that till today they've been designed with fixed refresh cycles is a technological paradox.
|
|
|
|
Re: Examples?
[Re: Calamity]
#316400 - 10/25/13 11:36 PM
|
|
|
> Now I see what you meant about the 6.9ms frame transition
> to monitor, you're talking about a bandwidth limitation.
> I understood you were suggesting the monitor was actually
> working at a fixed rate of 144 Hz,
What I meant was that the screen (LCD scanout) is refreshed in 1/144sec; but not at 1/144sec intervals. (can be any variable interval)
So you've got:
-- faster delivery (from computer over cable to display)
....AND....
-- faster scanout (refreshing from top to bottom)
Right now, in 144Hz GSYNC monitors, frame scanout occurs in realtime with delivery (scanout occurs as the bits come over the cable, at the full 144Hz-equivalent bandwidth, but not "144Hz intervals"). My XL2411T and VG278H does realtime scanout (~2-3ms input lag for top edge of screen; more determined by the pixel transition time, measured by my own photodiode/oscilloscope), and G-SYNC monitors do realtime scanout as well.
|
|
|
|
Re: Examples?
[Re: SailorSat]
#316409 - 10/26/13 07:20 AM
|
|
|
> You can ran MAME at 120Hz or 144Hz with "classic" double buffering (and throttle)
> anyway.
It's not the same thing. Without G-Sync you will get harmonics between the games refresh rate and the monitors refresh rate. You'll end up with some frames being visible for longer than others, which makes movement appear jerky like if you try to display a 24fps bluray on a 60hz TV. Your only alternative is to cheat and run the game at the wrong refresh rate.
With G-Sync you have the link from the graphics card to the monitor set at the highest speed (maybe 144hz, maybe more) and pacman can present frames at 60.606060hz. G-Sync is basically about allowing arbitrary delays between frames that can then be sent instantly and not wait for the next 144hz slot.
For that reason I don't believe that what G-Sync claims to do can be implemented with current technology.
Edited by smf (10/26/13 07:22 AM)
|
|
|
|
This
[Re: ]
#316412 - 10/26/13 04:45 PM
|
|
|
Thank you, smf. This is what I was getting at, but didn't have the tech knowledge to explain it 
> > You can ran MAME at 120Hz or 144Hz with "classic" double buffering (and throttle)
> > anyway.
>
> It's not the same thing. Without G-Sync you will get harmonics between the games
> refresh rate and the monitors refresh rate. You'll end up with some frames being
> visible for longer than others, which makes movement appear jerky like if you try to
> display a 24fps bluray on a 60hz TV. Your only alternative is to cheat and run the
> game at the wrong refresh rate.
>
> With G-Sync you have the link from the graphics card to the monitor set at the
> highest speed (maybe 144hz, maybe more) and pacman can present frames at 60.606060hz.
> G-Sync is basically about allowing arbitrary delays between frames that can then be
> sent instantly and not wait for the next 144hz slot.
>
> For that reason I don't believe that what G-Sync claims to do can be implemented with
> current technology.
|
|
|
|
Re: Too slow, hot shot.
[Re: Blur Busters]
#316421 - 10/26/13 07:55 PM
|
|
|
> >
> http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Board=mamechat&Number=316104
>
> Good one.
>
> But that other post actually doesn't explain the concept of accelerated frame
> delivery/accelerated scanout (e.g. 60Hz refresh scanout in 1/144sec). No input lag
> calculations over there.
>
> Inevitably, people are going to say "Yawn. Another useless proprietary technology
> goes down the toilet" unless they realize G-SYNC actually accelerates individual
> frame delivery times/scanout times to the screen. Major input lag reduction. Then
> they change their tune and say "Man, that sounds good and useful. Wish it wasn't
> proprietary".
Boring, still requires Windows to be "optimal" vs. other OSes, and probably requires Windows 8 or 8.1 at that. nVidia has no place in the 21st century, marketing "11-secret-herbs-and-spices" hardware and software (proprietary, binary-only drivers). In fact, even my toilet deserves better than having a shit-clad, obsolete by design (no drivers for modern Windows) nVidia card stuck in it blocking it up.
|
|
|
|
Re: Too slow, hot shot.
[Re: Heihachi_73]
#316426 - 10/26/13 09:46 PM
|
|
|
> and probably requires Windows 8 or 8.1 at that.
I require window 8 or 8.1, it's too good to go back to 7/Vista/XP.
|
|
|
|
Re: Too slow, hot shot.
[Re: Heihachi_73]
#316430 - 10/26/13 11:59 PM
|
|
|
> Boring, still requires Windows to be "optimal" vs. other OSes,
It works with Windows 7.
Intrisinically, variable refresh rates is simple to the software once the monitor and the graphics card does it; and the drivers expose it to the platform. Variable frame rates are really a truly platform independent concept. Whatever API is used (e.g. Direct3D Present() or OpenGL glFinish()) can be used to cause the refresh to occur immediately. It's potentially platform independent, if NVIDIA wishes, and technically very simple for software to drive the refresh rate, with very few modifications required.
Long term, it could even become part of HDMI 3.0 or another widespread standard, in a standardized manner, as it would also help video playback too (e.g. support 24fps/30fps/60fps/48fps, and seamless framerate switches, unusual framerates such as silent film 14fps/18fps, and future proof 72fps/96fps 120fps framerates, etc)
|
|
|
|
Re: Too slow, hot shot.
[Re: Blur Busters]
#316431 - 10/27/13 12:46 AM
|
|
|
> Long term, it could even become part of HDMI 3.0 or another widespread standard, in a
> standardized manner, as it would also help video playback too (e.g. support
> 24fps/30fps/60fps/48fps, and seamless framerate switches, unusual framerates such as
> silent film 14fps/18fps, and future proof 72fps/96fps 120fps framerates, etc)
I'm always surprised that HDMI doesn't allow for partial refreshes with arbitrary rates.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Examples?
[Re: ]
#316488 - 10/28/13 04:33 PM
|
|
|
> With G-Sync you have the link from the graphics card to the monitor set at the
> highest speed (maybe 144hz, maybe more) and pacman can present frames at 60.606060hz.
> G-Sync is basically about allowing arbitrary delays between frames that can then be
> sent instantly and not wait for the next 144hz slot.
Yup. That's an excellent explanation.
|
|
|
| Stiletto |
|
They're always after me Lucky ROMS!
|
|
|
|
|
|
Reged: 03/07/04
|
|
Posts: 6472
|
|
|
|
|
|
Send PM
|
|
|
Further vendor lock-in
[Re: R. Belmont]
#316642 - 10/31/13 11:12 PM
|
|
|
|
|
|
Re: Further vendor lock-in
[Re: Stiletto]
#316730 - 11/02/13 11:12 AM
|
|
|
|
|
Previous 
Index 
Next 
Threaded 
Ultra Low Input Lag (10ms less!) via fixed-refresh 60Hz G-SYNC for emulators
Reply
[Re: 
