Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators
Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators
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.
Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators
Narrowed it down to 1 single checkbox in CRU disabling LFC really strange
"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.
"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.
- Chief Blur Buster
- Site Admin
- Posts: 11714
- 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
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
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!
Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators
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.Chief Blur Buster wrote: ↑12 Jun 2021, 14:44LFC 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...
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.
Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators
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
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.
So I have been messing with cru. I have found freesync range to effect LFC behaviour but it doesn't actually effect gsync range
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.
- Chief Blur Buster
- Site Admin
- Posts: 11714
- 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
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
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!
Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators
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.Chief Blur Buster wrote: ↑13 Jun 2021, 00:33Very interesting observation about the FreeSync range controlling LFC behaviour with this implementation of NVIDIA G-SYNC Compatible.
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.
- Chief Blur Buster
- Site Admin
- Posts: 11714
- 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
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.
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
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!
Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators
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?
Re: Hacked ASUS VG279QM modified to single-strobe 60 fps capped VRR for emulators
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 . I can play games like cyber punk with this uncapped and it rivals fixed strobe with low crosstalk and minimum flicker.
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
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.
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;
}
}
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
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.