Threaded Mode | Linear Mode

ioannis · 12-20-2020, 06:01 PM

Hello and congrats on this great utility! I've managed to lower my freesync limits from 48-75 to 30-75 but on every reboot it gets backs to 48-75 even though on CRU it says 30-75 (i can see it in games that is in fact 48-75). I have an RTX 2060. I include two screenshots of how I did the settings. Thanks!

***ToastyX*** · 12-21-2020, 01:55 AM

(12-20-2020 06:01 PM)ioannis Wrote: Hello and congrats on this great utility! I've managed to lower my freesync limits from 48-75 to 30-75 but on every reboot it gets backs to 48-75 even though on CRU it says 30-75 (i can see it in games that is in fact 48-75). I have an RTX 2060. I include two screenshots of how I did the settings. Thanks!

Does that mean it works after running restart64.exe but reverts after rebooting? That would mean a driver bug. Are you using DisplayPort or HDMI? Try adding a FreeSync range data block in the extension block and set the range there.

ioannis · (Last edited: 12-21-2020, 07:17 AM by ioannis)

(12-21-2020 01:55 AM)ToastyX Wrote: Does that mean it works after running restart64.exe but reverts after rebooting? That would mean a driver bug. Are you using DisplayPort or HDMI? Try adding a FreeSync range data block in the extension block and set the range there.

Yes it works as it should in the first place but after reboot it gets back to defaults. I am using a displayport. The extension block is used with HDMI?

***ToastyX*** · 12-21-2020, 12:56 PM

(12-21-2020 07:17 AM)ioannis Wrote: Yes it works as it should in the first place but after reboot it gets back to defaults. I am using a displayport. The extension block is used with HDMI?

The data block was meant for HDMI FreeSync, but NVIDIA's driver seems to listen to it with DisplayPort.

ioannis · (Last edited: 12-21-2020, 02:46 PM by ioannis)

(12-21-2020 12:56 PM)ToastyX Wrote: The data block was meant for HDMI FreeSync, but NVIDIA's driver seems to listen to it with DisplayPort.

Still does not work, and now it does not work even before the reboot. Probably it is a driver bug after all. That's what I did, in the screenshots..

***ToastyX*** · 12-21-2020, 03:01 PM

(12-21-2020 02:46 PM)ioannis Wrote: Still does not work, and now it does not work even before the reboot. Probably it is a driver bug after all. That's what I did, in the screenshots..

Do it both ways, and don't add an extension block. Put it in the existing extension block. If there's no room, you can delete the HDMI data block because it's not needed with DisplayPort.

ioannis · 12-21-2020, 03:23 PM

Sadly it does not work. If i set it in the extension block (in the existing one) it does not work at all. If I set it above, in the display port section it works but resets after I reboot. It's fine though, thanks a lot for the help anyway!!

Epic753 · (Last edited: 12-21-2020, 07:02 PM by Epic753)

(12-16-2020 08:15 PM)ToastyX Wrote:
(12-16-2020 06:04 PM)Epic753 Wrote: BTW Lenovo says new Firmware in testing for my Y27Q20 monitor - this monitor has known black screen issues past year w/10xx series nvidia cards (I have 3070 but still may apply).

Since CRU clearly masking this issue (and assuming display EDID can change w/new firmware).

Could new monitor firmware be my fix?
It might. If it's stable after changing the range with CRU, then it might be a driver bug. The buggy firmware on the monitor could be causing an unstable or incorrect DisplayPort signal that the driver is not handling correctly. I don't think audio has anything to do with the problem. Since the monitor also has HDMI, it might be worth checking to see if the problem also happens with HDMI.

Thanks. Buggy firmware means incorrect code structure within it's own stack correct?

I am still completely stable with CRU albeit 8 bit color no HDR. I will next try HDMI 2.1 cable RTX 3070 to Y27Q20, coming in the mail. This will also allow me to connect to my LG C9. If not that then I will load the beta Lenovo Y27Q20 firmware supplied to me from Lenovo. If neither those I will be at a loss but I am never at a loss for ideas.

Question: My CRU settings reset at some point again to default (maybe PC power cycle etc.).

Even though I have a modified profile ready in CRU (asterisk) it will not stick by selecting and clicking ok, then resetting with CRU 64.exe. If I redo a new custom profile and then 64.exe restart it sticks.

Why can't I just select modified settings from dropdown, click ok, and rest 64.exe?

Do you have Paypal tip instead of Patreon?

***ToastyX*** · 12-22-2020, 02:44 AM

(12-21-2020 06:59 PM)Epic753 Wrote: Thanks. Buggy firmware means incorrect code structure within it's own stack correct?

I am still completely stable with CRU albeit 8 bit color no HDR. I will next try HDMI 2.1 cable RTX 3070 to Y27Q20, coming in the mail. This will also allow me to connect to my LG C9. If not that then I will load the beta Lenovo Y27Q20 firmware supplied to me from Lenovo. If neither those I will be at a loss but I am never at a loss for ideas.

Yes, I mean the firmware in the monitor could be faulty and making it produce a bad signal that's causing NVIDIA's driver to crash, which would also be a bug in NVIDIA's driver. If it also happens with HDMI, then I would suspect a hardware problem.

(12-21-2020 06:59 PM)Epic753 Wrote: Question: My CRU settings reset at some point again to default (maybe PC power cycle etc.).

Even though I have a modified profile ready in CRU (asterisk) it will not stick by selecting and clicking ok, then resetting with CRU 64.exe. If I redo a new custom profile and then 64.exe restart it sticks.

Why can't I just select modified settings from dropdown, click ok, and rest 64.exe?

That's a list of monitors, not settings. The drop-down list is to choose which monitor entry to edit, not which settings to apply. Use the copy and paste buttons at the top to copy everything over to the active entry.

The settings shouldn't reset on their own. If you see a new active entry but the old one is still there, that means the driver is detecting the monitor as a different monitor, which isn't normal.

(12-21-2020 06:59 PM)Epic753 Wrote: Do you have Paypal tip instead of Patreon?

Sure: https://paypal.me/ToastyX

jarkid · 12-22-2020, 10:47 AM

(12-18-2020 02:50 PM)ToastyX Wrote:
(12-18-2020 08:07 AM)jarkid Wrote: "LCD native" just uses the 60 Hz "LCD standard" timing parameters for all refresh rates. This works better when adding higher refresh rates with some LCD monitors and TVs. This is also what is filled in by default when clicking the "Add..." button.
https://forums.guru3d.com/threads/cru-cu...rt.410187/
That's in the context of adding higher refresh rates. You're not adding higher refresh rates. The monitor is supposed to support 75 Hz by default, and it should be able to handle the timing parameters defined in the EDID.

I added "LCD native" because HDTVs and some 60 Hz monitors are more likely to accept higher refresh rates with the 60 Hz timing parameters. It has nothing to do with the signal quality or how well the signal works. Many monitors can handle both "LCD standard" and "LCD native" just fine.

Dear ToastyX,

Could you explain what's the difference between longer blanking pixels and shorter blanking pixesl, for example, LCD standard and LCD reduced?

Does a longer blanking(280 pixels) have a different visual effect on a monitor compared to a shorter blanking(88 pixels)?

What I don't get is the refresh rate is all the same. Even if they have different blanking, they are still the same refresh rate.

I won't have a slower or a faster response based on different blankings.

After I tried many times, the monitor would flicker sometimes at 75hz while using LCD standard. But it's both fine at LCD native and LCD reduced.

The question is the LCD native has 280 blanking pixels and LCD reduced has 88 blanking pixels, they both are fine. But the LCD standard 160 blanking pixels which are between 88 and 280, has the flickering issue.

I am wondering what probably causes the issue, thank you for your help.