PyOpenCL July 2011

pyopencl@tiker.net

18 participants
44 discussions

by Ian Johnson

Hello all, I finally bit the bullet and got radix working in PyOpenCL :) It's also improved over the SDK example because it does keys and values, mostly thanks to my advisor. Additionally this sort will handle any size array as long as it is a power of 2. The shipped example does not allow for arrays smaller than 32768, but I've hooked up their naive scan to allow all smaller arrays. https://github.com/enjalot/adventures_in_opencl/tree/master/experiments/rad… all you really need are radix.py, RadixSort.cl and Scan_b.cl some simple tests are at the bottom of radix.py I hammered this out because I need it for a project, it's not all that clean and I didn't add support for sorting on keys only (altho it wouldn't take much to add that, and I intend to at a later time when I need the functionality). Hopefully this helps someone else out there. I'll also be porting it using my own OpenCL C++ wrappers to include in my fluid simulation library at some point. I also began looking at AMD's radix from their SPH tutorial, but they use local atomics which are not supported on my 9600M -- Ian Johnson http://enja.org

8 years, 8 months

A new project using pyopencl

by Jan Tore Korneliussen

Hello pyopencl users, I have created a small project to explore declarative representations of OpenCL command graphs. It is implemented in python and relies on pyopencl and can be found here: http://code.google.com/p/ocl-cgraph-tools/ I think that an alternative representation of a command graph can be useful in many cases. * Can give the ability to move command graphs between dynamic language environments like PyOpenCL and real-time environments (which may be implemented in a compiled language). * One way to get more dynamic runtime behaviour for compiled OpenCL applications. * Generation of host API C-code from a command graph. * Store traces of programs which are using the OpenCL API. * Intermediate format for autotuning/profile based optimization tools. * Visualization of command graphs. The syntax I have invented here must of course be seen as experimental and is deliberately low-level to match the API. It is not given that a universal low-level syntax is the best way to represent problems, maybe each domain rather could use its own more high-level kernel graph syntax. Numpy expressions "compiled" to OpenCL would be an example of this. I would be grateful for any feedback on this. Does such a mini-language has its place? What would it take to make it useful? Regards, Jan Tore Korneliussen jtkornel(a)yahoo.no +47 952 13 672 Schweigaards gate 92 0656 Oslo

9 years, 1 month

Typo in definition of DTYPE_TO_CHANNEL_TYPE_NORM

by Jan Tore Korneliussen

In pyopencl.py the definition is DTYPE_TO_CHANNEL_TYPE_NORM = { np.dtype(np.int16): channel_type.SNORM_INT16, np.dtype(np.int8): channel_type.SNORM_INT8, np.dtype(np.int16): channel_type.UNORM_INT16, np.dtype(np.uint8): channel_type.UNORM_INT8, } I suppose the numpy dtype associated with UNORM_INT16 is wrong and that it should be: DTYPE_TO_CHANNEL_TYPE_NORM = { np.dtype(np.int16): channel_type.SNORM_INT16, np.dtype(np.int8): channel_type.SNORM_INT8, np.dtype(np.uint16): channel_type.UNORM_INT16, np.dtype(np.uint8): channel_type.UNORM_INT8, } Regards, Jan Tore Korneliussen jtkornel(a)yahoo.no +47 952 13 672 Schweigaards gate 92 0656 Oslo

9 years, 1 month

all_kernels method on Program class

by Jan Tore Korneliussen

Hello, I can not find the all_kernels() method on the Program class, which is mentioned in the docs. I am looking at the latest git version now. Is it deprecated maybe? I would think it could be implemented if all kernels are pre-created with clCreateKernelsInProgram instead of created on the fly in the attribute lookup like it is done now (?) I do not have immediate need for this functionality, but it is not so hard to think of use cases, for instance programming tools or GUIS which needs programmatic access to the available kernels in a program. Regards, Jan Tore Korneliussen jtkornel(a)yahoo.no +47 952 13 672 Schweigaards gate 92 0656 Oslo

9 years, 1 month

Re: [PyOpenCL] Endless loop in PyOpenCL 2011.2 caching system

by Eli Stevens (Gmail)

On Sat, Jul 30, 2011 at 3:35 AM, Sebastian Nowozin <nowozin(a)gmail.com> wrote: > h_F0 = np.zeros(dims, dtype=np.float) > d_F0 = cl.Buffer(context, cl.mem_flags.READ_WRITE | > cl.mem_flags.COPY_HOST_PTR, hostbuf=h_F0) > d_PRN = cl.array.zeros(queue, dims, cl.array.vec.float4) I suspect that numpy.float isn't the size you're expecting: >>> import numpy >>> numpy.dtype(numpy.float).itemsize 8 I can't say for certain, but I think that it's that way to match the python "float" definition, which is 64-bit. Does the program behave as expected if you change np.float to np.float32? HTH, Eli

9 years, 1 month

Re: [PyOpenCL] Endless loop in PyOpenCL 2011.2 caching system

by Andreas Kloeckner

On Fri, 29 Jul 2011 22:00:53 +0100, Sebastian Nowozin <nowozin(a)gmail.com> wrote: Non-text part: multipart/mixed > Hello, > > I am having trouble with the PyOpenCL compile caching system once > again. The attached program should reproduce the issue, and an error > log is included in ERROR.txt. Fixed in git. > A related issue described in the included README file is that I have > so far failed to use the ranluxcl library with PyOpenCL, whereas it > works for me from a C++ program. If you describe the specific issue (expected/observed behavior), maybe somebody on the list can help. Andreas

9 years, 1 month

Endless loop in PyOpenCL 2011.2 caching system

by Sebastian Nowozin

Hello, I am having trouble with the PyOpenCL compile caching system once again. The attached program should reproduce the issue, and an error log is included in ERROR.txt. A related issue described in the included README file is that I have so far failed to use the ranluxcl library with PyOpenCL, whereas it works for me from a C++ program. Thanks, Sebastian

9 years, 1 month

Re: [PyOpenCL] Question about get_build_info

by Andreas Kloeckner

On Fri, 29 Jul 2011 13:47:07 +0200, Petter Säterskog <petter.saterskog(a)gmail.com> wrote: Non-text part: multipart/alternative > 2011/7/28 Andreas Kloeckner <lists(a)informa.tiker.net> > > > On Thu, 28 Jul 2011 16:54:08 +0200, Petter Säterskog < > > petter.saterskog(a)gmail.com> wrote: > > Non-text part: multipart/mixed > > Non-text part: multipart/alternative > > > Hi! > > > I have tried to get a build log for my opencl programs to be able to see > > > warnings. I use the function prg.get_build_info on a built program prg. I > > > get the following error: > > > > > > return self.prg.get_build_info(dev,cl.program_build_info.LOG) > > > File > > > > > "/usr/local/lib/python2.6/dist-packages/pyopencl-2011.1.1-py2.6-linux-x86_64.egg/pyopencl/__init__.py", > > > line 436, in __getattr__ > > > "info attribute or as a kernel name" % attr) > > > AttributeError: 'get_build_info' was not found as a program info > > attribute > > > or as a kernel name > > > > > > I can succesfully use prg.get_info(cl.program_info.DEVICES). Does anyone > > > have an idea to what I am doing wrong? > > > > First of all, if there's anything in the build log, PyOpenCL should show > > it to you automatically. (also post-caching, if applicable) > > > > Second, whatever it does should be able to serve as an example for what > > you're trying to do: > > > > https://github.com/inducer/pyopencl/blob/master/pyopencl/__init__.py#L118 > > > > What version of pyopencl are you running? > > > > Andreas > > > > > My version is 2011.1 . The build log is printed when an error appears but I > would like to get it with the function mentioned in the documentation: > get_build_info , > http://documen.tician.de/pyopencl/runtime.html#programs-and-kernels > It seems as if the function doesn't exist? Whoops, you're right. This got lost while I added caching. Fixed in git. Thanks for the report, Andreas

9 years, 1 month

Re: [PyOpenCL] Question about get_build_info

by Andreas Kloeckner

On Thu, 28 Jul 2011 16:54:08 +0200, Petter Säterskog <petter.saterskog(a)gmail.com> wrote: Non-text part: multipart/mixed Non-text part: multipart/alternative > Hi! > I have tried to get a build log for my opencl programs to be able to see > warnings. I use the function prg.get_build_info on a built program prg. I > get the following error: > > return self.prg.get_build_info(dev,cl.program_build_info.LOG) > File > "/usr/local/lib/python2.6/dist-packages/pyopencl-2011.1.1-py2.6-linux-x86_64.egg/pyopencl/__init__.py", > line 436, in __getattr__ > "info attribute or as a kernel name" % attr) > AttributeError: 'get_build_info' was not found as a program info attribute > or as a kernel name > > I can succesfully use prg.get_info(cl.program_info.DEVICES). Does anyone > have an idea to what I am doing wrong? First of all, if there's anything in the build log, PyOpenCL should show it to you automatically. (also post-caching, if applicable) Second, whatever it does should be able to serve as an example for what you're trying to do: https://github.com/inducer/pyopencl/blob/master/pyopencl/__init__.py#L118 What version of pyopencl are you running? Andreas

9 years, 1 month

Question about get_build_info

by Petter Säterskog

Hi! I have tried to get a build log for my opencl programs to be able to see warnings. I use the function prg.get_build_info on a built program prg. I get the following error: return self.prg.get_build_info(dev,cl.program_build_info.LOG) File "/usr/local/lib/python2.6/dist-packages/pyopencl-2011.1.1-py2.6-linux-x86_64.egg/pyopencl/__init__.py", line 436, in __getattr__ "info attribute or as a kernel name" % attr) AttributeError: 'get_build_info' was not found as a program info attribute or as a kernel name I can succesfully use prg.get_info(cl.program_info.DEVICES). Does anyone have an idea to what I am doing wrong? Best Regards, Petter Säterskog

9 years, 1 month

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

PyOpenCL July 2011