ASUS OLED PG27AQDP and inconsistent lag in ELMB mode

[StrobeMaster]

The ASUS ROG Swift PG27AQDP (2K, WOLED, 480Hz) exhibits inconsistent input lag when in ELMB/BFI mode. At 120Hz, input lag is between approx. 9ms and 18ms; at 240Hz, it is about half of this (measured with a photodiode placed at the top of the screen and a trigger signal issued after having switched to the new image, so add ~4ms or ~2ms [EDIT: no, it's ~2ms or ~1ms] respectively for screen center values). There is no visible tearing, so the monitor does synchronize in some way, it is just not fully synchronizing to input VSYNC. This results in the lag drifting slowly from, in my case, its maximum (18ms) to its minimum (9ms), before rolling back over to its maximum. The duration of this drift cycle obviously depends on the mismatch between the refresh rate of input video signal and the monitor's internal refresh rate. In my setup, the drift cycle duration is 11 minutes for 120Hz and about 70 seconds for 240Hz. And because the monitor updates a bit faster than the PC, it skips an input frame once per latency drift cycle.
I contacted ASUS about this, but I have only little hope of getting it fixed. They might just brush it off as a too minor issue, and it probably is for most people. Or maybe it isn't? I guess the stutter is less of a problem, at least with most setups. But the differences in lag - meh?!

And there is the annoyance of ELMB being disabled when the PC is rebooted or power-cycled. This is probably because the PC is falling back to 60Hz during the boot process, which makes the monitor disable ELMB because ELMB is not supported at 60Hz.

BTW, this is firmware version MCM102.

[Falkentyne]

So nice to see you again, Strobemaster!
This is all beyond me, but I'm going to take a guess that you have an Nvidia video card? I had problems with RTSS scanline sync not giving proper frame synchronization before, and I don't know why nor do I know what made it happen.

[StrobeMaster]

This is all beyond me, but I'm going to take a guess that you have an Nvidia video card?

Nope, AMD. I have tested this with an RadeonPro WX5100 (under Win10) and a Radeon RX6400 (under Win11), with Displayport - same results. From the PC's perspective, ELMB off or on shouldn't make a difference and syncing per se is not a problem in ELMB-off mode, with minimal lag (<1ms for the top of the screen). Since this monitor is only G-Sync compatible, I assume that it will be the same with an NVIDIA card.

[mossfalt]

I was just about to order this monitor Thankfully I read this first. Is it fixed ?

[StrobeMaster]

I was just about to order this monitor Thankfully I read this first. Is it fixed ?

I don't think so. The changelog of the latest firmware (MCM103) does not suggest that there was any change regarding this issue. I am not planning to update to MCM103 - see also this post.

[Chief Blur Buster]

The ASUS ROG Swift PG27AQDP (2K, WOLED, 480Hz) exhibits inconsistent input lag when in ELMB/BFI mode. At 120Hz, input lag is between approx. 9ms and 18ms; at 240Hz, it is about half of this (measured with a photodiode placed at the top of the screen and a trigger signal issued after having switched to the new image, so add ~4ms or ~2ms [EDIT: no, it's ~2ms or ~1ms] respectively for screen center values). There is no visible tearing, so the monitor does synchronize in some way, it is just not fully synchronizing to input VSYNC. This results in the lag drifting slowly from, in my case, its maximum (18ms) to its minimum (9ms), before rolling back over to its maximum. The duration of this drift cycle obviously depends on the mismatch between the refresh rate of input video signal and the monitor's internal refresh rate. In my setup, the drift cycle duration is 11 minutes for 120Hz and about 70 seconds for 240Hz. And because the monitor updates a bit faster than the PC, it skips an input frame once per latency drift cycle.

Hey Marc, great to see you hanging around here again.

This sounds like a phase-slewing effect between panel scanrate and cable scanrate. Firmware-based PLL's can exist that stop working, and stop syncing between cable Hz and panel Hz.

Some possible workarounds:

1. You may want to try using VRR and see if syncing to software clock produces better lag consistency; For scientific tests use a CPU busyloop on QueryPerformanceCounter/RTDSC to present time target + REALTIME thread priority + Present() + Flush(), which manages to achieve <100us software-to-photons timing accuracy (>99% to >99.9% of the time if nothing running in background), better-than-buggy-fixed-Hz. While I did it for beam racing (video proof at viewtopic.php?t=4213 ...) it can be used for better timing of VRR refresh cycles, though you will have to experimentally verify it with photodiode oscillosope data. But definitely managed to achieve <100us refresh cycle timing error with software-timed refresh cycles.

2. Try adjusting the refresh rate and/or Vertical Totals in fractional increments using EDID overrides, to see if it triggers a proper lock. I've seen minor changes fix 240Hz bugs (see this thread) You might want to try creating a phase-shift-compensated EDID using ToastyX CRU and see if it locks better. Hopefully there's a lazy PLL that locks automatically when differentials are smaller or at different margins (better genlock between cable scanrate and panel scanrate) with minor adjustments in refresh rate clocks like 479.983Hz or 480.031Hz (as random examples) or such; you can customize fixed-Hz in 0.001-ish increments.

Interesting stuff: Thermal effects can cause the CPU and GPU clocks to drift relative to each other, at www.testufo.com/refreshrates#count=8 since it's a CPU clock (javascript) measuring a GPU clock (VSYNC) over a long time period using the now open-source algorithm at https://github.com/blurbusters/RefreshRateCalculator .... If VRR is off, the drift is smaller, and if the VRR is on, the drift is bigger. The drift slows/accelerates depending on whether the computer is cold or warm; it's impressive I can see this in mere javascript simply by long-duration averaging of refresh cycle counting (>5 minute runs) + error recovery from stutter (compensatory math from missed VSYNC's).

[Supermodel_Evelynn]

Blows my mind how companies don't jump to the idea of Blur Buster 2.0 certification, anytime ASUS and these other companies do their own strobing it's always some garbage implementation.

[StrobeMaster]

This sounds like a phase-slewing effect between panel scanrate and cable scanrate. Firmware-based PLL's can exist that stop working, and stop syncing between cable Hz and panel Hz.

Yes, something like that. I am not sure how far VRR could provide a workaround, but I consider VRR a no-go for my use case. Tweaking the EDID, on the other hand, would be an option but can never reduce the scanrate mismatch to zero reliably, because of the temperature effects. That's why it won't fix the main issue of getting variable input lags, it could just make them vary more slowly.

I wonder how much pro gamers would be affected by such input lag variability - one minute it is 4ms, the next minute it is 9ms. Would this be even worse than having to cope with consistently 9ms?

[Chief Blur Buster]

I wonder how much pro gamers would be affected by such input lag variability - one minute it is 4ms, the next minute it is 9ms. Would this be even worse than having to cope with consistently 9ms?

Latency variability definitely is a problem, but this specific latency variability is actually not common. It is seen on the introduction of bleeding edge new refresh rates. The current 240Hz OLEDs, AFAIK, fortunately, does not exhibit this.

[Chief Blur Buster]

Yes, something like that. I am not sure how far VRR could provide a workaround, but I consider VRR a no-go for my use case

I guess reducing latency variability to a [0..100us] isn't enough?
VRR generally bypasses this problem you describe.

Tweaking the EDID, on the other hand, would be an option but can never reduce the scanrate mismatch to zero reliably,

If there's no PLL lock occuring, you're correct.
But as a monitor-model-specific workaround (Again, this is rare-ish), a specific EDID can cause it to go always-reliable, similiar to those 240Hz EDID-fixes.

I wonder how much pro gamers would be affected by such input lag variability - one minute it is 4ms, the next minute it is 9ms. Would this be even worse than having to cope with consistently 9ms?

Yes, latency variability and frame skipping is a problem. But fortunately this is rare. You just got unlucky with a model-specific quirk, I believe. It is more common with bleeding-edge introduction of new refresh rates. I don't get this problem with the majority of my monitors.