I'm looking for a good OpenCL wrapper\library for Python, with good documentation. I tried to search some... but couldn't find one good enough.
4 Answers
The most popular and best documented option seems to be PyOpenCL. It claims to be a complete wrapper for OpenCL and the documentation looks good.

- 75,757
- 21
- 156
- 151
-
Ow. tnx.. it seems that i were downloading PyOpenCL not from official site.. and that's why i didn't find documantation for it... – obenjiro Oct 31 '10 at 18:17

- 258,201
- 41
- 486
- 479
-
CLyther is far more immature than PyOpenCL, although the documentation looks excellent. – Rafe Kettler Oct 31 '10 at 16:01
pycl is a ctypes binding to OpenCL (hosted on bitbucket)
Its primary goal is simple: wrap OpenCL in such a way that as many Python implementations can use it as feasible. It is currently tested on CPython 2.{5,6,7}, 3.2, and PyPy 1.5. It is known to largely not work on Jython, whose ctypes library is still immature.
To achieve this, we eschew extension modules and dependencies outside of the standard library. Ideally things like NumPy arrays and PIL images should Just Work, but they shouldn't be required
It's currently pretty new. I've been playing with it recently and it's working nicely. Not done timings compared to PyOpenCL, but the performance appears to be perfectly reasonable
I didn't work for me with OS X 10.6's OpenCL 1.0 (and an AMD Radeon 5870, see here), but works perfectly under 10.7 and OpenCL 1.1
As for documentation, it's a fairly direct bindings to the C libraries, so any documentation those will apply. Also "Adventures in PyOpenCL" is good, and applies to almost all bindings

- 165,801
- 69
- 278
- 343
We are developing opencl4py, higher level bindings. This project uses CFFI, so it works on Pypy.
The major issue we encountered with pyopencl is that 'import pyopencl' does OpenCL initialization and takes the whole virtual memory in case of NVIDIA driver, preventing from correct forking and effectively disabling multiprocessing (yes, we claim that using pyopencl disables multiprocessing at least with NVIDIA). opencl4py uses lazy OpenCL initialization, resolving this "import hell".
Later, it gained some nice features like super easy binary program caching, etc. Unfortunately, the documentation is somewhat brief. The best way to learn how it works is go through the tests.

- 2,235
- 21
- 18
-
PyOpenCL author here. The most sense I can make of your statement is that opencl4py does not load libOpenCL.so at import time. If that's an issue (as you're claiming), then why not import PyOpenCL exactly where it's needed? Not sure I understand your motivation here. – Andreas Klöckner May 05 '14 at 15:33
-
As a further comment, PyOpenCL has a [cffi branch](https://github.com/pyopencl/pyopencl/tree/cffi) that can launch kernels and works on PyPy. It's not quite ready for prime-time, but it's getting there. – Andreas Klöckner May 05 '14 at 15:33
-
Our application has dozens of modules which use OpenCL and delaying the import makes the code very error prone. Each time someone imported pyOpenCL "earlier than he should" led to very hard to debug and diagnoze errors... sometimes :) And of course it could work with non-NVIDIA OpenCL devices on a developer's machine. – markhor May 05 '14 at 16:01
-
In spite of the fact that opencl4py API currently looks similar to pyOpenCL's, we are planning to rethink it, basing on our prevoius experience. – markhor May 05 '14 at 16:05