Friday, October 4, 2013

Minimal Headless OpenCL + cgminer on Ubuntu 13.04 Server

UPDATE 2015-05-12: This guide hasn't been touched in a really long time. It'll probably still work if you use the actual versions of everything listed, but no guarantees. I've noticed that Catalyst 14.12 has a "minimal" video driver now along with a "graphics accelerators devel files" download. Needless to say, the situation seems to have changed for the better, but I haven't needed to do any new OpenCL setups, so I don't know what's involved. If you've landed on this page from a search engine, I would suggest searching for a more up-to-date guide. Unfortunately, I do not have any recommendations at this time.


Purpose of this Guide
I'm going to explain how to set up a minimal number of X dependencies required to run cgminer on Linux with AMD GPUs. This also potentially applies to other OpenCL tasks too.

Why is this Needed?
AMD makes decent Windows drivers, but unfortunately, AMD's proprietary Linux drivers are not very good. In order to do OpenCL, you must have some sort of X server running*.

*Update: there is a way to modify the drivers so that an X server isn't required:
I could not get it to work, but one of the commenters reported success (but only with errors and no ADL)

I'm going to assume you've got a headless server with SSH access and that you've just done a default install of Ubuntu Server 13.04 64-bit.

Note about Ubuntu Desktop vs Ubuntu Server:
It's very likely that the instructions in this guide will not work with Ubuntu Desktop without a few modifications. This guide will install xdm and assume it's set as the default, but if you already have a graphical environment, you probably already have a display manager installed (probably lightdm).

Also, there have been varying levels of success with different software versions. Some combinations of fglrx and the APP-SDK result in 100% CPU usage, or just don't work at all.

Update the Server
It's very important that you run apt-get update otherwise the buildpkg may fail later. Also, upgrading now is a good idea unless you want to experience the pain of upgrading a kernel with fglrx right away.
sudo apt-get update
sudo apt-get dist-upgrade
sudo reboot

Download and Install the Drivers
Download the latest fglrx drivers (I'm using 13.8 beta in this guide):
(note: at least one commenter reported problems with the latest drivers. If you need 13.8 specifically, see Patrick's commentuse "wget --referer=""" to download because AMD blocks direct links)
(note: if you have an R9 290 or one of the other newer GPUs, please see this comment, there are several people having trouble with the newer cards, you might need to install a graphical environment first and run the manual installer rather than building a package)

Install Some Necessary Packages
sudo apt-get install dh-make dh-modaliases execstack libxrandr2 libice6 libsm6 libfontconfig1 libxi6 libxcursor1 libgl1-mesa-glx libxinerama1 libqtgui4 unzip

Extract the Installer
chmod +x

Build the fglrx .deb Packages
./ --buildpkg Ubuntu/raring

(replace "raring" with the code name for your version according to "lsb_release -c")

Install fglrx
sudo dpkg -i fglrx*.deb
sudo apt-get -f install
sudo reboot
(it'll fail the first time, complaining about dependency problems; running apt-get -f install fixes it)

If you have multiple GPUs and want to run all of them, you might have to run something like: Update: it looks like this step is required. You can also run "aticonfig --list-adapters" if you'd like some extra information.
sudo aticonfig --initial --adapter=all

Install the APP SDK
Next, you'll need AMD's APP SDK:

Extract the APP SDK
tar xvf AMD-APP-SDK-v2.8.1.0-lnx64.tgz
sudo ./
sudo reboot

(you can do this in another directory if you want, these things produce lost of junk files)

Install the Minimum Required X Server Packages
sudo apt-get install xdm xorg

If you have a screen hooked up, you'll see an ugly XDM log in prompt. Don't use it (unless you install openbox or something). If you need console access to your server, switch to tty1 (ctrl+alt+f1).

Disable Authorization on xdm
(if you know of a better way to do this, please tell me...)

sudo nano /etc/X11/xdm/xdm-config

find the line
DisplayManager*authorize:       true

and make it
DisplayManager*authorize:       false

Save the file and reboot
sudo reboot

At this point, I'd recommend making sure xdm is actually running.

Compile cgminer and Test
Even if you don't plan to mine crypto-currencies, running cgminer is a good way to make sure stuff works. If you just want to run your own application, take a look at the cgminer sh towards the end and modify it to your needs.

Install Git
sudo apt-get install git

Download cgminer
git clone -b 3.7
Update: It looks like cgminer 3.7.2 is the last version to support GPU mining (see: Thank you to the Anonymous poster in the comments for this.

Alternatively, you could try sgminer, a scrypt-only fork of cgminer 3.7.2 with new bug fixes, as suggested by an anonymous comment.

Download AMD ADL SDK (for temperature monitoring, fan control, etc)
cp include/* ./cgminer/ADL_SDK/
(you might want to do this in a temporary directory as the ADL zip has a bunch of other stuff that it extracts into the current directory)

Install the packages we'll need to compile cgminer
sudo apt-get install build-essential autoconf libtool libcurl4-openssl-dev libncurses5-dev pkg-config libudev-dev

Compile cgminer
cd cgminer
./configure --enable-opencl --enable-scrypt
Update: It seems that I now have to add --enable-opencl to compile on 3.7.2
Note: you only need "./configure" (without any options) if you're using sgminer

Make sure you see the following after configure:
OpenCL...............: FOUND. GPU mining support enabled
scrypt...............: Enabled
ADL..................: SDK found, GPU monitoring support enabled

If everything looks good, compile

Testing cgminer (or other OpenCL applications)
You'll need to set some environment variables to run OpenCL applications. I recommend you start them with a bash script like the following:
export DISPLAY=:0
./cgminer -n

Save it as something like "" and "chmod +x"

(note: in some cases, you may need to run the script as root)
When you run it, you should get something like:
 [2013-10-04 22:46:09] CL Platform 0 vendor: Advanced Micro Devices, Inc.                    
 [2013-10-04 22:46:09] CL Platform 0 name: AMD Accelerated Parallel Processing                    
 [2013-10-04 22:46:09] CL Platform 0 version: OpenCL 1.2 AMD-APP (1214.3)                    
 [2013-10-04 22:46:09] Platform 0 devices: 1                    
 [2013-10-04 22:46:09] 0 Tahiti                    
 [2013-10-04 22:46:09] GPU 0 AMD Radeon HD 7900 Series hardware monitoring enabled                
 [2013-10-04 22:46:09] 1 GPU devices max detected

If everything worked (hopefully it did, because if not, the suffering starts now), you can now run OpenCL applications. Yay!

If you found this guide helpful and want to donate:
LTC -- LQNDRwrk9H6nwU88Ka87XPqfiJ9AAqdxJR

Issues / Troubleshooting

If something in this guide didn't work for you, please leave a comment with your operating system and driver version. I ran through this guide start to finish on a fresh install on my hardware and it seemed to work, but I only have a 7950 to test.

Some people are having issues with R9 290s. It looks like there are problems getting cgminer to see the newer hardware in some cases. I don't have any new hardware to test unfortunately, but I linked a few of the comments above, it seems a few people managed to figure it out.

Also, since GPU mining isn't supported in the newer cgminer releases, this guide may no longer work when AMD releases new hardware.

Run cgminer at Boot with rc.local and screen

This is a simple workaround to get cgminer running at boot and allow you to see it when you log in remotely later. These are not complete instructions, but hopefully they might help.

First, install screen if you haven't already:

sudo apt-get install screen

If you use a script like my script above to start cgminer already, then take note of where that is located. Create a different script somewhere accessible (mine is ~/ in my home directory) and add this:

cd /home/yourusername/cgminer/
(of course replace "yourusername" with your name, and "" with whatever script you use to start cgminer)

Then add something like this to your rc.local

/bin/su yourusername -c "/usr/bin/screen -dmS test bash -c '/home/yourusername/; exec bash'"

To test, log in as the root user "sudo su" and run "/etc/rc.local". Exit the root user, and run "screen -r" and see if cgminer is working. To detach from screen, type Ctrl+a then type 'd' key. Then try it after a reboot.

Alternatively, one commenter mentioned using crontab, which may be better than the rc.local method.

Run "crontab -e" (as a regular user, not root) and add something like the following:

@reboot cd /home/yourusername/cgminer && screen -dmS test bash -c '/home/yourusername/cgminer/; exec bash'

That seemed to work for me. Probably a better solution since it doesn't require root.

Saturday, August 24, 2013

force anti-aliasing on open-source radeon driver

This isn't radeon specific of course, but users of the radeon driver might be interested.

If you're using the open source radeon driver on Linux, you can force multi sample anti-aliasing on for 3D applications with this command:


(2 refers to the sample count, and can be increased)

Please see for more details.

Saturday, May 25, 2013

vsync test videos

I got tired of using actual videos to test the vsync on my video cards. So, I created these simple video test clips that should help you determine if your video setup is in good shape.

These test videos feature a 30x1080px white square that moves across the screen in 0.25, 1, or 4 seconds, depending on the video you choose. They are at 60 FPS, so they're ideal for test 60Hz displays (or anything divisible by 60).

To test, run the video in full screen and look for the following:
  • The white rectangle should stay whole and not be torn apart as it moves across the screen
    • If it's tearing up randomly on all or part of the square, then vsync probably isn't working
    • If it's solid, then vsync is probably working
    • If it's a well defined tear on only the first 10px or so, well, it's a bit more complicated, and I don't have an answer as to why, but it probably can't be fixed by configuring vsync.
  • The white rectangle should not flicker
    • If it stutters, or just doesn't move smoothly across the screen at a consistent pace, then either the system, GPU, or driver can't keep up
      • AMD catalyst on Linux tends do this if TearFree is enabled
  • The white rectangle should remain (mostly) solid
    • It shouldn't be blurred too much, a little is okay, and is probably just ghosting on the display, and not the video card's fault, but make sure to check if any motion blur or similar filters are enabled.

Download Links:

vsync test 4 second intervals 1080p, 60 FPS (recommended test):

vsync 0.25 second interval 1080p@60 FPS:!Z4EQhApL!C-a-xS4CP04DrpynlayZnV_w41cz_PRiKNdGcccG6JE

vsync 1 second interval 1080p@60 FPS:

hysnc 1 second interval @60 FPS: (if you have a rotated monitor, you'll need to test with this I think)

(I also have 24000/1001 (~23.98 FPS) and 30 FPS test videos too, but only use these if you know what you're doing):

vsync 1s interval 1080p@23.98 FPS:!Bp9TnYaI!f-GtcVr97QV6ulOqE08mcmnmY-R7YVyLL-ZN11s7iKc
vsync 4s interval 1080p@23.98 FPS:
vsync 1s interval 1080p@30 FPS:
vsync 4s interval 1080p@30 FPS:

Wednesday, January 30, 2013

Disable Phantom VGA1 Output in Linux on Intel DZ77BH-55K

In a previous post, I detailed my problem with this board in Linux. There's also an Ubuntu Bug Report about this issue
I have a new Intel DZ77BH-55K motherboard with an i5-2400 processor with on-chip HD graphics. The motherboard has one HDMI and one DisplayPort output. For testing reasons and on the search to solve the problem I have connected both outputs to my EIZO EV2333W 23-inch 1920x1080 (16:9) monitor (HDMI to DVI via adapter, DisplayPort to DisplayPort), but I have the same problem when the DisplayPort cable is not connected.
The problem is that if the computer boots up and shows the login screen the login screen appears with 1024x768 resolution and not with the monitor's native 1920x1080. The driver is actually the intel driver (no fallback to VESA). After login I can correct thedisplay to 1920x1080 with the "Displays" section of the System Settings and this persists when I log out an log in again, only the login screen and the desktop of every new user stays 1024x768.
The problem seems that there are more than the two (HDMI and DisplayPort) displays reported by the driver, according to the xrandr output. Especially there is a "VGA1" display always considered as connected and with max resolution of 1024x768. This seems to somehow determine the default resolution, probably because the standard multi-monitor mode is mirroring and due to the VGA1 ghost display also a system with one monitor and one monitor cable is already in multi-monitor mode.
It looks like it's an issue with the kernel:
Ok, till we have evidence to the contrary I'll shrug this off as a hw bogosity ... crt detection is a funky business and we get way too much hate-mail from people because every time we touch it we break something. So I prefer not to touch it. Since you can easily work around the issue with xrandr, shouldn't be to horrid.
One way to fix it is with xrandr:
xrandr --output VGA1 --off

But your display manager will need to be appropriately updated, unless you're just using it on a per-user basis...

The other solution that was posted was adding  the option: "video=VGA1:d" to the kernel.
This didn't work for me however. You might want to try it, but I think I think that parameter is incorrect (see below).

On the Gentoo Wiki, in an article about nouveau, they discuss how to disable incorrect or phantom outputs. Look in /sys/class/drm for a list of outputs.

It turns out, I had an output that was labeled as "card1-VGA-1". The wiki says remove the "card1-" and you're left with "VGA-1". Then add this option to the kernel:

The difference, being, of course, the dash. The kernel names stuff slightly differently I guess. This option worked for me, and although xrandr -q still detected a VGA1 output, it finally said that it was disconnected (like it should be, since it doesn't exist).

Hoping this is fixed automatically some day. But the bug is marked as "RESOLVED WONTFIX". Grrr.

Still having lagging/microfreezing with the Intel HD graphics, but it's one step closer.

Friday, October 26, 2012

Kubuntu 12.10 No Menubars in GTK?

Today, when I launched Audacity on my Kubuntu 12.10, I was greeted with a window with no menubar for File, Edit, etc. It reminded me of how there are no longer menubars in a lot of Windows apps.

No menu bars... where'd they go?
I thought about it a bit, trying to figure out why this happened. The conclusion I came to was that this must be the result of some change in Ubuntu 12.10 related to Unity...

Image from:
Notice how Ubuntu integrates the menu bars from GTK applications into Unity?
In Ubuntu, apparently, in order to make menu bars show up in Unity instead of the application's window, they export the menus through DBus. This makes sense for Ubuntu, I guess; it's part of the reason why I never really liked the whole Unity thing.

However, the menus don't show up anywhere obvious in KDE:
After a quick Google search, I found one possible solution. There is now a KDE widget that does the same thing as Unity's menu-bar-stealing-system.

Huh, this is new...
Well, my menus are there... but YUCK!
Surely there must be a better way... thankfully, the fix is extremely easy.

How To Fix It

Simply uninstall appmenu-gtk and appmenu-gtk3. Restart your apps, and your menus will be back!

sudo apt-get remove appmenu-gtk appmenu-gtk3

If I had to guess, GTK apps must install these packages by default since that's what they'd need in Ubuntu. However, these packages are just dumb for KDE users. Thankfully, the fix is very easy.

I hope this is a bug and not a feature. If Ubuntu starts to deviate so much to make Unity run, I hope Kubuntu/Xubuntu won't suffer. If they do, Ubuntu will lose even more users than it already has. Not that there aren't good alternatives, Mint Debian is continually getting better. And Fedora's not bad, I just like the Advanced Packaging Tool (APT) much better than any alternatives.
Unity has had this feature for longer than just 12.10 though. Anyone know why this suddenly became a problem in 12.10?

Thursday, October 18, 2012

Why I Like Buckling Springs over Cherry MX Switches

If you're into mechanical keyboards, you almost certainly are familiar with Cherry MX Switches, they're the most popular these days. Especially MX Blues...

Personally, I prefer the buckling springs on the old IBM clicky keyboards.

Don't get me wrong, I think Cherry MX Blue switches are great, but I still think buckling springs are better.

The thing I don't like about Cherry tactile switches is that there is a noticeable "bump" on the release of a key.

This effect is nearly absent (in fact, it's slightly the opposite effect, it feels more like a springy pop) with buckling springs.

This is visible in the force diagrams.

Cherry Switches. MX Blue (and Brown) switches have a noticeable drop in force on the return, this results in a noticeable bump in the return of the keypress. It has the opposite feeling of the Buckling Springs' return path.
Buckling Springs. Notice how the return path is almost completely smooth? It actually jumps up a little near the end of the return of the key press.

As you can see from the two diagrams, the feel of the key return is completely opposite on the Cherry tactile switches versus the IBM buckling springs. The actuation is fairly similar though.

This is the main reason I don't like MX Browns, I'm not really a fan of the tactile feel of Cherry switches... I do like MX Blues, but mainly because I like the clicking (even if I can't hear it with headphones). It's been awhile since I've used Browns though, so, perhaps I wouldn't notice a huge difference between blues and browns if I can't hear the click. All I remember was that I originally thought Browns and Blues were the same, except for the noise, but I remember them feeling different when I tried them...
Also, the actuation force is too low on MX Blues for me... would love to see some keyboards with MX Greens (basically, MX Blue switches with MX Black springs), but they don't exist.

Either way, bucking springs are better.

Saturday, October 6, 2012

Kubuntu: Line In Hardware Passthrough

If I record music through Line In, I also want to be able to listen to it in real time while recording.

I don't want to use additional hardware splitters or software playthrough in Audacity (which has high latency). In Windows, I would normally enable playthrough for Line In through Control Panel or through the driver software for my soundcard. However, I couldn't find an easy way to do it through kmix. I eventually found that alsamixer will do what I want, and it's an easy enough fix.

Open a terminal, type "alsamixer".
Using the arrow keys, scroll right to "Line", hit "M" to unmute, and press Up until the volume is at its maximum. You should now hear all input through Line In immediately on your speakers.