Legacy ImageMagick Discussions Archive

We're not inclined to support two codesets for each algorithm in the main development trunk, one for CPU's and one for GPU's. Instead we're looking for inline acceleration. OpenMP 4, for example, supports SIMD pragmas, something we're investigating now. Another problem is that ImageMagick 7 will be released in Beta soon. It includes support for variable pixel channels (see http://www.imagemagick.org/script/porting.php) which would mean another set of OpenCL codesets to support. That's 4 codesets for each image filter (v6 & v7, CPU & GPU). And as mentioned, OpenCL ports of the algorithms are available @ http://www.imagemagick.org/download/contrib/. It does not fully match the capabilities of the CPU version-- for example, the virtual pixel method setting is ignored. Its not in the main trunk but none-the-less they do work on GPUs. We might be inclined to support a few image filters in OpenCL in the main trunk. Convolution is supported now. Distortion is probably a candidate.

Intel has released an OpenCL SDK that supports both GPU and CPU acceleration (Intel CPU ).
So, I would propose a more radical approach: switch over entirely to OpenCL and benefit
from both GPU and multi-core CPU with a single code base. OpenCL kernels can be compiled at runtime
for a specific platform, so configuration could decide which platform to target at runtime.
Of course, to get the most out of a given platform, once needs to tune the code for that platform,
but that could be done by contributors in their own forks, I suppose.

Also, since OpenCL is a small extension of C99, it would be quite easy to use the same kernels to run
on a platform that doesn't support OpenCL, using good old C.