Accéder au contenu.
Menu Sympa

starpu-devel - Re: [Starpu-devel] Building StarPU for OpenCL and Linux

Objet : Developers list for StarPU

Archives de la liste

Re: [Starpu-devel] Building StarPU for OpenCL and Linux


Chronologique Discussions 
  • From: George Russell <george@codeplay.com>
  • To: Cédric Augonnet <cedric.augonnet@inria.fr>
  • Cc: starpu-devel@lists.gforge.inria.fr
  • Subject: Re: [Starpu-devel] Building StarPU for OpenCL and Linux
  • Date: Wed, 23 Feb 2011 15:55:19 +0100
  • List-archive: <http://lists.gforge.inria.fr/pipermail/starpu-devel>
  • List-id: "Developers list. For discussion of new features, code changes, etc." <starpu-devel.lists.gforge.inria.fr>

Hi Cédric,

Some more feedback (still on the 0.4 release, atm)

The OpenCL support is assuming that the device to run on is a GPU, and this is hard coded into the StarPU OpenCL driver in _starpu_opencl_init

I don't believe this is necessary (or desirable). It should be possible to run OpenCL codelets on the CPU or on other OpenCL device classes (CL_DEVICE_TYPE_ACCELERATOR, CL_DEVICE_TYPE_CPU) which will allow running on the Cell SPUs or multi-core CPUs. I think its not impossible that, for some tasks, a vectorised CPU OpenCL codelet may outperform a scalar C codelet, for example; it may also allow another approach to StarPU on the Cell platform.

This is a slight obstacle for me at the moment, as in the Linux VM I don't have an OpenCL capable video card. Instead, I run the OpenCL code on the CPU (CL_DEVICE_TYPE_GPU)
instead, and this should work fine (tm). Sadly, it seems that the combination of StarPU 0.4, ATI Stream SDK, and the OpenCL on CPU tweak (just changing the device GPU->CPU in the setup) results in an infinite loop / deadlock in usage.

One further thing: The OpenCL kernels are compiled with the -Werror option. However, at least one of the kernels is using floating point constants without the F or f suffix. This is actually not allowed in OpenCL unless the fp64 (double precision floating point extension) is enabled via #pragma. Consequently, the AMD/ATI compiler raises a warning on this; the -Werror switch then results in a compile error when processing the OpenCL code.

Cheers,
George

On 22/02/2011 22:33, Cédric Augonnet wrote:
4D642B90.2060801@inria.fr"> Hi George,

This is actually possible to do that in the svn version with --with-opencl-include-dir=<path> and --with-opencl-lib-dir=<path>. Unfortunately, this is not in the released version, which makes it impossible to use ATI's OpenCL on window indeed.

Perhaps we need to backport some important modifications like that, or we should consider a new release...

Sorry for the trouble and thanks a lot for your feedback!

Cédric

On 22/02/2011 19:58, George Russell wrote:
4D640765.3040809@codeplay.com"> Hi,

It was easier to build StarPU 0.4 for Linux and OpenCL in a VM, just one note on the OpenCL side of things; the configure check assumes the OpenCL installation is in some directory specified in the configure, with a lib and include subdirectory.

For the ATI Stream SDK, the lib directory contains no files, just subdirectories, and so the OpenCL library is not found, and the build fails with undefined reference to the OpenCL API functions e.g. clCreateKernel.

Just moving the .so files etc to the lib dir (instead of lib/x86) makes the build succeed.

I think there is probably a need to decouple the location of OpenCL libraries and headers from the assumption of a fixed directory layout.

Cheers,
George
_______________________________________________
Starpu-devel mailing list
Starpu-devel@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/starpu-devel





Archives gérées par MHonArc 2.6.19+.

Haut de le page