Asus XG27AQDMG Discussion

[RealNC]

I think RTSS has that directly built-in now. It just needs to be added in the overlay editor. Will check later to make sure.

Even better, if so.

Just checked, and it has it as a data source in the internal HAL, at the very bottom:

rtss_vrr_hz.png (29.38 KiB) Viewed 13268 times

I added it to the overlay and it correctly tracks current refresh rate, including LFC (35FPS for example shows 70Hz.)

[jorimt]

Good to know.

[RealNC]

I noticed that DSC can be turned off in the OSD. This limits 10-bit to a max of 180Hz. For 240Hz only 8-bit is allowed. So apparently the only reason to keep DSC enabled with this monitor is for just one mode: 10-bit 240Hz 1440p.

8-bit dithered vs native 10-bit isn't very noticeable in 99% of cases, at least in my experience. DSC is better off, where possible (less glitches, DLDSR and custom resolution support, etc).

I just tested DSR/DLDSR with DSC enabled (1440p 10-bit 240Hz) and it seems to work fine in this case. I'm not sure what exactly the requirement is for it work with DSC, but it's fine with this monitor.

I still keep it disabled anyway, since I don't think there's a point in enabling 10-bit with SDR content.

[jorimt]

I just tested DSR/DLDSR with DSC enabled (1440p 10-bit 240Hz) and it seems to work fine in this case. I'm not sure what exactly the requirement is for it work with DSC, but it's fine with this monitor.

I'm sure the restrictions vary by monitor implementation. My PG27AQN doesn't allow NVCP custom resolution creation or DSR/DLDSR with 360Hz DSC active.

[RealNC]

Rtings review was just published:

https://www.rtings.com/monitor/reviews/ ... -xg27aqdmg

It mostly matches my impressions. Except there's no way this is an 8.5 in build quality, and the statement that "it has amazing height adjustment" is simply not true

[RealNC]

VRR flicker is there. Not only on loading screens. I spotted flicker in Halo 2 with in-game 60FPS cap. Using NVCP or RTSS cap instead fixes it.

Yup.

I was able to completely fix VRR flicker. And I mean completely, including during 0FPS stalls in loading screens. The original thread for that is on Guru3D:

https://forums.guru3d.com/threads/oled- ... ad.442564/

For the Asus XG27AQDMG, just lowering pixel clock by changing the 240Hz mode to 230Hz with "timing" set to "manual" (so the actual timings stay the same and only the pixel clock changes) completely gets rid of the VRR flicker! Editing the freesync range in CRU is not needed, at least on Nvidia (the driver ignores it.) On AMD, you might have to change the range and set the max to match the new Hz (or set it to Hz - 1.)

And yes, before you ask, I verified g-sync is still working perfectly, including LFC.

Have you tried this on your LG? Try 110Hz. It's surprising how well this works here. I'm not sure why. Just lowering the refresh rate normally by using a different mode (like 180Hz) does not fix the flicker. The only thing that fixes it is keeping the timings as-is while lowering pixel clock / Hz.

Maybe Chief has some insight? And also, he might be able to affect future displays (and firmware updates) to do by default what this CRU tweak does.

[jorimt]

I was able to completely fix VRR flicker. And I mean completely, including during 0FPS stalls in loading screens.

Interesting...

The last insider-level explanation that could be considered anything close to "official" (can't find the source again; HDTV Test posted the link from one of their videos years back, I think) was that the gamma response is fixed to the max refresh rate on OLED panels, so any deviation from that curve due to VRR operation results in micro differences in gamma response, hence the gamma of 110 FPS VRR @120Hz may be slightly raised/lowered vs. the gamma of 119 FPS VRR @120hz, and so forth.

As such, since OLED has a black floor of virtually 0, if the FPS wildly or abruptly fluctuates enough in VRR, gamma response differences between the individual "Hz" (aka how many times the scanout cycle repeats per second based on the average framerate at any given point) will result in the appearance of flicker, which is why it's mostly "fixable" by ensure the average framerate/frametime remains relatively constant.

Why your tweak apparently fixes it in your case, I'm not sure; perhaps some of it is due to near-black overshoot repeatedly being triggered by the panel exceeding its supported timings during the more extreme frametime variances with VRR engaged?

And I'm curious, is it still fixed for you with the below test?
https://github.com/MattTS01/VRR_Flicker_Test_OpenGL

Regardless, I'll try the tweak on my C4 when I get the chance and report back (no ETA).

[RealNC]

And I'm curious, is it still fixed for you with the below test?
https://github.com/MattTS01/VRR_Flicker_Test_OpenGL

Yes. There's very noticeable flicker in that test without the tweak. It's gone after applying the tweak.

However, I just noticed that fixed refresh rate operation has issues with the tweak. The test ufo tests will stutter, and the frame skipping test can't sync at all. So there might be frame skipping when VRR is not currently engaged. I have not noticed frame skipping by eye (on the desktop on in games with g-sync active.)

But it gets weirder. If I simply change to 180Hz (note that I didn't edit the 180Hz mode in CRU, this is the monitor's vanilla 180Hz mode,) and run the test (or a game) at that refresh rate, the flicker is still gone (I know it's the correct refresh rate because in games RTSS reports 180FPS with vsync. and 171FPS with NULL.) Also, all the tests on test ufo run flawlessly in 180Hz.

If I run CRU's reset-all.exe and restart, the VRR flicker comes back in 180Hz mode as well.

I have no explanation how this is even possible. For some reason, the edited 240Hz mode has an effect on other modes as well when it comes to g-sync. I'm clueless.

[jorimt]

I have no explanation how this is even possible. For some reason, the edited 240Hz mode has an effect on other modes as well when it comes to g-sync. I'm clueless.

Weird.

[RealNC]

Weird.

OK, this was an error on my part. The 180Hz mode does not have VRR flicker. Ever. The EDID tweak doesn't matter at all. 180Hz is flicker-free out of the box.

I experimented some more in CRU, and I can get rid of the VRR flicker even at 240Hz by simply keeping the refresh rate (239.973Hz) and selecting "Exact" in "timings." This also lowers the pixel clock. The inability of test ufo to sync in the frame skip test though remains.