Converted NVIDIA RadixSort to PyOpenCL
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/r...
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
7 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 years, 1 month
