LG 27GK750F-B - 240Hz, 27" 1ms Blur reduction, Freesync

[A Solid lad]

You are using generic windows default driver? And how games run with it?

I measured an average dpc latency of 3-4 us with the default windows driver.
However I didn't even try running games with that...you can't even set a refresh rate higher than 60hz, nor enable aero... just used it for testing purposes.
(After uninstalling nvidia drivers with DDU, I've fired up dpclat checker out of curiosity...and BAM. I even posted a video about it, and screenshots of latencymon test results...page 22, first post)

Now I'm trying to find a full-fledged nvidia driver, which does not increase dpcl latency considerably...

[k2viper]

Every driver vs no-driver scenario will be in a favor of nodriver it terms of raw DPCs.
But we are a real world population
GPU drivers are needed. Tonight I tested 387.92 as was recommended, but in terms of DPC's 385.69 currently contnuing to be the best.

[giubox360]

You are using generic windows default driver? And how games run with it?

I measured an average dpc latency of 3-4 us with the default windows driver.
However I didn't even try running games with that...you can't even set a refresh rate higher than 60hz, nor enable aero... just used it for testing purposes.
(After uninstalling nvidia drivers with DDU, I've fired up dpclat checker out of curiosity...and BAM. I even posted a video about it, and screenshots of latencymon test results...page 22, first post)

Now I'm trying to find a full-fledged nvidia driver, which does not increase dpcl latency considerably...

I just tested a thing that makes all the things a lot clearer. (using nvidia driver 391,01)
I tried the LG 240 hz @ 144hz with MBR activated and I'm always on a single digit 5/10 ms......like my samsung 144hz with MBR activated.
So 240 hz seems to add more latency to the graphic cards maybe is nothing to worry about...or maybe yes. But one thing is clear:
144hz has both lower DCP latency on my 2 monitors....at this point, who needs a 240 hz for competitive fps? (sarcastic)
I wish to try also the freesync version of the dell 240 hz....at this point I'm 99% sure also that will show less DPC latency on 144hz than on 240 hz.

p.s.

after some test on "Human reactions benchmark" to measure input lag, as a feeling 240 hz seems to have about 5/6 ms less than 144 hz.
(on my average 5 on 5 clicks) For this reason I think DPC latency programs seem showing wrong values when set on 240 hz.

240 hz Monitors should never be used @144hz because this will add a bit of input lag.

[Chief Blur Buster]

240 hz Monitors should never be used @144hz because this will add a bit of input lag.

Only for 240Hz monitors that are stuck in fast-scanout (1/240sec refresh cycle scanouts). That, by definition, requires a little pre-buffering for lower refresh rates. Which is why some 240Hz monitors aren't the world's lowest lag 60Hz displays.

You want synchronous scanout velocity (cable scanout = panel scanout) for essentially lagless operation -- meaning, pixels are being displayed at the same speed as they are arriving on the video cable. 240Hz monitors do it synchronously at 240Hz.

But I've also seen 144Hz monitors that could vary it scanout velocity based on refresh rate and veritcal totals -- but many 240Hz panels are currently not doing that (yet) at the moment.

Give it more time, and 240Hz panels will probably eventually have variable scan velocity to allow low-lag operation at 60Hz and 144Hz.

TL;DR: Drive 240Hz monitors at 240Hz or full range VRR (XHz-to-240Hz) for the lowest lag you can get in a gaming monitor today.

[GammaLyrae]

240 hz Monitors should never be used @144hz because this will add a bit of input lag.

Only for 240Hz monitors that are stuck in fast-scanout (1/240sec refresh cycle scanouts). That, by definition, requires a little pre-buffering for lower refresh rates. Which is why some 240Hz monitors aren't the world's lowest lag 60Hz displays.

You want synchronous scanout velocity (cable scanout = panel scanout) for essentially lagless operation -- meaning, pixels are being displayed at the same speed as they are arriving on the video cable. 240Hz monitors do it synchronously at 240Hz.

But I've also seen 144Hz monitors that could vary it scanout velocity based on refresh rate and veritcal totals -- but many 240Hz panels are currently not doing that (yet) at the moment.

Give it more time, and 240Hz panels will probably eventually have variable scan velocity to allow low-lag operation at 60Hz and 144Hz.

TL;DR: Drive 240Hz monitors at 240Hz or full range VRR (XHz-to-240Hz) for the lowest lag you can get in a gaming monitor today.

I found it interesting how the lower refresh rate lag expresses itself.

https://us.hardware.info/reviews/7895/8 ... ninput-lag

At 60hz, the top of the frame is delayed slightly. But as you approach the bottom of the screen, the frame delivery time is, overall, about the same as a 60hz panel. Of course, you don't play a game by looking at the bottom of the screen, so there's probably going to be a little bit of delay that you can feel.

https://www.youtube.com/watch?v=mHIoJWtGR_w

A 60hz BenQ gets different measurements - 3.1 top, 10.2 middle, 17.7 on the bottom. For a console eSports gamer, the added delay at the top of the frame with your typical 240hz panel is probably not acceptable. If you assume two opponents with equal reaction times, one on a fast 60hz display (or a higher refresh display with synchronous scanout) they could plausibly see something 3-7ms before their opponent. In a fighting game where the entire balance of the game is structured around increments as small as a single frame (or 16.67ms), you'd probably never see a 240hz panel like this used seriously for consoles either.

Although I suppose if the game is running on your PC with a Windows refresh rate of 240hz and no Freesync is in play, then the monitor would still be doing the fastest scanout possible, offering 1:1 performance with a fast, 60hz native display...right? Maybe even faster. Assuming what you're saying about the scanout being synchronous in a locked 240hz scenario is true. (IE: The 60fps frames are duplicated 4 times @ 240hz, rather than the monitor only updating 60 times per second)

[Chief Blur Buster]

Although I suppose if the game is running on your PC with a Windows refresh rate of 240hz and no Freesync is in play, then the monitor would still be doing the fastest scanout possible, offering 1:1 performance with a fast, 60hz native display...right?

Correct.

Maybe even faster.

Theoretically possible.
The LG monitor supports frame delivery in 1/280 sec using the VT1302 trick (max dotclock possible)
I don't know if the panel scanout is 1/240sec or 1/280sec.

Assuming what you're saying about the scanout being synchronous in a locked 240hz scenario is true. (IE: The 60fps frames are duplicated 4 times @ 240hz, rather than the monitor only updating 60 times per second)

Hold it, I never said that.

<Techncial: How It Works>

What I meant to say was 240Hz monitors does a partial buffering of the pixels arriving on the cable and then scans it out at high velocity.

Fundamentally - pixels are transmitted over the cable sequentially, one scanline at a time (rows of pixels), top-to-bottom. This is called rasterization, the art of "scanning out". Serializing an image over a wire has been done roughly this way (both analog and digital) for almost a century, and the standard scanout direction is top-to-bottom.

Clarifying The Variables To Avoid Misunderstanding
Display = Most 240Hz panels (at the moment)
Mode = Standard 60 Hz 1080p (like a console)
VRR = None

Cable Point of View
Frames are arriving in a slow-scan, taking 1/60sec to deliver a frame top-to-bottom

Panel Point of View
Some panels do synchronous scanout, but something weird happens with current 240Hz panels: They can only refresh fast!
It must display a refresh cycle top-to-bottom in 1/240sec. For some weird reason, it can't slow-scan. It's refreshing only once every 1/240sec. It simply pauses 3/240sec between refresh cycles (no extra refresh cycles) -- the static image just idles in a sample-and-hold manner, merrily keeping displaying the image that was refreshed before. No repeat refreshing is occuring. It's just longer pauses between fast-scanouts.

How Do You Display a Refresh Cycle Quickly From a Slow Frame Delivery Over Cable?
Yup. You have to buffer the slow cable scanout before you can do the fast panel scanout. It does a 3/4 buffering (basically buffers for 3/4ths of 1/60sec) -- roughly 12-13ms of buffering then it begins the fast scanout, while still buffering the final scanlines. The fast scanout (panel) meets the slow scanout (cable) by the time the final pixel is delivered over the cable. This is an internal "scan conversion" to make a slow scanout signal compatible with a fast-scanout-only panel.

Result: More lag for top edge than a 60Hz monitor.

Leo Bodnar Lag Tester would reveal:
Top: 3/4ths of a refresh cycle more lag than bottom edge.
Center: 1/2 of 3/4ths of a refresh cycle more lag than bottom edge
Bottom: Approximately full cable-original refresh cycle lag + partial GtG lag + cable lag (usually ~1/60sec + 1ms + 1ms)

Is this true for all panels?
No. Some panels can vary scanout speed on the fly. Many 144Hz 1080p panels can scanout synchronously with the cable scanout of a fixed-Hz signal, and their scan velocity will increase (without increased refresh rate) using Large Vertical Total tricks, which is why strobe crosstalk gradually reduces when doing Large Vertical Total tweaks on the 1080p 144Hz BenQ monitors.

Another different way to understand the fast-scan-and-long-pauses-between-scans is Large Vertical Totals which is a common trick to reduce strobe crosstalk

</Techncial>

[GammaLyrae]

What about VRR modes (specific to this monitor, freesync)

In a fixed 120hz scenario, based on your post, I can understand that the monitor would hold for 1/240 refresh cycles, then spit out the entire frame at 1/240 speed on the next refresh cycle, resulting in slightly higher delay than a 120hz native panel. But what if you are only getting this framerate while Freesync is enabled? Like, let's say you're in Freesync mode and you lock the game to 120fps, and you can consistently get this framerate. Does the frame render as quickly as possible (on the first 1/240hz refresh cycle), or would it behave as if you were on the fixed 120hz mode of the monitor, and hold the frame for the first refresh 1/240hz refresh cycle, and then scan it out on the second?

Basically, I am trying to determine if this monitor still meets my needs or not. If I can play 60fps games (fighters, console ports, many 2D games even if they're PC-Native) in the 240hz mode and not experience any additional input delay due to how the scanout functions, and Freesync adds no additional delays compared to whatever may already exist on the fastest 144hz synchronous scanout panel, then it will meet my needs. It sounds like the locked fast scanout may only cause input delay problems when connected to consoles locked at 60hz, which is never something I'll never do with this monitor. If not, then, well, looks like I'll be sending it back and picking up something else instead.

[Chief Blur Buster]

In a fixed 120hz scenario, based on your post, I can understand that the monitor would hold for 1/240 refresh cycles, then spit out the entire frame at 1/240 speed on the next refresh cycle, resulting in slightly higher delay than a 120hz native panel. But what if you are only getting this framerate while Freesync is enabled? Like, let's say you're in Freesync mode and you lock the game to 120fps, and you can consistently get this framerate.

Framerate caps do not affect scanout velocity. You'd simply set your refresh rate to 240Hz (preferably 240Hz VRR rather than 240Hz non-VRR), then cap to 120fps. That way, the top part of refresh cycles begin displaying immediately without being pre-buffered (scanrate conversion). So you get low-lag 120fps or 60fps during 240Hz VRR. No problem.

Does the frame scan out as quickly as possible (on the first 1/240hz refresh cycle), or would it behave as if you were on the fixed 120hz mode of the monitor, and hold the frame for the first refresh 1/240hz refresh cycle, and then scan it out on the second?

Fixed the post for you. It's scan out (the act of outputting a refresh cycle out a video output). It's not the same thing as render (GPU). Render stage always happens before the scan out. Also, during VSYNC OFF, you can have multiple renders per scanout (with tearlines separating frame slices).

Short answer: For full range VRR, yes, as quickly as possible.
It always scans out at the full velocity. Let's say you've configured a VRR range -- 30Hz-240Hz range -- 48Hz-240Hz range -- then each refresh cycle always scans out at full cable velocity -- 1/240sec -- even at 30fps@240Hz. Each refresh cycle begins displaying immediately with no lag, no matter how low frame rate is. And the refresh cycle finishes displaying in 1/240sec later -- no matter how low the frame rate. You're always getting low scanout lag. No buffering for scanout-velocity conversion between cable scanout velocity and panel scanout velocity.

Long answer: It gets slightly more complicated for a fast-scanout-only panel that is intentionally running a lower-Hz VRR.
For example, if you're switching it to 144Hz or 60Hz instead of 240Hz and enabling VRR on that said 144Hz or 60Hz. For example, a 240Hz VRR monitor can be run with a 144Hz VRR mode or 60Hz VRR mode. For monitors that support that, they may have a have partial-buffer-and-fast-scanout behavior for each refresh cycle, where cable scanout is 1/144sec, panel scanout is 1/240sec, for any VRR refresh rate of 30-144Hz (for a 30-144Hz VRR range). To make a cable scanout 1/144sec work on a fast-scanout-only panel, you still need a little prebuffering even for VRR. But most users almost never enable a VRR at lower than max Hz. It's usually never useful to do so. Cable scanout velocity typically matches the max-Hz you've set of your VRR range, so use the biggest VRR range and highest max-Hz (e.g. 30Hz-240Hz) for the most unbuffered, least-latency scanout behavior.

Basically, I am trying to determine if this monitor still meets my needs or not. If I can play 60fps games (fighters, console ports, many 2D games even if they're PC-Native) in the 240hz mode and not experience any additional input delay due to how the scanout functions, and Freesync adds no additional delays compared to whatever may already exist on the fastest 144hz synchronous scanout panel, then it will meet my needs.

You should be getting insanely low lag for 60fps caps at 240Hz VRR. There ideally should be no pre-buffering occuring at any framerate/"refreshrate"/caps during full-range 240Hz VRR. You should be able to feel a massive difference -- 60fps@240Hz VRR should feel much better than 60fps@60Hz fixed-Hz (whether on synchronous scanout or prebuffered scanout).

If you are feeling lag, then something is configured incorrectly, or the framerate capping software is adding input lag, or something unexpected is happening. All 240Hz panels I've tried can keep scanout in sync between cable and panel when running at its max-Hz (either fixed Hz for non-VRR -- or the high Hz in the VRR range, if using VRR). The rule of thumb is always try to use an in-game frame rate cap (console ports that self-cap to 60fps is fine) -- that is always lower lag than using an external capping utility such as RTSS.

Since you cannot turn off the in-game-cap of some 60fps console ports, you're stuck with that in-game capping (lag or not), so for that situation, the use of VRR modes (144Hz or 240Hz) gives you practically the lowest possible input lag for 60fps-capped videogames. 60fps@60Hz monitors will always have more lag with console ports, than 60fps-capped-at-240Hz-VRR.

So it doesn't affect console ports where you play 60fps @ 240Hz. There's no prebuffering lag.
It's only a bigger problem for console eSports where you connect an external fixed-60Hz signal (slow cable scanout that forces fast-scanout-only panels to prebuffer).

[GammaLyrae]

Thank you for the replies. It sounds like the monitor will meet my needs, since I only ever plan to run it either at a fixed 240hz or a VRR mode with an upper limit of 240hz.

The only potential loss I may suffer is if I wanted to drop to 120hz to ease the burden on my gpu while using strobing modes, but I can live with that, I think.

[Chief Blur Buster]

The only potential loss I may suffer is if I wanted to drop to 120hz to ease the burden on my gpu while using strobing
modes, but I can live with that, I think.

To fix that, it may be possible to simply use a Large Vertical Total. LG monitors are compatible with them.
(UNTESTED: I'm not sure if strobing will be enable-able during this mode)

That speeds up your cable scanout velocity (to match panel scanout velocity), and slightly reduces strobe lag too by allowing the panel to finish refreshing quicker, and can allow the monitor to flash the strobe backlight earlier (depending on how it's designed).

See the Advanced Strobe Crosstalk FAQ, Appendix A. Take either the existing VT1302 or VT1336 timings in ToastyX CRU and then put radio button on "Pixel Clock". Then increase Vertical Total even further until Refresh Rate falls to 120Hz. Now you've gotten a 120Hz refresh rate with the same scanout velocity as the original mode. AFAIK, the LG monitor supports a 120Hz fixed-Hz mode with roughly 1/280sec frame delivery over cable. (The VBI is actually taller than the active vertical resolution!)

I wish this tweaking stuff was easier, but at least it's neat that the LG monitor has an unusual ability to speed up refresh cycles above 1/240sec. The monitor will frameskip at above 240Hz, but it seems happy with ~1/280sec frame delivery when you don't refresh more than 240 times a second. A very interesting unusual (beneficial) quirk specific to the LG 240Hz monitor made possible via ToastyX CRU.

TIP: Did you know? HDMI just standardized this "cable-scanouts-faster-than-panel-scanout" technique for HDMI 2.1 as something called "Quick Frame Transport (QFT)"? It's a variant of large VBIs where you have very fast cable scanout with long idle VBI intervals between cable scanouts. This will probably help future consoles, connected to a compatible display -- and can help avoid needing to prebuffer when doing slow-cable-scanout on fast-panel-scanout.