When building Debian packages, I noticed few issues. Those are not even
(they do not prevent building) but some tools complain about them.
It has #! only as third line - first two are "from __future__ import ...".
Can you fix that?
2. pyopencl/scan.py contains copyright pointing to Thrust at
While URL still contains source code, it is now archival - i.e. it has old
Would it be better to point to Thrust at GitHub:
(similarly for PyCUDA)
3. NDArray (from compyte) has some non-Python3 code:
ncl/compyte/ndarray/test_gpu_ndarray.py to test_gpu_ndarray.cpython-35.pyc
print shp, dtype, offseted, order1, order2
SyntaxError: Missing parentheses in call to 'print'
ncl/compyte/ndarray/gen_elemwise.py to gen_elemwise.cpython-35.pyc
SyntaxError: invalid syntax
Again - nothing critical (only test and dead-function code), but prevents
pre-compiling Python3 code.
Thanks in advance for fixing.
I would also be interested in making PyOpenCL self contained enough that it can be installed without any further dependencies, in particular no OpenCL implementation. Ideally, 'pip install PyOpenCL' would just succeed no matter what. Pocl seems like a reasonable vehicle for that. The problem is that it has a nontrivial build system... And then there's LLVM... It feels like a substantial amount of engineering effort.
Another avenue I explored for a bit was a conda package. I even got to the point of making that work. I can dig those package recipes up if you're interested. I believe I also put them up on github. For those I did the thing that you asked about, which is link PyOpenCL directly to pocl.
Hope that helps, and let me know if you'd like to try and work together to engineer something.
Am 18. Mai 2016 03:16:04 GMT-05:00, schrieb Marmaduke Woodman <mmwoodman(a)gmail.com>:
>I'm curious if anyone has succeeded in building and using PyOpenCL,
>directly to the Beignet or PortableCL runtimes?
>In my case, I'm writing a library using PyOpenCL, and it would be
>fall-back on such an alternative, if the user of my library does not
>an OpenCL installation such as Intel's or Nvidia's.
>PyOpenCL mailing list
I am not quite getting the function of the event system together with
I want to enqueue a non-blocking copy function which returns an event
for a kernel to wait on:
wev1 = cl.enqueue_copy(IOqueue, device_image, host_image,
is_blocking=False, origin=(0,0,0), region=host_image_shape)
Both queues are defined as OoO queues in the same context on the same
In my profiling I can see the start of the kernel, before the copying is
finished. Does that mean, I have to use blocking copies,
or am I doing something else wrong?
Thanks for any help
Elliot Gorokhovsky <elliot.gorokhovsky(a)gmail.com> writes:
> If I have multiple devices in my system, will elementWise automatically
> split the work between them? If not, what's the cleanest way to map over
> multiple devices?
What you might be able to do is create a context spanning both devices,
slice the vector, and then run the elementwise kernel on both
pieces. Whether or not what the implementation does in that case is
efficient is another question. If not, then you really have to do more
work by doing the partitioning manually.