Open source radeon, OpenCL, clover and some borked darktable...
by, 30-05-2014 at 01:08 AM (53718 Views)
So I've been delving into some OpenCL lately - and thats been going ok. I'm writing up some tutorials on getting into OpenCL with FPC too so keep your eyes peeled for that sometime. The 1st installment is a few formatting fixes away, the 2nd is still in LibreOffice for the next few days... But OpenCL has its uses on linux - darktable being my main usage case as I enjoy a spot of photography here and there and when it comes to RAW files and post production, having an ATI card do the lifting really pays dividends.
Unfortunately, the way things stand today Linux users must make a choice: To use AMD's proprietary FGLRX driver, enjoy OpenCL and mostly OK 3D performance and OpenGL compliance OR use the open source radeon driver that wont crash your kernel, kill pandas and provide you with what most developers consider 'useful opencl' but will provide you a usable amount of 2D acceleration. (The difference here is unbelievable. Firefox & FGLRX rank up a miserable 26RPM on psychedelic browsing but the open source radeon drivers ranks up a respectable 1,825RPM).
Having gotten into some OpenCL myself and found clover (the project aiming to bring OpenCL to the open source radeon driver) to be quite serviceable for basic OpenCL workloads I thought I might pull the source for darktable and build it myself to try it out.
Problemo numero uno: According to clover my 1GB of GDDR% on my ATI card has now shrunk to 0.192GB... Below the 0.2GB that darktable wants to even consider booting OpenCL support. No big deal, even if its hard coded its a line of C to change. A line later I have darktable going a bit berserk about how it doesn’t like clover. Allegedly it can't compile an OpenCL kernel... Fishy. In truth, I'd previously brought this up on the darktable dev's IRC channel, the reply ws - FGLRX sucks but just works, clover doesn’t exist. It flat out wont work. So would someone explain why the FPC OpoenCL bindings can compile kernels and run them at sizeable speed?
Wondering if this wasn't a case of bad FGLRX code ignoring errors and telling darktable everything is okay when it wasnt (even FGLRX used to not like some things darktable tried to do at times and would kindly lock-up X or hang the kernel to the point where I was recalling how Raising Elephants IS Utterly Boring while contorting my fingers across my keyboard).
So out of curiosity I took out all the error checking code in the darktable source that could cause it to give up and give the workload to the CPU. The results were interesting to watch the tsunami of warnings GCC was only too delighted to flood the build log with. Booting up darktable again it too had decided to develop a rather serious case of verbal diarrhoea... But interestingly, I didnt get failures for everything. Just most things. The results of a few builds and a couple dozen minutes of fiddling? Well - its better than the blank screen I started with though I suppose its not quite there yet. Can you guess which is CPU rendered?
As an aside - yes the open source radeon driver is actually better day to day than the FGLRX mess (that you sometimes have to unzip and edit by hand before installing to get it compile a valid DKMS module for your newer than AMD wanted kernel) and the patterns change a bit based on what you do to the image... You can even see an almost-image when it demosaics at times before it aplpies anything else and spits out the results you see before you. SO - perhaps some OpenCL works and some doesn't. Guess I have something to do this weekend It also seems as though compiling with OpenMP support yields something like a 40% performance bump... Why this isn't how the builds come by default I literally have no idea...