Got a G-Sync monitor--are you willing to help?

[bulbousbeard]

Hello,

I got a G-Sync monitor here, and I'm willing to send it to Calamity, but I don't know if he has a Geforce 600 series+ video card. If he doesn't, someone else is going to have to help chip in. We need to get Calamity a video card and ship him this hardware.

Here's the problem: G-Sync isn't good enough on its own. We need black frame insertion, but we don't want to force every game to run at 120hz. We want every game to run at double its native refresh rate (possibly quadruple its refresh rate for 30hz games such as Rampage) and add black frames. Even if changing MAME's throttling mechanism to make this happen is impossible, at the very least, these G-Sync monitors are all variable refresh rate panels (30hz - 144hz). At the very least, even if we're stuck using V-Sync, these monitors really should be able to run at double the game's native refresh rate with black frame insertion even if we have to use Powerstrip or some other bullfuckery.

Here are my initial impressions after testing the G-Sync monitor for a day:

* G-Sync is incredibly rough around the edges right now. It's buggy, things don't work consistently, and you're constantly losing your ULMB (Ultra Low Motion Blur) settings when you switch from application to application. The latest Nvidia beta drivers don't even WORK with G-Sync. This is NOT consumer ready yet. This is prototype hardware as far as I'm concerned. I wouldn't buy this expecting to use it as your main monitor.

* The Asus VG248QE monitor that Nvidia built the G-Sync module for is a piece of ---steaming pile of meadow muffin---. It has a laughably awful backlight, color reproduction gives off the distinct whiff of ass, and 1080p isn't even close to enough resolution to do HLSL properly. You're really looking at 1600p minimum before HLSL even starts to look decent. This monitor isn't good enough for a high quality arcade cabinet. You're going to want to wait for at least the 27" Asus 1440p monitor coming out in Q2 this year.

* ULMB (Ultra Low Motion Blur) is the new G-Sync strobed backlight method, and it's pretty fantastic on the desktop. I can use auto-scroll in my web browser, rapidly scroll through a page, and still make out most of the text because it's not blurred to ---fudgesicle---. I don't have to stop to read the text anymore.

* Even though Nvidia's pretending that most applications will "just work" with G-Sync, emulation is an entirely different story. If G-Sync monitors were widely available in 1997, MAME would have been designed a lot differently. The basic throttling mechanisms that emulators use simply don't make sense anymore when you have a G-Sync monitor. MAME's core requires significant work to really take advantage of this technology.

* MAME and G-Sync don't really work that well together as it stands. For example, if I have HLSL on, G-Sync works fine, and everything is smooth, but if I disable HLSL, use D3D, but only use prescale X and don't turn on HLSL, I can see noticeable tearing. It's almost as if G-Sync doesn't actually turn on unless the GPU is doing a certain amount of work. It's got to be a bug. The company that sold me this monitor actually said that a second revision of G-Sync DIY kits are going to be released; I think that the first run is glitchy and has a lot of problems.

* GroovyMAME's current black frame insertion solution doesn't work well. It periodically flashes white or black. It's far from ready to go for a cabinet.

* With G-Sync, you can run GroovyMAME on an LCD with frame_delay without getting that weird tearing effect. I think VERY low input lag solutions are possible with this setup. You could do double the native refresh rate AND framedelay. It seems like you could get input lag down to virtually nothing.

* BSNES is a piece of ---steaming pile of meadow muffin--- program. It might be the most accurate SNES emulator in the world, but it's a ---smurfy--- Windows program. It stutters, it hitches, it doesn't even have a full screen exclusive mode. It sucks. It doesn't work with G-Sync at all. Useless emulator. Who cares if you're accurate when the program itself doesn't run well? I wouldn't ever actually want to PLAY A GAME with BSNES in its current state, so what good is it?

* Kega Fusion does work with G-Sync, but it has no HLSL options, so it looks like crap.

* Guacamelee works with G-Sync and even supports 120hz and 144hz refresh rates natively.

* Playing the Mega Play version of Sonic the Hedgehog 2 in Groovy UME with black frame insertion on is pretty staggering. There's basically no motion blur--even when running around at maximum speed. You don't even believe what you're seeing initially. It really does give you a glimmer of a possible future in which we don't need CRTs anymore for a decent picture in fast-moving games. That's the NICE part of black frame insertion. Here's the bad part...

* Black frame insertion isn't a silver bullet. It DOES look worse than an LCD back light running normally. It's as if a faint fog is covering the monitor. Color quality is diminished. It might partially be this piece of ---steaming pile of meadow muffin--- VG248QE panel, but the colors aren't vibrant at all. A great CRT is VIVACIOUS. The colors are so bright and vibrant. With black frame insertion on, it's like you're walking around on a cloudy day in the rain. I'm not entirely sold on it.

* Interestingly, G-Sync seems to make a more compelling difference in newer PC games than it does in MAME. Diablo 3, which is notorious for being a stuttery, hitchy pile of crap, runs butter-smooth with G-Sync on. It makes a huge difference. If you've played Diablo 3, you've probably experienced the game's constant hiccups. They're almost entirely gone with G-Sync on. It's like playing DOOM with the frame cap removed for the first time. It's a crisp slap in the face.

* Contrary to the ---That which is odiferous and causeth plants to grow--- and misinformation that's been spread, G-Sync works with OpenGL. It works perfectly with Quake 3.

* This G-Sync monitor is Display Port only. I can see why people dislike Display Port; my BIOS doesn't even show with this piece of crap. I don't get an image until Windows has booted.

I more or less can see how it's going to play out in the future. A 4K resolution, 30" OLED monitor with G-Sync or a similar technology is basically going to be the tech that can practically replace a CRT (really, be even better than a CRT).

[edekoning]

That's an interesting read! When I first read about G-Sync, I was all excited about what this could mean for emulation. If I understand you correctly it only works good with applications that don't try to be smart, as in they just output a frame whenever they can. As Mame and possibly other emulators try to do smart things to work around the fixed refresh rate limitation of LCDs it just doesn't work right out of the box.

I also do not share your faith in that G-Sync will be part of the future. Currently its very expensive, only available for one monitor, is not an open technology, only works with selected nvidea cards. Also AMD is blurring the picture with their Free-Sync. Now we just have to wait for Intel to come with something Furthermore, consumers don't know WTF this is all about. Even so, I really hope the tech makes it, and becomes compatible with AMD and Intel GPUs. I really want a variable refresh rate LCD

[Calamity]

Hi bulbousbeard,

Thanks for your detailed report. I don't have much time to analize everything now. By reading some information at blurbusters I found G-Sync and Light Boost (or ULMB as they call it now) are mutually exclusive. This doesn't come as a surprise to me but it's definitely a downer.

If G-Sync monitors were widely available in 1997, MAME would have been designed a lot differently. The basic throttling mechanisms that emulators use simply don't make sense anymore when you have a G-Sync monitor. MAME's core requires significant work to really take advantage of this technology.

I'd say this is not exact but I'd like to hear your opinion on why the current throttling doesn't make sense with G-Sync. On the contrary, I'd say the throttling mechanism in MAME had been broken since v0.114 when they decided to keep emulation totally agnostic of the video card's refresh, and ironically, in the end a new technology was invented (G-Sync) that made this throttling model reasonable after all.

[bulbousbeard]

Knowing what we know now, I would have designed MAME to be able to throttle games at different multipliers ie. run games at twice their refresh rate, triple their refresh rate, quadruple refresh rate.

If it had been done like this, it would have been trivial to implement black frame insertion while still keeping games at their native speed.

[Calamity]

Knowing what we know now, I would have designed MAME to be able to throttle games at different multipliers ie. run games at twice their refresh rate, triple their refresh rate, quadruple refresh rate.

If it had been done like this, it would have been trivial to implement black frame insertion while still keeping games at their native speed.

It's interesting that you mention that. See what they've added for next release: http://git.redump.net/mame/commit/?id=c3d99b569510d89c66da013cdec4edd052b0092a

[bulbousbeard]

Wow. That's almost creepy. I'll have to build from the latest SVN and try this with G-Sync.

[bulbousbeard]

Knowing what we know now, I would have designed MAME to be able to throttle games at different multipliers ie. run games at twice their refresh rate, triple their refresh rate, quadruple refresh rate.

If it had been done like this, it would have been trivial to implement black frame insertion while still keeping games at their native speed.

It's interesting that you mention that. See what they've added for next release: http://git.redump.net/mame/commit/?id=c3d99b569510d89c66da013cdec4edd052b0092a

Hi Calamity,

I compiled the latest MAME with this variable throttling change, changed the throttle multiplier to 2, and then added your black frame insertion code.

It almost works, but the problem is that when I do this, it's effectively running at the monitor's refresh rate instead of double the actual game's speed.

The monitor's running at a maximum of 144hz in G-Sync mode, and if I run a 60hz game, it runs at 119.57%.

What's weird, though, is that without the black frame insertion code, running at a maximum of 144hz, with a 2x throttle, the game runs at 200% or 120hz, which is what I'd expect.

I don't understand why it runs at double the game's speed without black frame insertion code but runs at the monitor's maximum refresh rate with black frame insertion code.

MAME's whole timing just seems off and ---smurfy---. If I leave the throttle multiplier at 1x and just add the black frames, I get:
Average speed: 99.55% (54 seconds)

How? Why wouldn't it be 100%?

Can you help me work this out?

[Calamity]

Hi bulbousbeard,

I don't know how you've added my black frame insertion code exactly. Just be aware my implementation relies on syncrefresh, this means the normal throttling is bypassed and I would expect everything running at the monitor's refresh.

A proper implementation following the g-sync logic would require the variable throttling factor set so that the game runs at twice its original speed (halving the wait time for each frame), and at the same time, you'd need to call "update throttle" twice per frame, one before blitting the actual frame, and one right before drawing the black frame. That will make the speed equal the original rate.

[bulbousbeard]

Calamity,

That's how I changed it, but it doesn't seem to work. The speed is still refresh rate dependent.

With a 120hz desktop:
Average speed: 99.58% (41 seconds)

With a 144hz desktop:
Average speed: 119.39% (50 seconds)

This is how I modified it:
http://pastebin.com/XFzK9eQt

I've tried using the same current_time for both update_throttles and defining a new one. It doesn't make a difference.

The other thing I'm noticing is that if I pause the emulator, the black frame insertion gets really flickery like it's updating too many times.

The throttling code seems wonky, too. It seems refresh rate dependent. For example, if I modify the code as seen in the pastebin link, but I leave the throttle_rate at 1.0f, it's actually CLOSER to the proper speed regardless of the desktop refresh rate.

At 120hz and 144hz, I get this speed with throttle_rate 1.0f and black frame insertion:
Average speed: 98.38% (59 seconds)

There's probably something very basic that I'm missing.

[Calamity]

Well, that sounds rather puzzling from here. Some thoughts:

- The refresh could be actually limiting the top speed somehow, even if you have triplebuffering & syncrefresh disabled. This would happen if the "Present" method didn't return immediately, in other words, if some sort of wait for vsync was performed internally by the driver. Yes, I know G-sync should abolish any form of vsync all together, but there still could be some internal granularity. Maybe you could try enabling -multithreading, to decouple emulation from video routines. If you magically see things running at the correct speed, then we can deduce the video code is actually anchoring the speed.

- Maybe, the throttling can't be used twice in a frame without further modifications. Depending on how things are done, on a second run within the same frame it could just notice the real time and emulation time already match and simply exit without waiting.

[bulbousbeard]

Well, that sounds rather puzzling from here. Some thoughts:

- The refresh could be actually limiting the top speed somehow, even if you have triplebuffering & syncrefresh disabled. This would happen if the "Present" method didn't return immediately, in other words, if some sort of wait for vsync was performed internally by the driver. Yes, I know G-sync should abolish any form of vsync all together, but there still could be some internal granularity. Maybe you could try enabling -multithreading, to decouple emulation from video routines. If you magically see things running at the correct speed, then we can deduce the video code is actually anchoring the speed.

- Maybe, the throttling can't be used twice in a frame without further modifications. Depending on how things are done, on a second run within the same frame it could just notice the real time and emulation time already match and simply exit without waiting.

Turning on multithreading completely broke MAME. Inputs took like 30 seconds to register.

Yeah...this needs someone with more expertise than I have. It's too bad, because G-Sync is potentially amazing for MAME.

[SyrianJoe]

In regards to bsnes, it has terrible sync.

I instead recommend trying out RetroArch, which is a frontend that can play programs/emulators ported to it. It includes bsnes. The sync it uses is called "Dynamic Rate Control". It's really quite simple and ingenious.

https://github.com/libretro/libretro.github.com/raw/master/documents/ratecontrol.pdf
http://www.libretro.com/

Dev builds:
https://www.dropbox.com/sh/91sakv0qdyxjx9f/cGOfV7ZOKd

[bulbousbeard]

In regards to bsnes, it has terrible sync.

I instead recommend trying out RetroArch, which is a frontend that can play programs/emulators ported to it. It includes bsnes. The sync it uses is called "Dynamic Rate Control". It's really quite simple and ingenious.

https://github.com/libretro/libretro.github.com/raw/master/documents/ratecontrol.pdf
http://www.libretro.com/

Dev builds:
https://www.dropbox.com/sh/91sakv0qdyxjx9f/cGOfV7ZOKd

Can you even run Retroarch from the command line or are you stuck with its GUI?

I have my own frontend.

[Calamity]

Turning on multithreading completely broke MAME. Inputs took like 30 seconds to register.

  This suggests the video routines are actually locking the window thread for input, in other words, the Present method does not return immediately as if they where actually doing vsync inside a black box. Of course this is just an idea, I may be totally wrong.

When I have some time I'll try writting a modification of the throttling routine that allows being called twice per frame for half the wait. I'd rather see how the final version of the throttling code is for v0.153 and then work on it.

[Dr.Venom]

* BSNES is a piece of ---steaming pile of meadow muffin--- program. It might be the most accurate SNES emulator in the world, but it's a ---smurfy--- Windows program. It stutters, it hitches, it doesn't even have a full screen exclusive mode. It sucks. It doesn't work with G-Sync at all. Useless emulator. Who cares if you're accurate when the program itself doesn't run well? I wouldn't ever actually want to PLAY A GAME with BSNES in its current state, so what good is it?

Hi bulbousbeard,

Thanks for posting the results about G-Sync, very helpful.

With regards to BSNES, I think you may be wrong with your conclusion.  There are just a few things you have to keep in mind when using it on Windows:

1. It's a program that runs in full-window mode when you press F11 for full screen. This means that in Windows 7 it's fighting with Aero for Vsync. So you absolutely need to disable Aero before running it, otherwise you'll get frequent stuttering.
2. In the menu for sync options, choose to -only- sync to video. Do not choose sync to both video and audio or audio alone.
3. In advanced settings make sure you set the correct video refresh of your real host PC monitor and set the correct real rate of your audio (you can use the program Freqtest as mentioned in one of the other threads to measure both)

Hope that helps. It should result in excellent smooth running vsynced emulation, at least it does for me.

[bulbousbeard]

Hi Dr. Venom,

Well, that's exactly my point. Why is BSNES the only program that makes you disable Aero? Why do MAME, Kega Fusion, and every other emulator have a full screen exclusive mode and work fine?

BSNES is the oddball here, and it will never work with G-Sync as long as it doesn't support full screen exclusive modes.

[rock145]

Are there any updates on free sync and G-sync with groovymame or regular mame. I am interested in buying one of these type of monitors for home use.

[M_W]

I use a G-sync monitor with GroovyMAME and I'm highly satisfied. Granted, black frame insertion still doesn't work properly, and otherwise it's not doing much over mainline MAME other than reducing lag, but I'm happy with the results. Zero tearing and 100% perfect game speed.

[rock145]

I use a G-sync monitor with GroovyMAME and I'm highly satisfied. Granted, black frame insertion still doesn't work properly, and otherwise it's not doing much over mainline MAME other than reducing lag, but I'm happy with the results. Zero tearing and 100% perfect game speed.

Thanks for the reply. Could groovymame work with freesync the same way as g sync. I find that freesync monitors are cheaper to buy and in theory offer higher ranges. I heard that freesync could allow 9hz-144hz ranges but I have not seem it in any monitors. Its usually from 30hz-144hz range. 

[M_W]

FreeSync will work exactly the same way. Turn off autosync, disable syncrefresh and triple buffering, and don't turn on black frame insertion (it won't work properly). Truthfully, you aren't getting much benefit out of GroovyMAME over mainline MAME, at least on the video side. I use it exclusively to reduce input lag using the BGFX renderer and/or frame_delay.

[rock145]

FreeSync will work exactly the same way. Turn off autosync, disable syncrefresh and triple buffering, and don't turn on black frame insertion (it won't work properly). Truthfully, you aren't getting much benefit out of GroovyMAME over mainline MAME, at least on the video side. I use it exclusively to reduce input lag using the BGFX renderer and/or frame_delay.

Thanks for the clarification. Do you think groovymame and mame benefit from a freesync or g sync 30-144hz range right now?. Since the games will be run at 60hz. In order to take advantage of the 30-144hz range groovymame and mame would need to implement a feature to use does ranges. I don't know if its capable right now can you clarify this. Will monitors with a 48-60hz or 40-75hz range in freesync be enough or would groovymame or mame benefit more from monitors with a 30-144hz range. I find the monitors with freesync 48-60hz or 40-75hz ranges are cheaper than the 144hz max range. Tell me what do you think.

[Calamity]

Truthfully, you aren't getting much benefit out of GroovyMAME over mainline MAME, at least on the video side. I use it exclusively to reduce input lag using the BGFX renderer and/or frame_delay.

I was curious why someone would use GroovyMAME instead of mainline for a free-sync/G-sync monitor. Frame delay won't work as long as you don't enable syncrefresh too, so... Now, the BGFX reduced latency makes sense. I'm interested on whether there's a noticeable latency reduction or not, before I consider submitting this change to mainline.

[M_W]

Truthfully, you aren't getting much benefit out of GroovyMAME over mainline MAME, at least on the video side. I use it exclusively to reduce input lag using the BGFX renderer and/or frame_delay.

I was curious why someone would use GroovyMAME instead of mainline for a free-sync/G-sync monitor. Frame delay won't work as long as you don't enable syncrefresh too, so... Now, the BGFX reduced latency makes sense. I'm interested on whether there's a noticeable latency reduction or not, before I consider submitting this change to mainline.

I want to say I notice a slight reduction in 3rd Strike (sfiii3nr1), but it honestly could all be in my head. It's at least as good as 3rd Strike Online Edition for consoles, which is an amazing port, regardless of what the nerds say.

Case in point: I probably thought I was seeing improvements with frame_delay, even though it was doing nothing with v sync and syncrefresh disabled, so I might be full of it :^). Objective testing is required.

I played around with an A/B test of groovyMAME with BGFX and mainline, and I'm fairly convinced the reduction in latency is not all in my imagination. I can't imagine the reduction is more than a frame, but I'm much happier playing in GM so far.

[rock145]

FreeSync will work exactly the same way. Turn off autosync, disable syncrefresh and triple buffering, and don't turn on black frame insertion (it won't work properly). Truthfully, you aren't getting much benefit out of GroovyMAME over mainline MAME, at least on the video side. I use it exclusively to reduce input lag using the BGFX renderer and/or frame_delay.

 Can you tell me what frame_delay setting you have in groovymame.

[M_W]

Can you tell me what frame_delay setting you have in groovymame.

Frame delay won't work as long as you don't enable syncrefresh too, so...

It doesn't do anything if you disable "syncrefresh" which you should leave off because it defeats the purpose of having a G-Sync monitor.

I did some blind A/B tests between GroovyMAME using the BGFX renderer and mainline MAME using default settings, and I honestly couldn't tell the difference in terms of input lag. If there was a difference, it was a frame at most.

That being said, proper black frame insertion support would be tops :^)