Allow pixel clock > 400MHz

[waperboy]

Tech is moving on, and people are actually running 2560x1440 resolution at 120+ Hz. Removal of 400MHz pixel clock limit in Linux drivers is requested.

Tested on 295.40 and 295.49.

This should actually work on a GTX 680, and people have used such timings in Windows:

ModeLine       "2560x1440_120" 478.785 2560 2608 2640 2704 1440 1443 1448 1475 +hsync +vsync
Option         "UseEdid" "FALSE"
Option         "ExactModeTimingsDVI" "TRUE"
Option         "ModeValidation" "NoVertRefreshCheck, NoHorizSyncCheck, NoDFPNativeResolutionCheck, NoMaxSizeCheck, NoMaxPClkCheck, NoEdidMaxPClkCheck, NoEDIDModes"

But get this:

[    19.217] (II) NVIDIA(0):   Validating Mode "2560x1440_120":
[    19.217] (II) NVIDIA(0):     2560 x 1440 @ 120 Hz
[    19.217] (II) NVIDIA(0):     Mode Source: X Configuration file ModeLine
[    19.217] (II) NVIDIA(0):       Pixel Clock      : 478.79 MHz
[    19.217] (II) NVIDIA(0):       HRes, HSyncStart : 2560, 2608
[    19.217] (II) NVIDIA(0):       HSyncEnd, HTotal : 2640, 2704
[    19.217] (II) NVIDIA(0):       VRes, VSyncStart : 1440, 1443
[    19.217] (II) NVIDIA(0):       VSyncEnd, VTotal : 1448, 1475
[    19.217] (II) NVIDIA(0):       H/V Polarity     : +/+
[    19.217] (II) NVIDIA(GPU-0):     BestFit Scaled and BestFit AspectScaled are identical;
[    19.217] (II) NVIDIA(GPU-0):         collapsing BestFit AspectScaled.
[    19.217] (II) NVIDIA(GPU-0):     BestFit Centered and BestFit Scaled are identical;
[    19.217] (II) NVIDIA(GPU-0):         collapsing BestFit Scaled.
[    19.217] (WW) NVIDIA(GPU-0):     BestFit Centered ViewPort 2560x1440 exceeds hardware
[    19.217] (WW) NVIDIA(GPU-0):         capabilities.
[    19.217] (WW) NVIDIA(0):     Mode is rejected: Unable to construct hardware-specific
[    19.217] (WW) NVIDIA(0):     mode timings.

...or am I missing something?

Timings that DO work, include:

ModeLine       "2560x1440_100" 400.000 2560 2592 2612 2692 1440 1443 1448 1480 +hsync +vsync
ModeLine       "2560x1440_102" 400.000 2560 2592 2612 2692 1440 1442 1446 1456 +hsync +vsync
ModeLine       "2560x1440_103" 400.000 2560 2592 2612 2692 1440 1441 1442 1444 +hsync +vsync

but anything with a pixel clock above 400 is summarily rejected, although the hardware can use it.

[Spyke]

So its true, stupid hard coded 400Mhz limit in the drivers.... LAME.

People with 680's can do 500+MHz pixel clock with ease in Windows.

Will NVIDIA fix it though? I mean there was a thread a while ago that they completely ignored, but replied in that thread relating to another issue, yet ignoring the main issue......

It will be like Stereo 3D I bet, nerf running 4K displays (and thus high pixel clocks) so only Quadro cards can run such resolutions or refresh rates....

NVIDIA Linux Devs Please Take NOTE:

Your Engineers have already stated that Fermi's can run 450MHz, and Keplars can run much higher. If your own Engineers can state that, then please remove the hardcoded limit from the Linux drivers.

There is a whole thread on www.120hz.net that posts the replies from NVIDIA on this subject, but I'm too lazy to hunt them down that the moment. They also explicitly state that 400MHz is the limit in SLI due to the SLI bridge bandwidth limitations...... but thats only when using a pair of cards in SLI (or a dual GPU 690).

[sandipt]

NVIDIA internal Bug ID: 990023 to track this issue.

[AaronP]

Could someone please follow the instructions in the thread about how to report a problem, particularly the section about generating an nvidia-bug-report.log.gz with a verbose X log? Thanks.

[Spyke]

I'll have one for you later when I'm done work. I too bought a 680 just for higher pixel clocks.

Thanks guys for looking into this.

[AaronP]

Spyke, can you do me a favor and link to where you found the 680 being specified as having a > 400 MHz maximum pixel clock, please?

[Spyke]

Originally Posted by AaronP

Spyke, can you do me a favor and link to where you found the 680 being specified as having a > 400 MHz maximum pixel clock, please?

Read the whole post in green and the followups.

http://www.120hz.net/showthread.php?...ull=1#post3576

[waperboy]

Ok, let's see if this is of any use.

nvidia-bug-report.log.gz

[Spyke]

People are easily getting over 500MHz in Windows on a 670/680 so that makes moot what engineers have said anyway.

The Linux drivers should simply have the hardcoded limit removed, especially with the huge ****tail of ModeValidation overrides that are required in xorg.conf to even make use of such high clocks.....

EDIT: LOL, c.o.c.k.t.a.i.l is censored.

[Xevious]

Originally Posted by AaronP

Spyke, can you do me a favor and link to where you found the 680 being specified as having a > 400 MHz maximum pixel clock, please?

Aaron there is this whitepaper where it says that the gtx 680 has been tailored for next-generation 4k displays on page 26:

http://www.geforce.com/Active/en_US/...aper-FINAL.pdf

I know I have heard this other places as well. Sorry but 400 Mhz pixel clock is not enough for a 4k display, period.

I am using a 4k display via two dual link DVI links (each driving 1920x2400) for 3840x2400. This is only at 48 Hz and its 244 Mhz per half that is 488 Mhz in total bandwidth I am using to drive the display. And this is at 48 Hz. Seems like the linux driver needs to get fixed? People on windows can pump out 500 Mhz no problem.

[waperboy]

Alas, even IF they decide to change the driver to allow higher pixel clock, it will probably not be done in the forseeable future - forseeable meaning useful, as in before the next iteration of cards.

[waperboy]

More worrying are the findings on windows that the new 304.48 drivers have REDUCED the max pixel clock to 330MHz (!), together with the statements in this thread:

...we have made a decision to support Linux on our GPUs by leveraging NVIDIA common code...

Linux end users benefit from same-day support for new GPUs , OpenGL version and extension parity between NVIDIA Windows and NVIDIA Linux support, and OpenGL performance parity between NVIDIA Windows and NVIDIA Linux.

So it looks suspiciously like we can expect not an improvement, but rather a regression in performance in this area.