2014/01/28

Display overclocking with XRandr

As the trends shift and more enthusiast class users start considering Linux, it is important you supply them with the tools to do all the push-it-to-the-limit overtuning effects they had available under Windows.

Monitor overclocking isn't a well documented art, especially since it can literally break the display, in a way reminiscent of 90's AMD processors literally melting their sockets. This isn't the coddled down overclocking of todays desktops, where pushing things too far just results in an unexpected reboot and need to tweak expectations lower. Try setting your monitors refresh rate to twice or more what it is rated and have fun with a dead panel.

That doesn't mean you can't overclock soundly. Trying to double your refresh rate is like trying to run an i7 at 6ghz with the stock cooler. Instead, look for incremental increases in performance like any other overclock, and hold it back from the literal edge of stability a bit so your screen lasts longer than a month.

Under Windows, as usual, the sizable install base has produced graphical tools to set refresh rates. And yet again, Linux proves its technological superiority by not requiring any such tool, xrandr has all the facilities you need to create custom display modes.

So yeah, we are using the cli here, but this is one situation I'll defend this usage - one, it requires you to know what the hell you are doing, and two it is integrated right into the display manager itself and is literally a few bash lines, and if you get a stable OC you can just add it to your xprofile or autostart scripts. In this example I'm taking a 60hz screen to 65 - start here, at the least (or on a 30hz panel at like 33), and increment up until you start seeing graphical errors or glitches. Good tests for graphical errors are fast paced rapid scene changes in 3d games, plus some repetitious pattern (to gauge burn-in), plus anything that rapidly fluctuates the subpixels color intensity, I just use a gif of rapid color flicker at 48 fps.

First, we use the cvt, provided by xorg, which stands for coordinated video timings from VESA. It generates the modelines for our desired new display profile.

cvt 1920 1080 65

Modeline "1920x1080_65.00"  188.00  1920 2048 2248 2576  1080 1083 1088 1124 -hsync +vsync

We get back this Modeline, which we will add to xrandr - note changing the quoted part just changes what we name this mode, so you can name it "oc" or "65" and be fine, since xrandr by default populates modes by resolution (ie, 1920x1080).

xrandr --newmode "1920x1080_65.00" 188.00 1920 2048 2248 2576 1080 1083 1088 1124 -hsync +vsync

So now we have a registered mode, we need to add it as a valid mode to our specific screen - running xrandr without arguments prints the state of all the display outs, find your choice screen and replace HDMI1 here with whatever it got named.

xrandr --verbose --addmode HDMI1 "1920x1080_65.00"

Then you need to actually set the mode. If after running this you see obvious glitches, revert quickly before your display is damaged. Good news is that on many panels, going ludicrously out of refresh bounds will just get you out of range errors on the display or in your xorg log (ie, my Asus IPS pannel probably is only rated for hdmi 1.2, so it can't go beyond 75hz refresh).

xrandr --output HDMI1 --mode "1920x1080_65.00"

If you encounter errors, remember you will probably need to specify the rate as well for your default modes, since most panels present multiple refresh rates and omitting may not pick the highest assumed rate.

xrandr --output HDMI1 --mode 1920x1080 --rate 60

But if it works, congratulations, you overclocked your monitor. You will have to add all the xrandr lines into an init script to run every boot, since it is a non-standard mode. I'm definitely going to be prioritizing good OC displays in the future, you can save some buck on that 120hz premium. I'd love to get an early 4k display that can support getting an OC to 90hz, since Displayport 1.3 can easily handle that.

1 comment:

  1. Thanks! This worked with my QNIX monitor with a AMD gpu.

    ReplyDelete