Custom Resolution Utility (CRU)

[ToastyX]

(12-17-2020 06:50 PM)traderdude123 Wrote:  I capture these shots from my TVs hdmi diagnostics screen after using the lg_cx_48Gbps.dat

https://ibb.co/myQGkTw

https://ibb.co/QpHympm

Any idea what they mean?

Should i be worried about the error count?

I don't know. Maybe the hardware or firmware can't handle a 48 Gbps signal without errors. That might be why it's limited to 40 Gbps by default.

[ToastyX]

(12-18-2020 03:00 AM)ship1666 Wrote:  In my case, do you think I need 3 active adaptors DP to HDMI, or just 1 active adaptor and 2 HDMI cables? Which way is gonna be work with NV surround.

I don't know. Either way, you'll need the HDMI cables, so try it with one adapter first.

[mathieulhe]

(12-18-2020 03:16 AM)ToastyX Wrote:  

(12-17-2020 06:50 PM)traderdude123 Wrote:  I capture these shots from my TVs hdmi diagnostics screen after using the lg_cx_48Gbps.dat

https://ibb.co/myQGkTw

https://ibb.co/QpHympm

Any idea what they mean?

Should i be worried about the error count?

I don't know. Maybe the hardware or firmware can't handle a 48 Gbps signal without errors. That might be why it's limited to 40 Gbps by default.

The thing is, this happens even at 40gbps as soon as we apply the modified EDID. If we revert to the original EDID, still running at the same resolution and lane speed, the errors stop.

I see only 2 bytes were changed from the original EDID, I am not sure if byte 0xC6 (increment of +0x10 compared to the original) is only the FRL (are they using a bitmask? I assume byte 0xFF is a parity byte, are you sure it's properly calculated ? (I assume so, since the additional 0x10 from the modified byte is subtracted from the parity byte so it seems to be a sum)
I never looked into modifying EDID by hand before.

[jarkid]

(12-18-2020 02:56 AM)ToastyX Wrote:  

(12-18-2020 01:30 AM)jarkid Wrote:  So my default timing parameters for 60 Hz is "LCD native", and the other(75 Hz) is "LCD standard".

Then could you figure out that

1. Why does the manufacturer use different timing parameters for 60/75 Hz? or in fact, the most common parameters for 75 Hz or higher refresh rates is "LCD standard"?
2. Why is "LCD native" 75Hz good compared to "LCD standard" 75Hz? Or is that because my video card can't handle "LCD Standard" 75hz well?

"LCD native" is the same as "LCD standard" at 60 Hz. Both 60 Hz and 75 Hz are using standard timing parameters by default. The problem is the monitor. It should have no problem handling the default timing parameters. There's really no reason for "LCD native" to work better. That actually uses more bandwidth, so it's not a signal quality problem.

"That actually uses more bandwidth, so it's not a signal quality problem."

But this page tells that:
"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/

What if more bandwidth gives better signal quality...etc?

[ToastyX]

(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.

[ToastyX]

(12-18-2020 08:07 AM)mathieulhe Wrote:  The thing is, this happens even at 40gbps as soon as we apply the modified EDID. If we revert to the original EDID, still running at the same resolution and lane speed, the errors stop.

I see only 2 bytes were changed from the original EDID, I am not sure if byte 0xC6 (increment of +0x10 compared to the original) is only the FRL (are they using a bitmask? I assume byte 0xFF is a parity byte, are you sure it's properly calculated ? (I assume so, since the additional 0x10 from the modified byte is subtracted from the parity byte so it seems to be a sum)
I never looked into modifying EDID by hand before.

The highest four bits represent the maximum FRL rate. The lowest four bits are the YCbCr 4:2:0 deep color options. The last byte is a checksum. Even if the checksum wasn't calculated correctly, that wouldn't cause signal errors.

[diakou]

(12-16-2020 07:54 PM)ToastyX Wrote:  I have an idea to read the extension block directly from the monitor instead, but I'll need someone to test it because I don't have a monitor with 2 extension blocks. Will you be able to run some tests?

I don't mind running some tests - albeit, I would prefer if they weren't too complicated (which I doubt.)

I'll also provide you with whatever info you'd need for troubleshooting more 360Hz monitors in the future.

- Also, have you been witness to driver related flicker when doing nothing with NVIDIA GPUs (1660s in this case) / newer drivers? I'm getting a flicker every 10-15 mins or so and it's driving me mad. So I went down almost 4 driver revisions and it seems to have fixed only then. Annoying.

[ToastyX]

(12-18-2020 07:06 PM)diakou Wrote:  I don't mind running some tests - albeit, I would prefer if they weren't too complicated (which I doubt.)

I'll also provide you with whatever info you'd need for troubleshooting more 360Hz monitors in the future.

- Also, have you been witness to driver related flicker when doing nothing with NVIDIA GPUs (1660s in this case) / newer drivers? I'm getting a flicker every 10-15 mins or so and it's driving me mad. So I went down almost 4 driver revisions and it seems to have fixed only then. Annoying.

That sounds like a signal quality issue. You need a good quality DisplayPort cable for 360 Hz.

The first thing I want to check is to make sure I'm using NVIDIA's API correctly. I sent you a PM.

[cobhc]

Hi all,

I'm trying to run 1440p@120hz at more than 8bit 4:4:4 from an AMD 5700xt through HDMI into an LG CX. From what I understand the HDMI 2.0b port on the 5700xt should be able to do 1440p@120hz 10bit 4:2:2 but I can't choose anything other than 8bit 4:4:4 in the AMD driver settings. Could using CRU do anything to help me achieve my goal?

Thank you.

[ToastyX]

(12-19-2020 02:43 AM)cobhc Wrote:  I'm trying to run 1440p@120hz at more than 8bit 4:4:4 from an AMD 5700xt through HDMI into an LG CX. From what I understand the HDMI 2.0b port on the 5700xt should be able to do 1440p@120hz 10bit 4:2:2 but I can't choose anything other than 8bit 4:4:4 in the AMD driver settings. Could using CRU do anything to help me achieve my goal?

AMD GPUs will only do YCbCr 4:2:2 with TV resolutions.