Custom Resolution Utility (CRU)

[Infinity]

Hello everyone!
I have overclocked my Samsung S22D390Q monitor to 75 Hz on it's native resolution (Full HD) and auto timings using HDMI 1.4 cable and Nvidia GTX 760 Ti (OEM) video card (by the specifications it is rebrand of GTX 670) on 361.91 driver. I haven't used CRU, only nvidia's tool in control panel. Everything is working fine, 75 Hz is now displayed in windows as refresh rate which monitor can use, in all my games it works too.
I have read on this forum that HDMI connection is limited to 165 Mhz pixel clock, but my pixel clock is 185.6250 Mhz. There are no artefacts or frameskipping.
I ran patcher and it found limits, but i don't patch the driver. Do i need to import HDMI.dat file or my system is bypassing this limit now? And is 165 Mhz limit actual now?

[ToastyX]

(02-22-2016 12:27 PM)Infinity Wrote:  I have read on this forum that HDMI connection is limited to 165 Mhz pixel clock, but my pixel clock is 185.6250 Mhz. There are no artefacts or frameskipping.
I ran patcher and it found limits, but i don't patch the driver. Do i need to import HDMI.dat file or my system is bypassing this limit now? And is 165 Mhz limit actual now?

HDMI 1.3 and later are capable of higher pixel clocks. The actual limit depends on the video card. Current video cards will allow higher pixel clocks as long as the monitor defines HDMI support in the EDID. You don't need to do anything because you're not using CRU to override the EDID.

[albertfu]

Hello,

I just tried to do some OC on my U28D590D monitor, and have some questions :

By using DP port of a 290X tri-crossfire configuration, "Pixel Clock Patcher" shouldn't be needed right ?


Started testing with 1080p resolution, and maximum refresh rate attainable without failure is 86Hz, moving up to 1440p and 1800p it is reduced to 85Hz.
So I thought 85-86Hz is the limitation of LCD panel itself and it didn't change across resolutions, but moving towards 2160p (native resolution of monitor), things got interesting:

In CRU, maximum refresh rate that can be chosen in LCD Standard mode is 73Hz, in LCD Reduced mode it is 77Hz. Any value above is forbidden with refresh rate marked in red and all other fields not filled.
But in Windows refresh rate scroll down list, only 67Hz or below in LCD standard mode and 69Hz or below in LCD reduced mode can be displayed and chosen.

Similar thing occurs to 3520*1980 resolution, in LCD standard mode, CRU let me set as high as 86Hz, but only 79Hz and below can be displayed in Windows refresh rate scroll down list and chosen.

So questions :
What is the reason of CRU's limitation upon refresh rate ?
(4K in LCD standard mode gives a 73Hz maxi refresh rate, anything above is forbidden in red color)

Why refresh rate that can be chosen in Windows is lower than in CRU ?
(4K in LCD standard mode gives a 67Hz maxi refresh rate, anything above can't be displayed in scroll down list)

Thanks in advance !



BTW, how does OCing of monitor impact its lifespan ? I'd like to hear from a forum dedicated to that.

[ToastyX]

(02-24-2016 12:31 PM)albertfu Wrote:  By using DP port of a 290X tri-crossfire configuration, "Pixel Clock Patcher" shouldn't be needed right ?

The patch does nothing for DisplayPort, but pixel clock limitations can still exist.

(02-24-2016 12:31 PM)albertfu Wrote:  What is the reason of CRU's limitation upon refresh rate ?
(4K in LCD standard mode gives a 73Hz maxi refresh rate, anything above is forbidden in red color)

That's an EDID limitation. It's not possible to define a pixel clock greater than 655.35 MHz. Higher pixel clocks would require the DisplayID standard, which isn't widely used yet.

(02-24-2016 12:31 PM)albertfu Wrote:  Why refresh rate that can be chosen in Windows is lower than in CRU ?
(4K in LCD standard mode gives a 67Hz maxi refresh rate, anything above can't be displayed in scroll down list)

That's a driver limitation. I'm not sure what limit you're running into, but it looks like the driver is not allowing a horizontal scan rate greater than 150 kHz, which I haven't seen before.

(02-24-2016 12:31 PM)albertfu Wrote:  BTW, how does OCing of monitor impact its lifespan ? I'd like to hear from a forum dedicated to that.

That depends on the hardware. There's no way to know for sure, but something like 75 Hz shouldn't be an issue.

[albertfu]

(02-24-2016 03:29 PM)ToastyX Wrote:  

(02-24-2016 12:31 PM)albertfu Wrote:  By using DP port of a 290X tri-crossfire configuration, "Pixel Clock Patcher" shouldn't be needed right ?

The patch does nothing for DisplayPort, but pixel clock limitations can still exist.

(02-24-2016 12:31 PM)albertfu Wrote:  What is the reason of CRU's limitation upon refresh rate ?
(4K in LCD standard mode gives a 73Hz maxi refresh rate, anything above is forbidden in red color)

That's an EDID limitation. It's not possible to define a pixel clock greater than 655.35 MHz. Higher pixel clocks would require the DisplayID standard, which isn't widely used yet.

(02-24-2016 12:31 PM)albertfu Wrote:  Why refresh rate that can be chosen in Windows is lower than in CRU ?
(4K in LCD standard mode gives a 67Hz maxi refresh rate, anything above can't be displayed in scroll down list)

That's a driver limitation. I'm not sure what limit you're running into, but it looks like the driver is not allowing a horizontal scan rate greater than 150 kHz, which I haven't seen before.

(02-24-2016 12:31 PM)albertfu Wrote:  BTW, how does OCing of monitor impact its lifespan ? I'd like to hear from a forum dedicated to that.

That depends on the hardware. There's no way to know for sure, but something like 75 Hz shouldn't be an issue.

Thanks for your prompt reply ! That explains a lot.

For limitation of horizontal scan rate (150KHz), it came to my mind too, I noticed it while switching between LCD standard and LCD reduced modes. Both top at approximately 150KHz horizontal scan rate at 4K.

But later I tried 3200*1800@85Hz and 3520*1980@79Hz and succeeded, they both exceed 150KHz horizontal scan rate (160KHz and 162.2KHz respectively), so it seems that the limitation is not the same across resolutions, quite weird...



Tried Pixel Clock Patcher and no avail, as expected (it is over DP port).

Another question : if we only take LCD panel's capability into consideration, refresh rate limitation should remain the same for different resolutions ?

[Johnnyp]

I've been reading that nvidia forces GPU scaling and the only way to fix it is through EDID overrides.

I have an Asus VG248QE, and would like to force display scaling, for native 1920x1080 @ 144hz.

Is there an idiots guide on how to do this w/o having to read through 200 pages of this thread?

[albertfu]

When searching similar issue, I discovered frame skipping and had my monitor tested, result : positive, it gets frames skipped when overclocked.

So it's quite pointless to overclock it to 85Hz while some frames are skipped.
I have to admit that for me it's hard to notice frame skipping without tests on Blur Busters, but fact is fact.
Also I couldn't tell the difference between 60Hz and 85Hz, maybe it's due to frame skipping.

Next time will try to acquire a 120Hz or 144Hz monitor to see if high refresh rate really is that good or not for me.

[ToastyX]

(02-24-2016 05:27 PM)albertfu Wrote:  Another question : if we only take LCD panel's capability into consideration, refresh rate limitation should remain the same for different resolutions ?

The panel only runs at the native resolution. Other resolutions are scaled to the native resolution by the monitor's scaler. The scaler can have its own limitations at different resolutions.

(02-25-2016 12:07 AM)albertfu Wrote:  When searching similar issue, I discovered frame skipping and had my monitor tested, result : positive, it gets frames skipped when overclocked.

So it's quite pointless to overclock it to 85Hz while some frames are skipped.
I have to admit that for me it's hard to notice frame skipping without tests on Blur Busters, but fact is fact.
Also I couldn't tell the difference between 60Hz and 85Hz, maybe it's due to frame skipping.

It should be obvious just by moving the mouse cursor. Frame skipping should be more noticeable than the difference between 60-85 Hz.

[ToastyX]

(02-24-2016 07:19 PM)Johnnyp Wrote:  I've been reading that nvidia forces GPU scaling and the only way to fix it is through EDID overrides.

I have an Asus VG248QE, and would like to force display scaling, for native 1920x1080 @ 144hz.

The native resolution isn't scaled. That only applies to lower resolutions.

(02-24-2016 07:19 PM)Johnnyp Wrote:  Is there an idiots guide on how to do this w/o having to read through 200 pages of this thread?

I don't know what criteria NVIDIA's driver uses to determine if display scaling is available. It's supposed to be available if lower resolutions are defined in the EDID, but apparently that's not happening for some reason.

[albertfu]

(02-25-2016 02:58 PM)ToastyX Wrote:  

(02-24-2016 05:27 PM)albertfu Wrote:  Another question : if we only take LCD panel's capability into consideration, refresh rate limitation should remain the same for different resolutions ?

The panel only runs at the native resolution. Other resolutions are scaled to the native resolution by the monitor's scaler. The scaler can have its own limitations at different resolutions.

(02-25-2016 12:07 AM)albertfu Wrote:  When searching similar issue, I discovered frame skipping and had my monitor tested, result : positive, it gets frames skipped when overclocked.

So it's quite pointless to overclock it to 85Hz while some frames are skipped.
I have to admit that for me it's hard to notice frame skipping without tests on Blur Busters, but fact is fact.
Also I couldn't tell the difference between 60Hz and 85Hz, maybe it's due to frame skipping.

It should be obvious just by moving the mouse cursor. Frame skipping should be more noticeable than the difference between 60-85 Hz.

Tried to notice frame skipping by moving mouse cursor, and can't tell the difference between 60hz without frame skipping and 85hz with it......
Maybe it will be more obvious when compared against a native 85hz monitor

Anyway thanks a lot for your help (and for developing CRU too) !