PyCUDA February 2017

pycuda@tiker.net

5 participants
6 discussions

by Chris

Hey Andreas, I am having a similar issue that Kambiz Tavabi was having. Here is the error (I have pycuda on anaconda2 just like Kambiz) File "main_class.py", line 17, in <module> import pycuda.gl as cuda_gl File "/home/uchytilc/anaconda2/lib/python2.7/site-packages/pycuda-2016.1.2-py2.7-linux-x86_64.egg/pycuda/gl/__init__.py", line 2, in <module> import pycuda._driver as _drv ImportError: /home/uchytilc/anaconda2/lib/python2.7/site-packages/pycuda-2016.1.2-py2.7-linux-x86_64.egg/pycuda/_driver.so: undefined symbol: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev The weird thing is that I have some files that are having this problem and some that are not, with identical import statements. import sys from OpenGL.GL import * from OpenGL.GLUT import * from OpenGL.GLU import * from OpenGL.GL.ARB.vertex_buffer_object import * from OpenGL.GL.ARB.pixel_buffer_object import * import pycuda.gl as cuda_gl import pycuda.driver as cuda_driver The files that are experiencing this issue are all files that run this import statement right at the top in the main.py file, the one I initialize from. The one that doesn't hit this error has the import statements in a second file that is being imported with an __init__.py file. Not sure if this is pure coincidence or not but I figured it was worth bringing up. -- View this message in context: http://pycuda.2962900.n2.nabble.com/undefined-symbol-error-tp7575758.html Sent from the PyCuda mailing list archive at Nabble.com.

4 years

Installation on Ubuntu 14.04

by Guillaume Androz

Hi, I'm trying to install pyCuda 2016.1.2 on Mint 17.3 (same as Ubuntu 14.04), I follow the procedure found at https://wiki.tiker.net/PyCuda/Installation/Linux/Ubuntu, but I keep having the same error In file included from src/cpp/cuda.cpp:1:0: src/cpp/cuda.hpp:14:18: fatal error: cuda.h: No such file or directory #include <cuda.h> ^ compilation terminated. error: command 'gcc' failed with exit status 1 make: *** [all] Error 1 >> echo $PATH /usr/local/cuda-8.0/bin:/usr/local/bin/anaconda/bin:/usr/local/bin/anaconda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games >> echo $CUDA_ROOT /usr/local/cuda-8.0

4 years, 1 month

Re: [PyCUDA] CUDA driver compute mode

by Andreas Kloeckner

Kambiz Tavabi <ktavabi(a)uw.edu> writes: > Following TB from test_driver.py with 2016.1.2 build on OS X 10.11 with > CUDA 8 V8.0.61; was able to workaround by changing > > if drv.Context.get_device().compute_mode == drv.compute_mode.*EXCLUSIVE*: > > to > > if drv.Context.get_device().compute_mode == drv.compute_mode. > *EXCLUSIVE_PROCESS*: > > in test_dirver.py > > Is this expected? Fixed in git, but not yet released: https://github.com/inducer/pycuda/commit/255644ad802a20191e31bc15f4fd46e6c9… Thanks for the report, Andreas

4 years, 1 month

CUDA driver compute mode

by Kambiz Tavabi

Following TB from test_driver.py with 2016.1.2 build on OS X 10.11 with CUDA 8 V8.0.61; was able to workaround by changing if drv.Context.get_device().compute_mode == drv.compute_mode.*EXCLUSIVE*: to if drv.Context.get_device().compute_mode == drv.compute_mode. *EXCLUSIVE_PROCESS*: in test_dirver.py Is this expected? ________________________ TestDriver.test_multi_context _________________________ args = (<test_driver.TestDriver instance at 0x10fa18dd0>,), kwargs = {} pycuda = <module 'pycuda' from '/Users/ktavabi/anaconda2/lib/python2.7/site-packages/pycuda-2016.1.2-py2.7-macosx-10.5-x86_64.egg/pycuda/__init__.pyc'> ctx = <pycuda._driver.Context object at 0x10e9a59b0> clear_context_caches = <function clear_context_caches at 0x10dc52e60> collect = <built-in function collect> def f(*args, **kwargs): import pycuda.driver # appears to be idempotent, i.e. no harm in calling it more than once pycuda.driver.init() ctx = make_default_context() try: assert isinstance(ctx.get_device().name(), str) assert isinstance(ctx.get_device().compute_capability(), tuple) assert isinstance(ctx.get_device().get_attributes(), dict) > inner_f(*args, **kwargs) ../../../anaconda2/lib/python2.7/site-packages/pycuda-2016.1.2-py2.7-macosx-10.5-x86_64.egg/pycuda/tools.py:460: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <test_driver.TestDriver instance at 0x10fa18dd0> @mark_cuda_test def test_multi_context(self): if drv.get_version() < (2,0,0): return if drv.get_version() >= (2,2,0): > if drv.Context.get_device().compute_mode == drv.compute_mode.EXCLUSIVE: E AttributeError: type object 'compute_mode' has no attribute 'EXCLUSIVE' test_driver.py:638: AttributeError =============== 1 failed, 25 passed, 2 skipped in 37.73 seconds ================ ------------------------------------------------------------ Kambiz Tavabi PhD Institute for Learning & Brain Sciences 1715 Columbia Road N Portage Bay Building Box 357988 University of Washington Seattle, WA 98195-7988 Tel: 206-685-6173 ------------------------------------------------------------ *Confidentiality Notice: Because email is not secure, please be aware that we cannot guarantee the confidentiality of information sent by email. If you are not the intended recipient of this email, please notify the sender by reply email, and then destroy all copies of the message and any attachments.*

4 years, 1 month

Re: [PyCUDA] [PyOpenCL] New architectures for PyOpenCL in Debian

by Tomasz Rybak

On Mon, 2017-02-13 at 10:24 +0000, Vedran Miletić wrote: > Tomasz, > > half a year ago there was one person who came to #radeon on Freenode > and talked about open source radeon driver stack almost working on > ppc64 (I have no information whether the bugs have been addressed > since, but I would presume they have). Would it be possible to > provide ppc64 package for PyOpenCL as well? > In theory it's possible. But according to Debian Policy 2.2.1 package must not require software not present in Debian for execution. https://www.debian.org/doc/debian-policy/ch-archive.html#s-main Currently there is no OpenCL ICD for ppc64 in Debian - so I cannot upload PyOpenCL for that architecture. It would be much easier to just build PyOpenCL for all architectures, but to be following Policy I need to manually maintain list of architectures for which we have ICDs. Best regards. -- Tomasz Rybak, Debian Maintainer <tomasz.rybak(a)post.pl> GPG: A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak

4 years, 2 months

Re: [PyCUDA] [PyOpenCL] New architectures for PyOpenCL in Debian

by Tomasz Rybak

On Mon, 2016-11-21 at 22:46 -0600, Andreas Kloeckner wrote: [ cut ] > At the same time I have a question for you Andreas. There will be > > freeze of Stretch on 2017-01-05. I’d like to upload PyOpenCL and > > PyCUDA > > in mid-December, and those versions will be versions for Stretch. > > Do > > you plan new releases, or should I just take snapshots from git? > > I'll do a 2016.2.1 mid-December. > Quick update. PyOpenCL from 2016-11-30 (commit 19015994653dffe2ee407271e19a46e1d6a62796) is in Debian testing, for architectures amd64, arm64, armhf, i386, and amd64 and i386 for kFreeBSD. There is no release-critical errors against it which means that this version of PyOpenCL should be in Debian Stretch. As for PyCUDA, the version in Debian is from 2016-10-24, commit 50457813cfe3eb359a230c4e1e546ccdef9947f8. It's only available for amd64. I tried to build package for ppc64el, but wasn't able to properly configure cross-compiler. As Debian is in deep freeze now, I won't upload new versions of packages Stretch release. Using this time I'll try to make ppc64el PyCUDA - but it's not something I'll focus on entirely. If you have questions or suggestions regarding packages, please let me know. Best regards. -- Tomasz Rybak, Debian Maintainer <tomasz.rybak(a)post.pl> GPG: A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak

4 years, 2 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

PyCUDA February 2017