Two Hacks For The NVIDIA Linux Graphics Driver

[blackout23]

What is is it with "nvidia-smi"? It works just fine on my 580 with latest beta driver and reports running cuda applications, fanspeed etc.

[kokoko3k]

What is is it with "nvidia-smi"? It works just fine on my 580 with latest beta driver and reports running cuda applications, fanspeed etc.

See if reports gpu utilization with this:

nvidia-smi -q --display=UTILIZATION

--

I've had an idea to benchmark compositing performance; with this:

#!/bin/bash
export LD_LIBRARY_PATH=/tmp/nvml_fix/built/319.32/
while true ; do 
    gpuuse=$(nvidia-smi -q --display=UTILIZATION |grep Gpu|sed  's/ //g'|cut -d ":" -f 2|cut -d "%" -f 1)
    echo -n $gpuuse" "
    #test $gpuuse -gt 1 && echo "higher" || echo "lower"
    sleep 0.5
done

The commented line is something i plan to use to make my gpu switch performance profiles better than the default nvidia strategy that often produces lags in webpage scrolling or window moving (my stock low freqs are REALLY low).

Anyway, you can monitor the gpu use on little cpu cost (0%cpu on an E7500@3Ghz).

GPU:  9500GT
Vsync: enabled (without vsync you have always 100% gpu)
App: glxgears (that is not a benchmark, but in this case it IS)
WM: Kwin-4.10.5
Resolution: 1280x1024
Maximized as a frontmost window: gpu=20% 
Effects disabled:gpu=10%
Fullscreen and window unredirected (so effects enabled): 11%

It would be nice if this could be added to PTS, as a nvidia specific test.

[dee.]

I am pretty sure that the pixels of LCD monitors remain "lit" continuously without regard to the refresh rate of the signal. This is, in my opinion, what makes them so much better than CRTs and plasmas because they never flicker, even at "low" refresh rates like 60hz.

On any active matrix display, yes, the pixels stay lit constantly. Pretty much all modern TFT LCD's are active matrix LCD's. This also applies to some plasma displays, and OLED displays.

The limiting factor on the refresh rate of LCD's is mostly the pixel response time, ie. the time it takes for a pixel to transition from completely lit to completely dark, or vice versa.

[schmidtbag]

These seem like pretty nice patches. While they're very niche, they are practical and I can't imagine they're the easiest things to figure out.

[agd5f]

While there's no 1440p monitor that will advertise support for 120Hz, since it's way outside of the DVI spec, there are a few monitors that have been found capable of overclocking that high.

(As an FYI, both monitors I mentioned have incorrect EDID checksums, for some reason - you'll have to configure your display server to ignore that or the monitor will not be detected correctly.)

Probably whatever "vendor" hacked the EDID to expose the 120Hz mode didn't update the EDID properly to fix the checksum.

[CFSworks]

Probably whatever "vendor" hacked the EDID to expose the 120Hz mode didn't update the EDID properly to fix the checksum.

But that would make too much sense.
The vendor never intended for these to do 120Hz, so the EDID only reports 2560x1440@60Hz. To get 120, you have to write the modeline yourself.
My guess is the OEM only tested the EDID on Windows, which seems to ignore the EDID checksum.

[agd5f]

But that would make too much sense.
The vendor never intended for these to do 120Hz, so the EDID only reports 2560x1440@60Hz. To get 120, you have to write the modeline yourself.
My guess is the OEM only tested the EDID on Windows, which seems to ignore the EDID checksum.

Some 3rd parties sell pre-hacked monitors with a hacked EDID on ebay for people looking to use 120hz modes. Some users also hack their EDIDs themselves to add the 120hz modes. It's also possible the original vendor also messed up the EDID.

[CFSworks]

Some 3rd parties sell pre-hacked monitors with a hacked EDID on ebay for people looking to use 120hz modes. Some users also hack their EDIDs themselves to add the 120hz modes. It's also possible the original vendor also messed up the EDID.

Possible, but that sounds like a lot more effort than doing it in software, what benefit is there in doing that? You already have to resort to software modifications (in order to overcome the 400 MHz limit) so it seems pointless to waste time figuring out how to modify the monitor's microcontroller just to add a mode that an unmodified display driver is immediately going to reject anyway.

Regardless, no, these monitors do not report any mode other than 2560x1440@60Hz. Instead, I think the OEM that makes the PCBs (which seems to be the same across the Catleap, QX2710, and X-Star DP2710) simply didn't verify their EDID checksum, and shipped it without ever realizing that it was wrong.

[koolkao]

Checksum error QNIX2710

(As an FYI, both monitors I mentioned have incorrect EDID checksums, for some reason - you'll have to configure your display server to ignore that or the monitor will not be detected correctly.)

I'm a newbie with xorg.conf, and EDID. I also have a couple of QNIX2710 monitors that give checksum error in Xorg.0.log. This was not a problem under stock Ubuntu 12.04, but appeared after I installed Nvidia CUDA toolkit.

Do you mind pointing me towards any resources that show me how to ignore checksum errors, and how to set-up a correct Monitor section in xorg.conf for this monitor?

Thank you

[CFSworks]

Do you mind pointing me towards any resources that show me how to ignore checksum errors, and how to set-up a correct Monitor section in xorg.conf for this monitor?

Thank you

Oh, not at all! Here's what my xorg.conf looks like: https://gist.github.com/CFSworks/6101954
Note: I'm not an expert at writing xorg.conf's, so please don't use mine as a prime example. Also, I don't know if those timings are optimal, but they do produce pretty stable 120Hz output for me at least.
Note #2: When you use NoEdidModes, the nvidia driver seems to insert 800x600 mode on its own. Using this mode will not work; your monitor will start displaying a bunch of test patterns until you set it back to 2560x1440.

For an explanation on all of the driver options, see Appendix D of the driver manual.

Hope this helps!