Dear PYopenCL support,
I just started use Pyopencl, by following this tutorial:
https://www.google.ch/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwj…
(this is also my first time with GPU parallel computing)
I get some problems from the beginning:
- cl.get_platforms() gives me:
[<pyopencl.Platform 'Apple' at 0x7fff0000>]
- I tried also the 4 tests present in ~/pyopencl/test/
with this (summarised) results:
[cid:B50B9F37-3CFF-42F3-AFE3-0AE79FF6A7AB@unige.ch][cid:243B193F-4CFC-425A-AB78-4FD7DF16FD5F@unige.ch][cid:365CCB01-1182-435C-9819-C7C139280DFF@unige.ch]
[cid:F201F981-099F-4843-A497-A20D973447F2@unige.ch]
Do you need more details about the test-output?
thanks for help,
Gianrocco
Lazzari Gianrocco <gianrocco.lazzari(a)epfl.ch> writes:
> the mail I send below to the address failed…I didn’t know I cannot reply…
> anyway, I write here since I cannot attach files apparently in the forum
> http://post.gmane.org/post.php?group=gmane.comp.python.opencl&followup=2068
>
> and also, i don’t know how to reply from the mailing list to the same thread…
>
> anyway, here is the zip I was talking a bout in the previous mail
>
> thanks again…
> I hope I can get started quickly with pyopencl…and start soon run faster my simulations
>
> ...more question will come for sure :)
I looked through your attachment, and it seems like all the errors you
are encountering are issues and shortcomings with your OpenCL
implementations, rather than issues with PyOpenCL itself. PyOpenCL does
its best to try and work around these issues, but obviously that only
works up to a point. Upgrading your operating system to a newer version
of OS X will perhaps help with some of them.
In general it is true that running OpenCL code on OS X requires a little
more care than it does on Linux, so if you are looking for a more
seamless experience, I would perhaps recommend that to start out.
Andreas
Hi Bogdan,
thank you for your suggestions. I must admit I'd rather stick with using
high level functions coming with pyopencl or reikna. Writing my own
opencl kernels is a little out of reach for me. I'll deal with this when
I have more complex sub tasks to solve. That transposing thing of mine
works reasonably well and is still faster than padding on the host.
Newbie question: is it even possible that fancy indexing will work one
day on GPUs?
Thanks again...
Hi all,
recently I needed a way to zeropad a 2D array with pyopencl like
numpy.pad() does. Since changing array size only works in the first
dimension I came up with this:
concatenate old array with zeros <- in 1st dim
transpose new array <- flip dims
concatenate new array with zeros <- again in 1st dim
transpose again <- flip back dims
That works well with the Transposition() in Bogdan Opanchuk's Reikna
package. I only need to do a reshape() after each transposition.
With pyopencl's transpose() strides are also flipped so I can't carry
out the 2nd transposition (strides don't match). So here is my question:
How can I make use of transpose() when the result always has flipped
strides?
Also, can you think of a simpler way to zeropad in 2D? The array should
be padded symmetrically so that the old array is embedded in the center
of the padded array.
Thanks in advance...
Hi Benson,
What is the conflict you got between pyopencl and python2.7?
Can you show some detail?
I met one similar problem before and found the solution, I am not sure
whether you are confused by the same conflict.
The following is what I wrote to Andreas before, hope it helps.
PS. I like the idea to put pyopencl in conda, and install it in local directory.
Best regards,
longgang
Dear Andreas,
I have found the reason. It is something related to the unicode string used in the newer versions of python.
In order to use python3.3 and python 2.7 at the same time, I add the following line in my python code,
from __future__ import absolute_import, division, print_function, unicode_literals
however, the compile_options in cl.Program().build(compile_options)
can not be unicode strings for python version 2.7.6 and 2.7.8
I have fixed the bug by just remove unicode_literals from preamble such that the code can
run under both python 2.7 and 3.3. Thanks a lot!
Best regards,
LongGang
> On Oct 12, 2015, at 7:23 PM, Andreas Kloeckner <lists(a)weasel.tiker.net <mailto:lists@weasel.tiker.net>> wrote:
>
> Longgang Pang <pang(a)fias.uni-frankfurt.de <mailto:pang@fias.uni-frankfurt.de>> writes:
>> I have problem when run the most recent PyOpenCL2015 with python2.7.6
>> and 2.7.8
>> The full output is as following, looks like 'ArgumentError' has no
>> attribute 'what' for python version 2.7.6 and 2.7.8?
>> There is no problem when I run pyopencl with python/3.3.6 or python/2.7.10.
>>
>> Do you know how to fix it in the code without modifying pyopencl?
Hi!
Thanks so much in advance!
I have successfully installed pyopencl
with the configure.py variables --cl-inc-dir
and --cl-lib-dir set to my AMD app provided
headers and libraries.
But when I try to import pyopencl, it runs
into an ImportError importing _cffi, and
the exact output is
libOpenCL.so.1: cannot open shared object file: No such file or directory
I browsed through the pyopencl package
(it installed to my anaconda site-packages folder)
and I see a _cffi.py and a _cffi.so. The .py
is only a bootstrap loader for the _cffi.so file.
What isn't linked? I tried linking boost,
but the man for configure.py does not indicate that
boost-inc-dir or boost-lib-dir are viable options.
Thank you,
Michelle
Hi,
Seems to work on Fedora 23 with AMD APU and Python 3, though some errors
with dependencies for Python 2, get a conflict between Pyopencl and
Python2.7
Benson
On 1/5/16 7:00 PM, pyopencl-request(a)tiker.net wrote:
> Send PyOpenCL mailing list submissions to
> pyopencl(a)tiker.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.tiker.net/listinfo/pyopencl
> or, via email, send a message with subject or body 'help' to
> pyopencl-request(a)tiker.net
>
> You can reach the person managing the list at
> pyopencl-owner(a)tiker.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of PyOpenCL digest..."
>
>
> Today's Topics:
>
> 1. Packaging PyOpenCL in conda (Andreas Kloeckner)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 04 Jan 2016 17:38:19 -0600
> From: Andreas Kloeckner <lists(a)informa.tiker.net>
> To: pyopencl(a)tiker.net
> Cc: Aaron Meurer <asmeurer(a)gmail.com>
> Subject: [PyOpenCL] Packaging PyOpenCL in conda
> Message-ID: <87vb78syok.fsf(a)bolt.d.tiker.net>
> Content-Type: text/plain
>
> Hi all,
>
> I've just played around a bit with conda [1], a binary package manager
> by Continuum Analytics, with the goal of getting to the point of being
> able to say
>
> $ conda install -c inducer pyopencl
>
> to get PyOpenCL installed, or
>
> $ conda install -c inducer pyopencl-pocl
>
> to get a fully self-contained version of PyOpenCL (based on pocl [2])
> installed that should run anywhere, independently of whether any OpenCL
> anythings are already installed.
>
> The amazing thing is that this seems to at least somewhat work, at least
> work on the two Debian-based machines I tried it on. For now, this is
> *very alpha* and probably broken for anyone but me. Package recipes are
> here [3] and packages themselves here [4].
>
> If you're on 64-bit Linux, it'd be great if you could give this a try
> and report back.
>
> Andreas
>
> [1] http://conda.pydata.org/docs/index.html
> [2] https://github.com/pocl/pocl
> [3] https://github.com/inducer/ak-conda-recipes
> [4] https://anaconda.org/inducer/packages
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> PyOpenCL mailing list
> PyOpenCL(a)tiker.net
> http://lists.tiker.net/listinfo/pyopencl
>
>
> ------------------------------
>
> End of PyOpenCL Digest, Vol 76, Issue 1
> ***************************************
Hi all,
I've just played around a bit with conda [1], a binary package manager
by Continuum Analytics, with the goal of getting to the point of being
able to say
$ conda install -c inducer pyopencl
to get PyOpenCL installed, or
$ conda install -c inducer pyopencl-pocl
to get a fully self-contained version of PyOpenCL (based on pocl [2])
installed that should run anywhere, independently of whether any OpenCL
anythings are already installed.
The amazing thing is that this seems to at least somewhat work, at least
work on the two Debian-based machines I tried it on. For now, this is
*very alpha* and probably broken for anyone but me. Package recipes are
here [3] and packages themselves here [4].
If you're on 64-bit Linux, it'd be great if you could give this a try
and report back.
Andreas
[1] http://conda.pydata.org/docs/index.html
[2] https://github.com/pocl/pocl
[3] https://github.com/inducer/ak-conda-recipes
[4] https://anaconda.org/inducer/packages
