Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators

Advanced display talk, display hackers, advanced game programmers, scientists, display researchers, display manufacturers, vision researchers & Advanced Display Articles on Blur Busters. The masters on Blur Busters.
elexor
Posts: 169
Joined: 07 Jan 2020, 04:53

Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators

Post by elexor » 12 Jun 2021, 07:59

yup fully reset cru settings and monitor is back to normal no blankouts and LFC functions. I think i might be because i deleted a bunch of pc resolutions and tv resolutions. need to experiment and figure out how i can lower LFC without fully disabling it.

elexor
Posts: 169
Joined: 07 Jan 2020, 04:53

Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators

Post by elexor » 12 Jun 2021, 08:41

Narrowed it down to 1 single checkbox in CRU disabling LFC really strange

Image

"Include if slot available" on the bottom under Max pixel clock

also you have to make sure you have at least 1 detailed resolutions slot left because "range limits" takes up a slot.

what happened is I filled up my detailed resolution slots unknowingly removing the range limits

tried all sorts of range limits, the panel with just go into LFC mode if any low framespikes occur and LFC usually gets stuck on until you go back to 240hz and back down again.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators

Post by Chief Blur Buster » 12 Jun 2021, 14:44

elexor wrote:
12 Jun 2021, 08:41
tried all sorts of range limits, the panel with just go into LFC mode if any low framespikes occur and LFC usually gets stuck on until you go back to 240hz and back down again.
LFC should only be sticky over a narrower range -- like about 20Hz-ish. But even with that, it may be sticky until above 60fps. That could be a problem for reliable emulator compatibility in an open-VRR-range situation.

Disabling hardware/driver-side LFC may end up easier, but then a method to force 30Hz refreshing is needed, even if it's a driver hook that transmits a dummy Present() of the previous frame (software-based LFC). Just brainstorming possible workarounds...
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

elexor
Posts: 169
Joined: 07 Jan 2020, 04:53

Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators

Post by elexor » 12 Jun 2021, 20:24

Chief Blur Buster wrote:
12 Jun 2021, 14:44
elexor wrote:
12 Jun 2021, 08:41
tried all sorts of range limits, the panel with just go into LFC mode if any low framespikes occur and LFC usually gets stuck on until you go back to 240hz and back down again.
LFC should only be sticky over a narrower range -- like about 20Hz-ish. But even with that, it may be sticky until above 60fps. That could be a problem for reliable emulator compatibility in an open-VRR-range situation.

Disabling hardware/driver-side LFC may end up easier, but then a method to force 30Hz refreshing is needed, even if it's a driver hook that transmits a dummy Present() of the previous frame (software-based LFC). Just brainstorming possible workarounds...
This monitor is crazy with it sometimes it will double frame 120hz to 240hz other times it will randomly allow 50hz. I can minimize and maximize a few times and get the correct hz. but it's behavior is very random.

but as soon as i touch a menu or loading screen it reverts back to LFC and will stick.

The narrow range LFC works correctly at 100hz since it can't double frame 60hz it only kicks in when needed and can't stick.

I'm thinking that's my only solution driver hook stuff is abit out of my league but i'll keep experimenting.

even tried using another 75hz monitors product id in cru to try and trick gsync. the monitor actually detects as a different monitor in NVCP but alas the behavior doesn't change. minimum rate without blanking out is 23hz but even at 20hz the monitor still has the werid LFC behavior. I thought about changing the max ratelimit to 100hz but gsync ignores it. I'm pretty sure it uses your max refreshrate as a guide for LFC not the max ratelimit in cru.

elexor
Posts: 169
Joined: 07 Jan 2020, 04:53

Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators

Post by elexor » 12 Jun 2021, 23:44

update

So I have been messing with cru. I have found freesync range to effect LFC behaviour but it doesn't actually effect gsync range
Image

been able to significantly reduce sticky LFC behaviour in most games. I still have found a few edge case games that will cause LFC to stick at 120hz for awhile but it will eventually return. gsync range is unaffected vrr still remains working up to 280hz.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators

Post by Chief Blur Buster » 13 Jun 2021, 00:33

Very interesting observation about the FreeSync range controlling LFC behaviour with this implementation of NVIDIA G-SYNC Compatible.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

elexor
Posts: 169
Joined: 07 Jan 2020, 04:53

Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators

Post by elexor » 05 Jul 2021, 22:44

Chief Blur Buster wrote:
13 Jun 2021, 00:33
Very interesting observation about the FreeSync range controlling LFC behaviour with this implementation of NVIDIA G-SYNC Compatible.
Think I might be wrong about that one. LFC is so random sometimes it's easy to get confused by what's actually affecting it.

Question about gsync

Does decreasing your max hz and increasing the size of the back porch allow you more crosstalk headroom past vertical sync?
So you have more room for error without picking up crosstalk from the beginning of the next frame.

Image

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators

Post by Chief Blur Buster » 06 Jul 2021, 04:32

elexor wrote:
05 Jul 2021, 22:44
Does decreasing your max hz and increasing the size of the back porch allow you more crosstalk headroom past vertical sync?
So you have more room for error without picking up crosstalk from the beginning of the next frame.
Beats me - the ASUS algorithm is proprietary. But I know VRR strobeon all VRR strobe monitors usually keys strobe relative the end of active refresh cycle, or beginning of VBI. It’s possible it may key on VSYNC, allowing you to use vertical front porch to delay the strobe. However, this mau be monitor dependant. You will have to test if the crosstalk position changes.

First, it’s the Front Porch that comes BEFORE vsync, not after. VRR dynamically resizes Back Porch (bigger) in realtime, leaving Front Porch and VSYNC unchanged.

Image

For a DIY hack, simply use (in granularity of ~0.1ms or less) an absolute-time phase adjustment for your backlight flash relative to your leading edge of VSYNC trigger and call it a day, as VRR only varies the Back Porch.

Same end result, making it (mostly*) irrelevant what you pad the large Vertical Total with (saving experimentation time),
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

elexor
Posts: 169
Joined: 07 Jan 2020, 04:53

Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators

Post by elexor » 06 Jul 2021, 09:19

Chief Blur Buster wrote:
06 Jul 2021, 04:32
Ah got my fp and bp mixed up!

I have very accurate strobe duration because im counting 1.67ns ticks of the 600mhz clock for timestamps.

ARM_DWT_CYCCNT overflows in 6 seconds that's plenty of time for me.

so just multiplying ticks by strobe duty.

It works pretty well it greatly decreases flicker for variable fps content. I was wondering do you use any filtering when vsync is noisy I have tried using an ewma filter. higher strength increases phase lag. Is that the correct way to deal with it?

elexor
Posts: 169
Joined: 07 Jan 2020, 04:53

Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators

Post by elexor » 09 Jul 2021, 05:15

another test. sometimes the simplest solution is the best. free floating strobe untethered from my input pulse. seems to always want to return to the crosstalk sweet spot own its own accord :D. I can play games like cyber punk with this uncapped and it rivals fixed strobe with low crosstalk and minimum flicker.

Code: Select all

#include <Ewma.h>

const int vsyncSignal = 6;
const int backlightSignal = 7;

float strobeDuty = 0.20;
Ewma adcFilter1(0.25);

unsigned int frameTime, oldframeTime, avgframeTime, strobeTime, slewPhase;
uint32_t phaseDiff, vsyncTimestamp, oldvsyncTimestamp, oldARM_DWT_CYCCNT;
bool vsyncLock, onLock, slewLock;

void setup() {
  pinMode(vsyncSignal, INPUT);
  pinMode(backlightSignal, OUTPUT);
}

void loop() {
  if (digitalReadFast(vsyncSignal) == LOW && vsyncLock == true) {vsyncLock = false;}
  if (digitalReadFast(vsyncSignal) == HIGH && vsyncLock == false) {
    vsyncTimestamp = ARM_DWT_CYCCNT;
    frameTime = vsyncTimestamp - oldvsyncTimestamp;
    avgframeTime = adcFilter1.filter(frameTime);
    oldvsyncTimestamp = vsyncTimestamp;
    vsyncLock = true;    
  }
  
  if (phaseDiff > (frameTime / 2) && slewLock == false) {slewPhase = 50000; slewLock = true;}
  if (phaseDiff < (frameTime / 2) && slewLock == true) {slewPhase = -50000; slewLock = false;}

  if ( (ARM_DWT_CYCCNT - oldARM_DWT_CYCCNT) > avgframeTime + slewPhase && onLock == false) {
    strobeTime = (ARM_DWT_CYCCNT - oldARM_DWT_CYCCNT) * strobeDuty;
    oldARM_DWT_CYCCNT = ARM_DWT_CYCCNT;
    digitalWriteFast(backlightSignal, HIGH);
    onLock = true;
  }
  if ( (ARM_DWT_CYCCNT - oldARM_DWT_CYCCNT) > strobeTime && onLock == true) {
    digitalWriteFast(backlightSignal, LOW);
    phaseDiff = ARM_DWT_CYCCNT - vsyncTimestamp;
    onLock = false; 
  }
}
https://youtu.be/wtmcwSCKkhk

Another thing I discovered is you can move phase around erratically and you won't even see any flicker. so i can filter the frametimes and then slew it aggressively to where i need it. if that makes sense.

btw here's how to change od with ddc commands

Image

0% OD 0
1% OD 20
2% OD 40
3% OD 60
4% OD 80
5% OD 100

unfortunately the hidden od mode OD strong weak disables those commands.
probably not useful for the blurbusters strobe app since elmbsync locks OD when enabled.

edit: added much better phase correction strobe will always return to the crosstalk sweet spot.

Post Reply