Blur Busters Forums

So I test a lot of monitors as it is my fav piece of hardware. I pursue the lowest possible input lag experience aswell. Im very sensitive to it and in blind tests I could even spot 5ms differences.

There is something I recently noticed while testing gsync panels, and how they differ to non gsync, even with gsync disabled.

First of all I noticed on every review about input lag with leo bodnar on gsync monitors, that the 3 lines used (top, middle and bottom) are very close to each other! For example Asus PG258q has 14ms, 14,2ms, 14,4ms. While on a non gsync monitor it is usually like 3ms, 10ms,17ms.

Get my idea? So what does that mean? Gsync monitors have constant input lag value across the entire panel? 14ms at the lower line is the lowest value I ever seen, but 14 on top and middle line is pretty bad.

However now starts the intetesting part. Testing asus pg258q at 60hz I notice something weird. It feels more floaty when I send a controller input, but seems consistent, I dont know how to explain the feel. A non gsync panel feels more responsive but the image seems to be displayed in a different way.

On gsync monitors like asus pg258q on both console or pc 240hz I notice the image a lot smoother!! Consistent and no transitions/blur. Idk how to explain, sorry for my lack of technical terms. I just don't understand this particular aspect of gsync panels.

Any idea?

I've moved your question to the Input Lag forum.

Notty_PT wrote:First of all I noticed on every review about input lag with leo bodnar on gsync monitors, that the 3 lines used (top, middle and bottom) are very close to each other! For example Asus PG258q has 14ms, 14,2ms, 14,4ms. While on a non gsync monitor it is usually like 3ms, 10ms,17ms.

It all depends on variety of factors:
(1) How quickly the frames are delivered from PC to monitor
(2) How quickly the frames are scanned out from monitor's framebuffer to screen.

Usually, this is what happens:

Strobed VSYNC ON: top/center/bottom equalizes
Strobed VSYNC OFF: top/center/bottom different

Unstrobed VSYNC OFF: top/center/bottom equalizes
Unstrobed VSYNC ON: top/center/bottom different

This is because of asymmetry between cable scanout and panel scanout/visibility. The cable scanout velocity (PC->monitor electronics) can different from panel scanout velocity (monitor electronics->panel visibility).

Watch the high speed video of LightBoost to understand what I mean:



Strobing mean the whole frame becomes visible all at once. The panel is scanned out top-to-bottom in non-LightBoost mode, but the panel becomes visible instantly all at once in LightBoost mode. That mean top/center/bottom lag differentials are different.

Also some LCDs scans out faster than cable delivery. The refresh cycle is buffered and then scanned-out faster.

Most of the time, on CRTs and current eSports LCD monitors (BenQ/Zowie) panel scanout is synchronous to cable scanout.

Also, future HDMI 2.1 Quick Frame Delivery (QFD) (a special form of CRU Large Vertical Totals: Running at dotclocks higher than default to deliver the pixels faster) also speeds up PC-to-monitor delivery, so will change the top/center/bottom lag algebra too.

To understand how lag of frameslices work, see these diagrams.







Mind you, these diagrams are not perfect. It's extremely hard to explain lag mechanics of VSYNC ON versus VSYNC OFF, especially concurrently with modified gradient effects from asymmetries between cable scanout and panel/visual scanout.

Thank you very much, your knowledge is fantastic!

However I still didn´t understand something. I understoog how the screen behaves when strobed, but what I notice is that even without strobing on a Gsync monitor, the image seems to appear all at once without blur. Happens on the Asus PG258Q I have around here, and I don´t get why is that. It is flicker free too and I have both ulmb and gsync OFF!

Also on the input lag measurements gsync panels always have equal/similar 3 lines, while non gsync have different, like you said. And this is what I don´t get. What does the gsync module do to the monitors?

If you compare Asus PG258Q to other non gsync 240hz monitor, you will notice that asus is smoother on the transitions.

Notty_PT wrote:However I still didn´t understand something. I understoog how the screen behaves when strobed, but what I notice is that even without strobing on a Gsync monitor, the image seems to appear all at once without blur. Happens on the Asus PG258Q I have around here, and I don´t get why is that. It is flicker free too and I have both ulmb and gsync OFF!

Which lag testing method did you use to determine TOP/CENTER/BOTTOM becoming equal in sample-and-hold mode?

This would be normal for unstrobed VSYNC OFF (scanout-following) but abnormal for unstrobed VSYNC ON.

It's normally for VSYNC OFF to make TOP/CENTER/BOTTOM equal. Real-world lag numbers tends to randomize/jitter to roughly MAX(frametime, refreshcycle time) according to the number patterns seen in GSYNC 101. But will average equally for TOP/CENTER/BOTTOM for VSYNC OFF unstrobed. For VSYNC OFF you need to run many passes and average them because of the jitter. VSYNC ON input lag doesn't jitter like VSYNC OFF input lag does.

For VSYNC ON and for GSYNC mode, a 240Hz G-SYNC monitor tended to show slightly more lag for BOTTOM than TOP.

Can you tell me how the lag testing run was donke?

Most of the time, this is how lag gradients changes for four scenarios :

TOP/CENTER/BOTTOM equalizes
1. VSYNC ON strobed
2. VSYNC OFF nonstrobed

TOP/CENTER/BOTTOM different
3. VSYNC OFF strobed
4. VSYNB ON nonstrobed

See how the lag gradient behavior changes for VSYNC OFF, and how strobing can invert this behavior?
This is because strobed is global, and VSYNC ON is global.
While unstrobed has scanout, and VSYNC OFF is scanout-following.

VSYNC ON and GSYNC would be the same, and GSYNC is unstrobed, so TOP/CENTER/BOTTOM should be different in GSYNC mode. Which is the correct assumption. That said, TOP/CENTER/BOTTOM equalizes in unstrobed mode is if you're using a VSYNC OFF lag testing method.

THe input lag measure method was Leo Bodnar. You can check it here:



This is for Asus PG258Q. Meanwhile the usual numbers are like "3ms - 10ms - 17ms" for example. This is what I find odd. Also this Asus PG25 transitions behaviours seems completly different from the other monitors. Idk how to explain it technically. Image seems smoother on transitions, like it has no absolute blur or like it is flickering or strobing all the time (even with ULMB off and even with a console connected to it). And I think this image effect has relation with the fact the screen seems to have similar lag across all lines top center bottom. is it? That´s why I´m confused because idk what this monitor has that makes it so different. If you check other gsync monitors with leo bodnar tests, they will be pretty similar with really close values from top center bottom. This asus also shows the lowest bottom value ever, 14ms. Usually it is 17ms or more on every monitor, while the top and center values are too high.

Notty_PT wrote:THe input lag measure method was Leo Bodnar. You can check it here:



This is for Asus PG258Q. Meanwhile the usual numbers are like "3ms - 10ms - 17ms" for example. This is what I find odd. Also this Asus PG25 transitions behaviours seems completly different from the other monitors. Idk how to explain it technically. Image seems smoother on transitions, like it has no absolute blur or like it is flickering or strobing all the time (even with ULMB off and even with a console connected to it). And I think this image effect has relation with the fact the screen seems to have similar lag across all lines top center bottom. is it? That´s why I´m confused because idk what this monitor has that makes it so different. If you check other gsync monitors with leo bodnar tests, they will be pretty similar with really close values from top center bottom. This asus also shows the lowest bottom value ever, 14ms. Usually it is 17ms or more on every monitor, while the top and center values are too high.

Oh, that's really interesting. Perhaps it's a special undocumented strobed behaviour with its 60 Hz mode.

You have the same monitor right?

You're saying it is flickering even with the ULMB menu option off? That could be proof of a ULMB bug, in that it's strobing at 60Hz at all times. When you wave a hand or finger in front of a bright screen, it looks stroboscopic -- like it strobes at 60Hz?

If looks like strobed duck, feels like a strobed duck, it's a strobed duck.

Then the Leo Bodnar is just behaving normally: It's measuring a strobed 60Hz mode -- and strobed modes equalizes TOP/CENTER/BOTTOM for Leo Bodnar. That'd then be normal behaviour.

Can you try TestUFO Panning Map Test at 60Hz on a computer through the same input (HDMI) that you use for consoles, and then let me know if you can read the street name labels at 60Hz (using standard HDMI 1080p 60Hz timings -- you need to mimic console timings in CRU). If you can, that's definitely a strobed low-persistence mode -- it's almost impossible to read the street name labels on a sample-and-hold display at less than ~480Hz.

No matter what the OSD is saying, it's a strobed duck IF all 1/2/3 is true:
1. You see no motion blur at 60Hz that you normally see on other 60Hz 1ms TN monitors
2. You can read the TestUFO street name labels at 960pps;
3. You see stroboscopic effects when you wave your hand fast in front of a bright screen.
...even if menus claim "ULMB" is turned "OFF".

Several ASUS monitor have an ELMB mode. This is ASUS's version of NVIDIA's ULMB. This might also be the ASUS ELMB mode (Extreme Low Motion Blur). It might be available for 60Hz, so is it possible that ELMB is being used for console 60Hz? (ELMB is very similar to ULMB).

Chief Blur Buster wrote: Mind you, these diagrams are not perfect. It's extremely hard to explain lag mechanics of VSYNC ON versus VSYNC OFF, especially concurrently with modified gradient effects from asymmetries between cable scanout and panel/visual scanout.

How does the scan diagram look like if a display does not support real time scanout with V-SYNC OFF?

KKNDT wrote:How does the scan diagram look like if a display does not support real time scanout with V-SYNC OFF?

No change for cable scanout (that's 100% fixed by numbers you see in CRU).
Change only for panel scanout.

First, there's a distinction between cable scanout and panel scanout.

The scan diagram does not change with the cable scanout.
But there are infinite number of ways that panel scanout may happen, so not possible to create scan diagrams for all but the most common ones of them.

e.g.
-- Partial-buffer-from-cable-and-accelerated-scanout-onto-panel (e.g. LightBoost and ULMB). Scanout speeds can be any different velocity.
-- Subfield scanouts (e.g. Plasma) or temporal dithered pulses (e.g. DLP).
-- Scan converesion -- Sideways scan, multiscan, segmented scans (e.g. jumbotron panels).
-- Global refresh (hidden refresh from cable, and then instantly display whole frame -- e.g. LightBoost, ULMB)
-- Refresh rate conversion (intentional frame dropping)
-- Etc.

Scanout velocity asymmetries would likely be the most common divergence, in the case of LCD monitors. It would simply apply a vertical lag graident distortion factor based on the velocity differential. So you get a situation of flipped lag gradients for global:
VSYNC OFF + nonstrobed = lag equalized
VSYNC ON + nonstrobed = lag gradient effect (bottom edge more lag)
VSYNC OFF + ULMB = lag gradient effect (bottom edge more lag)
VSYNC ON + ULMB = lag equalized

This is the simplest non-synchronous scenario to explain, because only VSYNC ON is global and only ULMB is global. While VSYNC OFF is scanout-following and nonstrobed is scanout-on-the-fly.

The other non-synchronous scenarios are all even more complicated to explain.

*Note: Yes, there's still frameslice gradients. For the above scenarios, for the purposes of simplicity, I'm, of course, ignoring the within-frameslice lag gradients during VSYNC OFF (top edge of frameslice versus bottom edge of frameslice -- since top edge of a frameslice has less lag), of course, so mathematically most simple for the infinite-framerate VSYNC OFF situation (resulting in each scanline has same lag for infinite-framerate VSYNC OFF nonstrobed), so this refers to the average input lag of a frameslice. So when I say "lag equalized" for VSYNC OFF", I mean all of the average lag of all frameslices, including the frameslice near top edge and the frameslice near bottom edge. (And VSYNC OFF frameslices get thinner at higher frame rates).

Needless to say, complex display scanout patterns are far beyond scope of the scan diagrams. The simplest situation is from the video timings perspective (CRU) and the cable scanout point of view., which all of the diagrams are based off. It would massively complicate scan diagrams to model all possible non-synchronous combinations since there is an infinite number of them.

The result of Leo bordnar test on PG258Q is really odd.
- Why does the values of the 3 different postion get so close? The values look like being created on strobed display, but no site has reported someting about it. Tftcentral did the pursuit camera test and we can see, there's lot of motion blur at 60HZ non-strobed mode.
- How could the lag number at the bottom edge be so small? A refresh cycle at 60HZ is at least 16ms.

Prad.de also tested XB252Q and PG27VQ, their lag numbers look more logical
- The bottem number - Top number is close to their scan out cycle at the native refresth rate. Maybe they buffed the frame from the cable and then scan out onto the panel at a much faster speed?
- The bottom number is bigger than 16ms.

PG27VQ


XB252Q

KKNDT wrote:The result of Leo bordnar test on PG258Q is really odd.
- Why does the values of the 3 different postion get so close? The values look like being created on strobed display, but no site has reported someting about it. Tftcentral did the pursuit camera test and we can see, there's lot of motion blur at 60HZ non-strobed mode.
- How could the lag number at the bottom edge be so small? A refresh cycle at 60HZ is at least 16ms.

Buffer-and-accelerated-scanout.
Essentially internal scan velocity conversion.
Basically 60Hz refresh cycles that are buffered 3/4ths, then scanned out in 1/240sec.

Yes, that means two different scan diagrams occuring at the same time! One for the GPU/cable (electronic scanout), and one for the panel (pixel visibility scanout). When it's not synchronous, it's essentially a form of internal "scan-conversion" going on within the panel.

KKNDT wrote:- The bottem number - Top number is close to their scan out cycle at the native refresth rate. Maybe they buffed the frame from the cable and then scan out onto the panel at a much faster speed?
- The bottom number is bigger than 16ms.

Yep!

Several 240Hz panels aren't very good at 1:1 symmetric scanout with 60Hz. The 240Hz panels apparently prefer to be scanned-out in 1/240sec. To make 60Hz work on some of those, the monitors have to partially buffer the slow-trickling video by roughly 3/4ths.

The top edge of the panel doesn't begin refreshing until about 3/4ths of the frame has arrived (and buffered). Once that happens, the panel begins scanning out the buffer (As the remainder (bottom-most 1/4th) of the monitor's framebuffer fills up). The start of scan lags, but the scan velocity then "catches up". The bottom edge of the screen is refreshed at the same time as the last pixels finally arrive on the cable. In other words, a single, continuous 1/240sec scanout-velocity pass.

This is okay with VSYNC ON games, but this is terrible for VSYNC OFF lag mechanics. The scanout asymmetry creates strange nonlinear lag gradient effects between the frame buffer flip in the computer & the pixel visibility to the human eye. Asymmetric scanout velocity is strongly discouraged for eSports.

eSports gamers prefer "lagless" scanout, i.e. synchronous scanout (cable scanout exactly matching panel scanout).

That's another reason why 240Hz monitors don't make very good console-gaming 60Hz eSports monitors. At least until manufacturers do lagless slow-scan of 60Hz (basically display each pixel on the fly as it comes off the wire -- with only minor scanline buffering for processing purposes).

One potential method (if using a PC) to somewhat compensate for this is to use a VT4500 (Vertical Total 4500 -- about 4x the existing 1080p Vertical Total) -- basically using a 240Hz Pixel Clock (Via ToastyX CRU or other utility) on a 60Hz refresh rate. Put the excess pixel clock in the Front Porch -- that makes it kind of behave like a "Quick Frame Delivery" (QFD) technique by delivering the visible part of the refresh cycle faster. That way, panel scanout stays in sync with cable scanout -- assuming the monitor's firmware correctly intelligently synchronizes to this. (Problem: This does not always happen).