Page 1 of 1

Dirty Hack for Displays that OC 720p to 120hz, but not 1080p

Posted: 25 Mar 2014, 00:41
by trey31
Disclaimer: I'm not advocating that this is a fix for 1080p panels that won't overclock to 120hz, nor that it is ideal, nor that it is even possible for every display.

That being said, I found the limitation of an HDMI 3D TV that overclocks to a true 120hz at 720p, 900p, and 1760x990 (all frame-skipping tested), but barely overclocks above 100hz at standard 1920x1080 timings. I previously thought this was the TV's dot clock limitation, or perhaps a cable limitation (not likely with High Speed HDMI and pixel clocks under 330-340MHz). Turns out it is a panel limitation (I think) that refuses to display above 110hz beyond a certain horizontal pixel width. The particular display I tested was fine at 120hz with 1728 horizontal active pixels, but was sketchy at 1760 and complete bust at 1780.

Here is a list of 16:9 resolutions that work at 120hz:
720p (added as default secondary resolution/refresh via CRU)
1600x900 (added as default secondary resolution/refresh via CRU)
1760x990 16:9

Here is a list of dirty hack resolutions that work at 120hz:
1755x1080 13:8
1750x1000 7:4 / 14:8 (for comparison to native)
1740x1080 29:18 / 14.5:9 (for comparison to native)
1728x1080 8:5 / 16:10 (because calling them 8:5 monitors would've blown consumers minds...)
1600x1400 8:7 / 16:14 (for comparison to native)
1600x1200 4:3 / 16:12 (to further confuse anyone who's mind was just blown after seeing the 8:5 aspect ratio)

Here is a very dirty hack to get games to render at 1920x1080 at 120hz, while sending a reduced pixel resolution to your display:
1. use NVIDIA Control Panel's Custom Resolution (CRU won't allow active pixels to be lower than desktop pixels like NVIDIA does)
2. set "desktop resolution" fields at the top of the custom resolution screen to 1920 x 1080 at 120hz
3. select Manual Timings
4. Enter a reduced active horizontal pixel value (like 1920 to 1728 or 1755)
5. Enter a reduced total horizontal pixel value (like 1838 or 1865)
6. Test the resolution.

Similar to downsampling, this forces a 16:9 desktop resolution. Because of the reduced timings, it will either be slightly stretched on the display into a full screen image that maintains 16:9 aspect ratio (at the cost of introducing slight FXAA-like blur), or appear with a very slight letterbox, depending on the display. If the letterbox occurs, consider trying the 1728x1080 resolution instead.

Your mileage will vary.

quote from other thread discussing the issue:
trey31 wrote:Also of note, I found the clock limit of the M651d (313.99MHz) and the non-clock related restriction of 1080p at 120hz.

At 1920x1080 Active pixels with 2025x1090 Total pixels at 120hz, the dot clock is 264.87
At 1920x1080 Active pixels with 2025x1090 Total pixels at 108hz, the dot clock is 238.383

120hz fails. So does everything down to 109hz (109hz works fine as a custom resolution with even further reduced timings, +104 horizontal and +9 vertical total pixels above the active pixels; it even retains full sound. It just refuses to work as a native res with a modified EDID; so I still use 108hz.)

However, this is not the Pixel Clock limit of the panel.

At 1920x1080 Active pixels with 2025x1260 Total pixels (a +170 pixel increase of the vertical blank over the above timings) at 108hz, the dot clock is 275.562, which works flawlessly. The anomaly here is the fact that a very similar timing to the 120hz above has an 11MHz higher clock at 108hz and works fine, but nothing works between 120-110hz.

So to test a hypothesis, I created a custom 16:10 resolution of 1728x1080.

At 1728x1080 Active pixels with 1848x1400 Total pixels at 120hz, the dot clock is 310.464, which looks great and scales very well as the panel only stretches the image horizontally 192 pixels and not at all vertically.

Ok so this tells me the display is having issues with the number of horizontal pixels above a certain refresh rate, which doesn't appear to have much of anything to do with the pixel clock nor the amount of vertical pixels.

So to test the theory again, I created a custom 29:18 (14.5:9 if you want to compare it to 16:9) resolution of 1740x1080.

At 1740x1080 Active pixels with 1844x1089 Total pixels at 120hz, the dot clock is 240.9739, and it works great at 120hz. But...
At 1740x1080 Active pixels with 1844x1100 Total pixels at 120hz, the dot clock is 243.4080, and it is not working properly.

So my guess is that anything greater than 1728 Active horizontal pixels causes the display to become less and less stable between 108hz and 120hz.

4K Resolution downsample UPDATE:
Also, to update what I previously posted in the thread about 4K resolution and pixel clock, the M651d successfully passed at 3840x2160 Active pixels with 3944x2169 Total pixels at 37hz (36.7hz), and the dot clock is 313.9515

Going above 313.99MHz clock at any resolution causes screen flickering, every step of .1 above that introduces significantly more. 314.0000MHz appeared to be stable, but I encountered some very minor flicker and changed all the custom resolutions to at least 313.99MHz and have seen no issue sense then. Also, anything near 315MHz or above flickers and shakes severely.

Re: Dirty Hack for Displays that OC 720p to 120hz, but not 1

Posted: 25 Mar 2014, 00:54
by trey31
Also, correct me if I am wrong, but I think 3D Blu-ray players may be sending displays that are true "120hz" an actual 1920x1080 signal at 120hz, but because it is at 24 bits instead of 32 bits like Windows 7/8+, the display's timing is not having issues with it. Whereas on Windows PCs, the 32 bit depth at 1080p may be causing the many reported issues of incompatibilty at 120hz in 1080p over HDMI for most/many 3D TVs.

I also think the m651d's clock limitation of 313-314MHz might actually be the full HDMI spec of 340MHz when used at 24 bit color depth. But, I have no way to test because WIndows 8/8.1 force 32 bit color depth at all times, regardless of actual source.

I'll test this once Steam OS is out and fully supported. I plan on running a dual boot Steam OS plus Ubuntu or Fedora distro before too long. I'm sure linux still allows the user to set color depth.

EDIT: Or possibly the 313-314MHz is HDMI's pixel clock limitation at 32 bit color, and 340MHz is the limit at 24 bit??

Re: Dirty Hack for Displays that OC 720p to 120hz, but not 1

Posted: 25 Mar 2014, 08:31
by Chief Blur Buster
trey31 wrote:24 bits instead of 32 bits like Windows 7/8+
That's the alpha channel -- that's done at the GPU level, so 32bits is actually 24bits to the display.

From a Blu Ray player, it's transmitted as YCbCr.
However, there could be a 4:4:4 chroma versus 4:2:2 chroma bandwidth behavior.

Re: Dirty Hack for Displays that OC 720p to 120hz, but not 1

Posted: 25 Mar 2014, 10:39
by RealNC
Could be related:

It seems some TVs do not expect full 4:4:4 chroma.

Re: Dirty Hack for Displays that OC 720p to 120hz, but not 1

Posted: 25 Mar 2014, 12:58
by trey31 wrote:The Blu-ray specification for movies (BD-ROM) does not support Deep Color or the new xvYCC color space. Oops.

I'll say it again: Blu-ray and HD DVD movie formats are limited to 8-bit 4:2:0 YCbCr. To our knowledge, there is no move to add xvYCC expanded color capability to the BD-ROM specification. In addition, issues of backwards compatibility would be extremely difficult to overcome, rendering any new 10-bit or higher formats unplayable on legacy BD players. The only solution would be to take advantage of larger BD storage media and issue discs with dual data streams for video (double sided or dual layer if you will).

Currently, Hollywood films are telecined directly to digital, with masters stored on D5 tape in 10-bit 4:2:2 format. While this is better than the 8-bit 4:2:0 present on current media, it's still not 12- or 16-bit Deep Color or even utilizing the xvYCC color space.
Apparently I need to do some more in-depth reading about color encoding. I know that many Blu-Ray players have options for outputting Deep Color and YCbCr 4:4:4, but if the source material is still compressed YCbCr 4:2:0 8-bit then is the BD player converting the color space and the HDMI cable carrying uncompressed 4:4:4 video data to displays? Or is it still only carrying the compressed 4:2:0 from the source material?
According to this chart, HDMI can do 120hz at 24bpp, but not at 30bpp nor 36bpp, correct? Also from what I have always assumed 24bpp is 8bit color x 3 channels (Red, Green, Blue) right?

If this is the case, it seems that HDMI panels limited to less than 120hz at 1080p aren't being limited internally, but rather HDMI bandwidth? Assuming the use of 4:4:4 YCbCr encoding anyway?

If I recall correctly, aren't all current 120hz Monitors (not 3D TVs) on the market using DisplayPort or DL DVI-D connections, rather than HDMI? The way I've understood DL DVI-D is that the connection isn't limited by its connection or input, but rather by the output of the source component (GPU) and the quality of the cable itself, so in theory it could (and probably does with quality cables) have more bandwidth than current HDMI standards, right? At least in regards to video bandwidth specifically considering DVI doesn't carry any audio?
RealNC wrote:It seems some TVs do not expect full 4:4:4 chroma.
From what I understand some TV's refuse 4:4:4, some convert the color space to non-4:4:4, and some happily use the color space and display higher pixel and color details (the vizio m651d does but apparently only above 61hz; or it does at any hz but with some kind of internal processing being applied at 60hz and below. I posted about it here: At least this is what I had previously understood to be the case.

From what I understood, most (if not all) monitors with digital inputs use 4:4:4, but I could be wrong.

Also it seems like there may be some answers to some of these questions here: ... hread/0_50 if anyone is interested but I have not read the entire thread yet.

Re: Dirty Hack for Displays that OC 720p to 120hz, but not 1

Posted: 25 Mar 2014, 13:11
by trey31

Changing color space to/from RGB has exactly the same limits on custom resolutions/overclocks either way. Pixel clock is reported by NVIDIA CP to be the same regardless of which color mode is selected.