PyOpenCL February 2014

pyopencl@tiker.net

9 participants
16 discussions

Invalid command Queue when using big data sets on nVidia

by Justin Heinermann

Dear all, we are trying to implement a K nearest neighbor search on GPUs with PyOpenCL. The goal of the algorithm is: For a given target point, find the nearest points from a given set (training data). The distance between two points is computed by the squared euclidean distance. One of our implementations is a brute force approach, which aims at processing big data sets in parallel, e.g. 1 million training data and some millions of targets (test data). For every target point one kernel instance is created which finds the k nearest points out of the training points. Our problem is the following. Everything works fine for small data sets and the results are as expected on both GPU (GeForce GTX 650 with nVidia Driver 313.09.) and CPU(Intel Core i5-3450 with AMD APP SDK) running Ubuntu 12.10, PyOpenCL 2013.1-py2.7-linux-x86_64. But if we increase the size of the data sets, the GPU version crashes with the following error: > File "brutegpu.py", line 65, in query > cl.enqueue_copy(self.queue, d_min, self.d_min_buf).wait() > File "/usr/local/lib/python2.7/dist-packages/ > pyopencl-2013.1-py2.7-linux-x86_64.egg/pyopencl/__init__.py", > line 935, in enqueue_copy > return _cl._enqueue_read_buffer(queue, src, dest, **kwargs) > pyopencl.LogicError: clEnqueueReadBuffer failed: invalid command queue The CPU-Version still works fine with 1 million training points and 1 million of test points. Attached you can find the corresponding source code as working minimal example, which consists of on Host-Python-File and one OpenCL-Kernel-File. We would highly apprecriate any help - maybe we made a mistake which is already known to you. So the big question for us is: Why is it working on CPU and why isn't it working on the GPU? Are there nVidia-specific pitfalls for such big data sets? The compiler says: > ptxas info : Compiling entry function 'find_knn' for 'sm_30' > ptxas info : Function properties for find_knn > 0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads > ptxas info : Used 17 registers, 336 bytes cmem[0], 4 bytes cmem[3] Or are there any rules for using a kernel for big data sets such as setting the work group sizes or maximum memory usage? The error message "invalid command queue" is confusing and I wasn't able to find any helpful information (except that oftentimes "invalid command queue" means segfault, but i could not find any wrong array adress yet.) Maybe one of you could have a look at our code and finds some stupid mistake. We would be very grateful for every hint. Best regards, Justin Heinermann, University Oldenburg

6 years, 3 months

Problems with git repositories

by Tomasz Rybak

Hello. What's going on with PyOpenCL repositories? I cannot clone one on tiker.net: $ git clone http://git.tiker.net/trees/pyopencl.git Cloning into 'pyopencl'... error: unable to open object pack directory: /tmp/pyopencl/.git/objects/pack: Too many open files fatal: failed to read object bff987ecd9aca7f6b2e1dc8a86af7086ee9cbcc2: Too many open files At the same time repository on gitbut contains old revision, a2fb48462cf957590d2c9c6c8eb3776f781ca6b6 from Wed Nov 27 14:40:35 2013 -0600, while the one from tiker.net is a1d1603041ff90f3814dd263c33ee35c7de33ef9 from Tue Feb 18 12:01:10 2014 -0600. Short googling suggests the need to re-push or issuing git gc on repository. At the same time PyCUDA repositories seem OK. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak

6 years, 9 months

Profiling OpenCL ...

by Jerome Kieffer

Dear all, I wonder which profiler is mostly used by you developers ? Since the switch to cuda5, the nvidia profiler "compute-prof" has been replaced with "nvvp" which no more supports (py)opencl programs. Has anybody tested to generate PTX from OpenCL code and profile the corresponding PTX using nvvp ? Cheers, -- Jérôme Kieffer tel +33 476 882 445

6 years, 9 months

[JOB ANNOUNCEMENT] Software Developer permanent position available at ESRF, France

by Jerome Kieffer

Dear colleagues, The ESRF is looking for a Software Developer: http://esrf.profilsearch.com/recrute/fo_annonce_voir.php?id=300 Our ideal candidate would be experienced on OpenGL, OpenCL and Python. Best regards, -- Jérôme Kieffer Data analysis unit - ESRF

6 years, 9 months

Re: [PyOpenCL] Segmentation faults when using 'int_ptr' with other Python extension.

by Martin Rehr

Hi Bogdan, Thanks for the tip, I will take a look at the Reikna package. Cheers, Martin On 17/02/2014, at 11.03, Bogdan Opanchuk <mantihor(a)gmail.com> wrote: > Hi Martin, > > Thank you, but as an author of this package I'd prefer that people did > not mention it, and used Reikna instead (which is already featured in > PyOpenCL docs, thanks to Andreas). It incorporates pyfft functionality > and has some other useful stuff. > > On Mon, Feb 17, 2014 at 5:36 PM, Martin Rehr <rehr(a)nbi.ku.dk> wrote: >> >> On 16/02/2014, at 23.07, Andreas Kloeckner <lists(a)informa.tiker.net> wrote: >> >>> Brandon Amos <bdamos(a)vt.edu> writes: >>> >>>> Hi Andreas, >>>> >>>> >>>>> peb does not build for me: >>>>> >>>> I think this is from incompatibilities between Python 3.3 and Python 2.7. >>>> >>>> Regardless, I'm probably going to remove `peb` from github and >>>> just follow Gregor's gpyfft example for extending clblas. >>>> >>>> I don't know if this would benefit anybody else in the future, >>>> but a reference to Gregor's gypfft library in the >>>> "Interoperability with other OpenCL software" section in the documentation >>>> would have really helped me! >>> >>> Done: >>> >>> http://documen.tician.de/pyopencl/#software-that-works-with-or-enhances-pyo… >>> >>> Andreas >>> >>> _______________________________________________ >>> PyOpenCL mailing list >>> PyOpenCL(a)tiker.net >>> http://lists.tiker.net/listinfo/pyopencl >> >> Another FFT package worth mentioning is pyfft: https://pypi.python.org/pypi/pyfft it works with both PyCUDA an PyOpenCL >> >> Cheers, >> Martin >> _______________________________________________ >> PyOpenCL mailing list >> PyOpenCL(a)tiker.net >> http://lists.tiker.net/listinfo/pyopencl

6 years, 9 months

Re: [PyOpenCL] Segmentation faults when using 'int_ptr' with other Python extension.

by Andreas Kloeckner

Brandon Amos <bdamos(a)vt.edu> writes: > Hi Andreas, > > >> peb does not build for me: >> > I think this is from incompatibilities between Python 3.3 and Python 2.7. > > Regardless, I'm probably going to remove `peb` from github and > just follow Gregor's gpyfft example for extending clblas. > > I don't know if this would benefit anybody else in the future, > but a reference to Gregor's gypfft library in the > "Interoperability with other OpenCL software" section in the documentation > would have really helped me! Done: http://documen.tician.de/pyopencl/#software-that-works-with-or-enhances-pyo… Andreas

6 years, 9 months

Re: [PyOpenCL] Segmentation faults when using 'int_ptr' with other Python extension.

by Jerome Kieffer

On Sun, 16 Feb 2014 16:42:09 -0500 Brandon Amos <bdamos(a)vt.edu> wrote: > I don't know if this would benefit anybody else in the future, > but a reference to Gregor's gypfft library in the > "Interoperability with other OpenCL software" section in the documentation > would have really helped me! I was aware of this library and will test it as soon as I have some time. How does it compare with cuFFT/scikit.cuda ? did anybody benchmark ? Cheers, -- Jérôme Kieffer Data analysis unit - ESRF

6 years, 9 months

Is there 2014 release plan?

by Tomasz Rybak

Hello. I have question regarding potential dates of releasing new versions of PyOpenCL (and PyCUDA). Is there any plan? I'm asking as Debian Jessie will be frozen on 2014-11-05 which means that no new versions of packages will be accepted after that date. To be sure that there is no ugly bugs discovered at the last moment, I intend to upload latest version in October 2014. Andreas - is that OK with you? I can move upload earlier or later, but the latest day I can upload and be sure that this particular version reaches Jessie is 2014-10-22. Such late upload will be risky though. Best regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak

6 years, 9 months

Segmentation faults when using 'int_ptr' with other Python extension.

by Brandon Amos

Hi all, I'm really interested in the pyopencl project and on integrating with clBLAS [0], as discussed in a previous thread [1], and I'm currently working on building a Python C extension to use pyopencl objects with clBLAS. However, I'm very new to building Python C extensions, and I'm new to writing Python C extensions, and the interoperability documentation [2] mentions pyopencl objects contain `from_int_ptr()` and `int_ptr`, but unfortunately no examples are given. So, as a first step to help me learn about build a Python C extension to interoperate with pyopencl, and to help anybody else, I've created a project on GitHub [3] to show a simple usage. It's still very much a work in progress and needs a lot of cleaning. I'm sending this message to ask for help with a segfault I'm getting when calling `clGetContextInfo`. `example-usage.py` [4] shows the example I'm using to obtain a pyopencl context, queue, and buffer. The `int_ptr` fields are passed to `peb.c::peb_example_method()` [5], the context segfaults when passed to `clGetContextInfo`, which I added as a check because `clCreateProgramWithSource` was segfaulting. I've added `printf("Calling. %p %d\n", &m_context, m_context);` to `pyopencl::wrap_cl.hpp::context::data` to print the address and first 32 bits of the context that's being returned to python. Then, in `peb.c` I added `printf("%p %d\n", ctx, (int) ctx);`. This may be misleading, but the following output shows the memory addresses differing (red flag), but the first 32 bits being the same. [peb::example-usage.py] 0x1d722b8 [pyopencl::wrap_cl.hpp::context::data] Calling. 0x1b55130 30876344 1 2 3 [peb::peb.c::peb_example_method()] 0x1d722b8 30876344 For more information about my configuration, I'm using x86_64 Linux, the latest `pyopencl` from `git`, and the Intel OpenCL 1.2 SDK. I've seen a few posts on the `pyopencl` mailing list, so I hope this isn't an issue with the Intel SDK, because I can't easily develop on any other OpenCL device. Let me know if I can provide any more information. Thanks, Brandon. [0]: https://github.com/clMathLibraries/clBLAS [1]: http://lists.tiker.net/pipermail/pyopencl/2013-August/001573.html [2]: http://documen.tician.de/pyopencl/misc.html#interoperability-with-other-ope… [3]: https://github.com/bamos/peb [4]: https://github.com/bamos/peb/blob/master/example-usage.py [5]: https://github.com/bamos/peb/blob/master/src/peb.c

6 years, 9 months

Segmentation fault in pyopencl.image_from_array

by Jerome Kieffer

Dear Python/OpenCL community, I am pretty new (py)opencl and encountered a problem, maybe it a lack of understanding of openCL, but I found strange python seg-faults: test program: #!/usr/bin/python import numpy, pyopencl ctx = pyopencl.create_some_context() data=numpy.random.random((1024,1024)).astype(numpy.float32) img = pyopencl.image_from_array(ctx, ary=data, mode="r", norm_int=False, num_channels=1) print img System: debian sid: pyopencl2012.1 (the same code works with debian stable and v2011.2) Here is the backtrace obtained with GDB: 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007ffff340c253 in pyopencl::create_image_from_desc(pyopencl::context const&, unsigned long, _cl_image_format const&, _cl_image_desc&, boost::python::api::object) () from /usr/lib/python2.7/dist-packages/pyopencl/_cl.so #2 0x00007ffff342de36 in _object* boost::python::detail::invoke<boost::python::detail::install_holder<pyopencl::image*>, pyopencl::image* (*)(pyopencl::context const&, unsigned long, _cl_image_format const&, _cl_image_desc&, boost::python::api::object), boost::python::arg_from_python<pyopencl::context const&>, boost::python::arg_from_python<unsigned long>, boost::python::arg_from_python<_cl_image_format const&>, boost::python::arg_from_python<_cl_image_desc&>, boost::python::arg_from_python<boost::python::api::object> >(boost::python::detail::invoke_tag_<false, false>, boost::python::detail::install_holder<pyopencl::image*> const&, pyopencl::image* (*&)(pyopencl::context const&, unsigned long, _cl_image_format const&, _cl_image_desc&, boost::python::api::object), boost::python::arg_from_python<pyopencl::context const&>&, boost::python::arg_from_python<unsigned long>&, boost::python::arg_from_python<_cl_image_format const&>&, boost::python::arg_from_python<_cl_image_desc&>&, boost::python::arg_from_python<boost::python::api::object>&) () from /usr/lib/python2.7/dist-packages/pyopencl/_cl.so #3 0x00007ffff342e06f in boost::python::detail::caller_arity<5u>::impl<pyopencl::image* (*)(pyopencl::context const&, unsigned long, _cl_image_format const&, _cl_image_desc&, boost::python::api::object), boost::python::detail::constructor_policy<boost::python::default_call_policies>, boost::mpl::vector6<pyopencl::image*, pyopencl::context const&, unsigned long, _cl_image_format const&, _cl_image_desc&, boost::python::api::object> >::operator()(_object*, _object*) () from /usr/lib/python2.7/dist-packages/pyopencl/_cl.so #4 0x00007ffff311715b in boost::python::objects::function::call(_object*, _object*) const () from /usr/lib/libboost_python-py27.so.1.49.0 #5 0x00007ffff3117378 in ?? () from /usr/lib/libboost_python-py27.so.1.49.0 #6 0x00007ffff3120593 in boost::python::detail::exception_handler::operator()(boost::function0<void> const&) const () from /usr/lib/libboost_python-py27.so.1.49.0 #7 0x00007ffff3445983 in boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<pyopencl::error, void (*)(pyopencl::error const&)>, boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(pyopencl::error const&)> > >, bool, boost::python::detail::exception_handler const&, boost::function0<void> const&>::invoke(boost::detail::function::function_buffer&, boost::python::detail::exception_handler const&, boost::function0<void> const&) () from /usr/lib/python2.7/dist-packages/pyopencl/_cl.so #8 0x00007ffff3120373 in boost::python::handle_exception_impl(boost::function0<void>) () from /usr/lib/libboost_python-py27.so.1.49.0 #9 0x00007ffff3115635 in ?? () from /usr/lib/libboost_python-py27.so.1.49.0 Thanks for your help. If you are not able to reproduce this bug, I should mention it to debian. Cheers, -- Jérôme Kieffer Data analysis unit - ESRF

6 years, 9 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

PyOpenCL February 2014