Blur Busters Forums

Sorry if this has been asked already but will it be possible in the future to combine both together? Would you need to buy new hardware or would this be something release through drivers?

It won't be possible to do it via drivers or software --

It would have to be a custom monitor hardware feature, if/when this is introduced eventually.

However, for now, you can do one or the other in the same monitor (GSYNC mode versus ULMB mode), but not enabled at the same time.

What I don't get is the lack of a "partial G-Sync" mode (or rather "fixed refresh G-Sync" or "low latency V-Sync") where you can use ULMB with G-Sync operating on a fixed refresh rate. That is, repeat frames if FPS falls below refresh, and cap FPS to refresh rate. For games that always output enough FPS, the mode would be basically indistinguishable from full G-Sync, except that ULMB would be working since the refresh rate stays constant.

That would lower input lag by quite a bit. And it doesn't sound that difficult to implement. I suspect NVidia didn't actually think of it, otherwise they would have probably done it.

RealNC wrote:What I don't get is the lack of a "partial G-Sync" mode (or rather "fixed refresh G-Sync" or "low latency V-Sync") where you can use ULMB with G-Sync operating on a fixed refresh rate.

The problem is that external limiters (by drivers or hardware) usually add input lag. So this typically won't work well.
The proper way to do low-latency limiters is letting the game control the refresh rate.
Frame rate limiters (fps_max) actually sets a low-latency fixed Hz of a GSYNC monitor, as found in my GSYNC preview #2.
In GSYNC mode, fps_max is equivalent to setting a low latency fixed refresh rate on a GSYNC monitor.

External limiter:
Read Input -> Render Frame -> Present Frame -> Drivers/Monitor delays frame til next fixed interval -> Display Refresh Begins

Internal limiter:
Game Waits Till Next Fixed Interval -> Read Input -> Render Frame -> Present Frame -> Display Refresh Begins

This means less time between input read and frame delivery. It actually also applies to VSYNC ON, not just GSYNC. Did you know that there is actually a LOT less input lag during VSYNC ON when you combine VSYNC ON with fps_max? For example, fps_max 119 during VSYNC ON 120Hz has much lower input lag; the trick is to make fps_max a "hair" underneath the refresh rate. The problem is if you get external things such as drivers or hardware to control your framerate, your software has essentially "given up" control over the timing of the frame delivery. In the long term, new API's need to be invented to easily allow low-latency VSYNC ON, to make things like Just-In-Time VSYNC very easy to do for game developers. Many game developers aren't familiar with how displays are refreshed, since the Microsoft layers, the drivers, the monitors are essentially latency blackboxes beyond the game engine's control. You can supply flags (e.g. immediate presentation), but does one REALLY know exactly how many milliseconds each layer (after Direct3D Present()) takes for a frame to become visible (a.k.a. send photons into your eyeballs)?

TL;DR Internal frame rate limiters (game engine) has lower input lag than external frame rate limiters (drivers/NVInspector/monitor)

Chief Blur Buster wrote:

RealNC wrote:What I don't get is the lack of a "partial G-Sync" mode (or rather "fixed refresh G-Sync" or "low latency V-Sync") where you can use ULMB with G-Sync operating on a fixed refresh rate.

The problem is that external limiters (by drivers or hardware) usually add input lag. So this typically won't work well.
The proper way to do low-latency limiters is letting the game control the refresh rate.
Frame rate limiters (fps_max) actually sets a low-latency fixed Hz of a GSYNC monitor, as found in my GSYNC preview #2.
In GSYNC mode, fps_max is equivalent to setting a low latency fixed refresh rate on a GSYNC monitor.

External limiter:
Read Input -> Render Frame -> Present Frame -> Drivers/Monitor delays frame til next fixed interval -> Display Refresh Begins

Internal limiter:
Game Waits Till Next Fixed Interval -> Read Input -> Render Frame -> Present Frame -> Display Refresh Begins

This means less time between input read and frame delivery. It actually also applies to VSYNC ON, not just GSYNC. Did you know that there is actually a LOT less input lag during VSYNC ON when you combine VSYNC ON with fps_max? For example, fps_max 119 during VSYNC ON 120Hz has much lower input lag; the trick is to make fps_max a "hair" underneath the refresh rate. The problem is if you get external things such as drivers or hardware to control your framerate, your software has essentially "given up" control over the timing of the frame delivery. In the long term, new API's need to be invented to easily allow low-latency VSYNC ON, to make things like Just-In-Time VSYNC very easy to do for game developers. Many game developers aren't familiar with how displays are refreshed, since the Microsoft layers, the drivers, the monitors are essentially latency blackboxes beyond the game engine's control. You can supply flags (e.g. immediate presentation), but does one REALLY know exactly how many milliseconds each layer (after Direct3D Present()) takes for a frame to become visible (a.k.a. send photons into your eyeballs)?

TL;DR Internal frame rate limiters (game engine) has lower input lag than external frame rate limiters (drivers/NVInspector/monitor)

Thank you for the informative post. I took the liberty of quoting you to explain the issue with external frame rate limiters on another forum.

writer21 wrote:Sorry if this has been asked already but will it be possible in the future to combine both together? Would you need to buy new hardware or would this be something release through drivers?

I have an idea: selectable range of frame rates to be strobed in the monitor OSD (i.e. from 60 to 144 fps) and variable brightness and/or persistence in real time to compensate the fluctuation of fps/Hz, so the same brightness remains at all times. If fps are lower than the lowest value you selected, strobing is disabled, or frames are repeated at double the Hz (i.e. 40fps at 80Hz).
If all my "or" can be toggled in the menu, then that's even better .

RealNC wrote:That is, repeat frames if FPS falls below refresh

That would remove an important part of the G-Sync stuttering elimination.

I also would love to have a G-Sync + Strobe solution, but I think the best implementation for that would be the variable refresh rate strobbing algorithm here http://www.blurbusters.com/faq/creating ... blerefresh

I don't see why a firmware/driver update wouldn't be able to implement it on a current G-Sync module though. I thought the module was what controlled both the refresh rate and the strobbing.

Anyway why on a 120 hz monitor 60 hz looks so horrible?
I'm thinking to take a Benq Xl2720Z for use it at 60 with lightboost;) any suggestion?

CoMa wrote:Anyway why on a 120 hz monitor 60 hz looks so horrible?

Horrible in what way?
Stutters? Tearing? Etc.

60Hz on a 120Hz TN monitor just looks virtually exactly like 60Hz on a 60Hz TN monitor.
(When not used with any features such as motion blur reduction)

You need to use the 120Hz refresh rate to get the benefits of a 120Hz monitor.
The optional 60Hz strobing (on BENQ Z series V2 firmware) can greatly improve motion clarity of 60Hz but at the cost of potentially annoying flicker.

CoMa wrote:Anyway why on a 120 hz monitor 60 hz looks so horrible?
I'm thinking to take a Benq Xl2720Z for use it at 60 with lightboost;) any suggestion?

A 120Hz monitor looks the same as a 60Hz monitor if driven at 60fps.
But, if the 120Hz monitor is in strobe back-light mode, then it looks pretty bad at 60fps. This is because the same image is presented for 2 consecutive strobes. And this result in double image artifact when you're tracking a moving object.
That's one of the reasons why we recommend frame rate = refresh rate = strobe rate for the best experience.

Now for a 120Hz monitor driven at 60fps@60Hz you won't get that issue. But 60hz strobed is very flickery and strain the eyes.