PyOpenCL in main!

Yesterday (2014-05-26) my sponsor Piotr Ożarowski uploaded new version of PyOpenCL to Debian. Usually I can upload new versions of packages to Debian as I am Debian Maintainer. But this time it was very special upload. It was closing bug 723132, asking to move PyOpenCL from contrib to main. Because Debian contains free OpenCL implementations, Beignet and Mesa, one can run OpenCL programs using FLOSS code.

Moving package from contrib to main meant that PyOpenCL had to be removed from contrib, and uploaded anew to main. Thanks to Piotr for sponsoring it, and to FTP masters for accepting in from NEW, and dealing with all this removal/adding of package.

There is still work to do. Rebecca Palmer works on allowing for having all OpenCL implementations installed, which should lead for more experimentation and easier work with OpenCL but requires changes to many of the OpenCL-related packages. I’m also thinking about moving PyOpenCL to use pybuild, but this needs to wait till I have more free time.

Let’s hope that having PyOpenCL in main will allow for more people to find and use it.

GPGPU presentations in 2012

During the last three months I have given three presentations.

On September 16, during PyConPL 2012, I gave presentation “Asynchronous and event-driven PyOpenCL programming”. I have shown how to use events and queues to asynchronously call OpenCL code in Python and how this can help to use PyOpenCL in common programs, not only for scientific purposes.

On October 21 I gave presentation “PyOpenCL – unleash your GPU with the help of Python” at PyCon Ukraine 2012 in Kyiv. I started with short introduction to OpenCL and PyOpenCL and again tried to convince audience that GPGPU can be used in ordinary programs, especially with the help of PyOpenCL and its high-level features like reduction or parallel prefix scan.

The last of the presentations I gave was on November 12 at PyWaw 18. It was not programming-related presentation – I talked about PyCon Ukraine, my remarks, how it went, and so on.

During and after my talks at PyConPL and PyCon Ukraine I got questions related to GPU programming. Listeners were asking about debugging and profiling of code.  I also got some questions about performance differences between OpenCL and CUDA. One very interesting question was about existence of some library of kernels (either for CUDA or for
OpenCL) with the most common functions and computations. PyOpenCL contains some features (like mentioned reduction or prefix sum) but I have not heard about CPAN-for-GPGPU.  It might be a good concept though.

In summary, there was some interest in GPGPU, but during the time since my presentation I have not seen much new discussions on PyCUDA or PyOpenCL mailing lists. This means that either I am not so good speaker ( 🙂 ) or GPGPU is still considered niche topic.

PyOpenCL and PyCUDA in Debian Wheezy

Latest versions of PyOpenCL and PyCUDA packages (2012.1-1 in both cases) have reached testing; thanks to Piotr Ożarowski for sponsoring. Wheezy is frozen now, so there will be no new versions of PyOpenCL nor PyCUDA in the new stable; the only allowed changes now are bug fixes. There has been no serious errors detected in my packages so it looks like there is no need for 2012.1-2.

All my packages have been going through some changes recently. Both PyCUDA and PyOpenCL were removed from testing during Boost 1.49 transition as they were depending on old Boost 1.46. Neither PyOpenCL nor PyCUDA could be rebuilt automatically as they depend on non-free packages but it might change in case of PyOpenCL.

I have created Python 3 package for pytools. This allowed for creation of PyOpenCL Python 3 package; it required extracting headers to separate package with headers to allow for installation of both PYthon 2 and Python 3 versions. Unfortunately I forgot to put some metadata (Replaces and Conflicts fields) which was noticed by Andreas Beckman in bug #674000. I have fixed it. At the same time Patrick Matthai uploaded AMD 12-4 drivers with OpenCL 1.2 support and Andreas Beckman uploaded new OpenCL 1.2 headers. This allowed for compiling PyOpenCL with OpenCL 1.2 support.  Unfortunately NVIDIA does not support OpenCL 1.2, so I had to force dependency on AMD libraries.

Bug #673992 was initially created by Vedran Miletic as the request for clarification of this situation, but soon it was clear that using AMD ICD loader with NVIDIA libraries fails in some cases. Using mixed libraries worked on all machines I had access to, but failed on hardware of other PyOpenCL users. I do not know whether this was caused by new
NVIDIA hardware (GF114) or by new AMD APU, but PyOpenCL was crashing during initialisation. Fortunately Vincent Danjean uploaded ocl-icd-libopencl1 package just
about that time. ocl-icd-libopencl1 is free ICD loader which seems to be giving better results for heterogeneous libraries.  Now PyOpenCL can be build with only free software. It can also run with only free software, but it’ll not be useful, as it’ll not find any ICDs. But there is work on free ICD so let’s hope that it will be soon solved. When it happens I’ll move PyOpenCL to the main section of Debian. If you want to know more, Vincent Danjean wrote email describing situation of OpenCL in Debian.

Currently PyOpenCL depends on any package providing libopencl1:

  • ocl-icd-libpencl1
  • amd-libopencl1
  • nvidia-libopencl1.

It’ll not work reliably with current nvidia-libopencl1 though, as it requires OpenCL 1.2 – and nvidia-libopencl1 provides only OpenCL 1.1, as was notices in bug #682435.  I have decided to leave relaxed dependency (instead of forcing PyOpenCL to require ocl-icd-libopencl1) to allow for experimentation with different hardware and software configurations and to be ready for new OpenCL implementations which might be uploaded to Debian in the future. But if you have some problems please try free ocl-icd-libopencl1 before filling the new bug report.

There is still small problem with PyOpenCL though. When using ocl-icd as ICD loader and running tests on NVIDIA hardware it crashes on Image testing. I was not able to test it throughly and I am not sure what is the root cause of the problem.

PyCUDA is Python 3 ready, but I have not created Python 3 package because there are still problems with compiling kernels on Python 3. Current package has already been split into python-pycuda and python-pycuda-headers so now adding Python 3 support is only matter of enabling python3-pycuda package.

As for Ubuntu, it looks like PyOpenCL 2012.1-1 has already been uploaded for Quantal Quetzal. It looks like changes I made for Debian also were beneficial for Ubuntu. PyCUDA is seen by Ubuntu but only as foreign (Debian) package, not as a part of Ubuntu. I think it will be problematic to push PyCUDA into Ubuntu as it depends on NVIDIA CUDA toolkit which is not packaged for Ubuntu.  If someone reading this knows how Ubuntu process works, or how to contact people responsible for release, or maintainers of NVIDIA or AMD drivers, please let me know. I am open for proposals of changes which will not break Debian package and will make life of Ubuntu maintainers easier.

New PyOpenCL in Debian

Debian has now new version of PyOpenCL package (2011.2), thanks Piotr for sponsoring.  I have changed dependencies allowing to use non-NVIDIA OpenCL ibraries, closing #628702. There is still open Ubuntu bug, but Debian-Ubuntu package synchronisation should deal with it.

Popularity of GPGPU-related packages

While dealing with #628702 I have looked at metadata of different packages, including popularity of packages, gathered with popcon. Data used in the following analysis is from 2011-12-05. I have looked at following packages:

PyOpenCL is installed on 189 machines, used on 62 of them. PyCUDA is installed on 13 machines, used on 7. As for NVIDIA GPGPU, libcuda1 is installed on 1110 machines, used on 131, nvidia-libopencl1 is installed on 822 machines, used on 134. AMD OpenCL libraries (amd-libopencl1) are installed on 33 machines, used on 9.

AMD OpenCL libraries are not very popular because they were only uploaded into Debian with the last version of Catalyst drivers, two weeks ago. Much more people have installed GPGPU packages (libcuda1 and libopencl1) than are using it. Data for NVIDIA packages might be skewed in favour of libcuda1: nvidia-opencl-icd depends on libcuda1 and libnvidia-compiler which means that everyone who wants to use NVIDIA OpenCL libraries must install libcuda1 for OpenCL to work.

Although more people have installed libcuda1 (1110) than libopencl1 (822), similar number of people are using those packages (131 vs. 134). This might be caused by the package dependencies described in previous paragraph. About half of the people who are using libopencl1 are doing so through PyOpenCL – 134 active users of libopencl1 and 62 active users of python-pyopencl which depends on libopencl1.

There is definitely interest in both OpenCL and CUDA in Debian, although until recently we had only NVIDIA OpenCL libraries available in repositories. It will be interesting to see how introducing AMD OpenCL libraries and PyOpenCL allowing to use any OpenCL provider will change popularity of OpenCL and CUDA.

Hardware

To test OpenCL on AMD I have been using Forconn nT A3500. It is small machine with AMD Fusion architecture. It has two core CPU and ATI 6310 integrated in the same chip. I have not yet tested performance of it. It is interesting that Foxconn is producing hardware under their own name. It looks like they have learned how to do good hardware doing outsourcing, and now are competing on the global market (with quite nice products IMO). That’s feature of outsourcing, I guess.