Hi all,
Matthew Goodman reported (below) that PyCuda fails with CUDA 2.1 because nv
made a whitespace change in the cubin files they write. First of all, a change
like that shouldn't be able to take PyCuda down, so I've made sure that even
if metadata extraction fails, PyCuda doesn't throw weird-looking exceptions.
Next, I've fixed the actual bug along the lines of what Matt suggests. Since
this bug may turn people away from PyCuda unnecessarily, I've released 0.91.1.
Happy hacking,
Andreas
On Mittwoch 26 November 2008, Matt G wrote:
> I found a silly little bug you might wanna know about:
> Some nvcc builds generate "cubin" files that your regex fails to account
> for:
>
> The line:
> reg = 4
> (two spaces b/t 'reg' and '=' causes the:
>
> self.registers = int(re.search("reg = ([0-9]+)", cubin).group(1))
>
> to return a None and thusly crash ungracefully. Adding a strategic + to
> the regex seems to fix things:
> self.registers = int(re.search("reg += ([0-9]+)", cubin).group(1))
>
> I attached my "cubin" file so you can take a looksee.
>
> Thanks for the awesome tools.
> I am gonna be taking on some big CFD chores only possible by your help!
>
> Thanks.
> -Matthew Goodman
>
> ps
> nvcc --version
> Copyright (c) 2005-2007 NVIDIA Corporation
> Built on Fri_Nov__7_06:20:13_PST_2008
> Cuda compilation tools, release 2.1, V0.2.1221
>
> NVIDIA 260 GTX
On Mittwoch 26 November 2008, Derek Anderson wrote:
> i have not moved the cuda toolkit, but i did find the problem. i had
> used the ubuntu norm of instead of modifying my path, i had symlinked
> nvcc into /usr/bin. works find now that i switched it back.
>
> thanks!
> derek
>
> p.s. it is my understanding that nvcc always calls another compiler
> (for all the non-gpu compilation).
That's the weird bit: There's no non-GPU compilation in the case of PyCuda.
nvcc is always called with the --cubin option. All we get out is a GPU binary.
Maybe for preprocessing? Who knows.
Andreas
Hello,
I've been working with the tutorial on using pycuda for doubling an array.
As a project, I attempted to modify the code so that the size of the array
can be variable, mostly for the purpose of importing images. The functions
have been modified as follows:
mod = cuda.SourceModule("""
__global__ void doublify(float *a, int rows)
{
int idx = threadIdx.x + threadIdx.y*rows;
a[idx] += 2;
}
""")
.
.
.
func = (a_gpu, r_gpu, block=(4,4,1))
The idea is to pass an additional int variable into the function. However,
when I run the code I get an error telling me of an invalid type parameter,
as follows:
Traceback (most recent call last):
File "img_double_c.py", line 39, in <module>
func(a_gpu, r_gpu, block=(5,5,1))
File
"/usr/local/lib64/python2.5/site-packages/pycuda-0.91-py2.5-linux-x86_64.egg/pycuda/driver.py",
line 108, in function_call
handlers = func.param_set(*args)
File
"/usr/local/lib64/python2.5/site-packages/pycuda-0.91-py2.5-linux-x86_64.egg/pycuda/driver.py",
line 78, in function_param_set
raise TypeError("invalid type on parameter #%d (0-based)" % i)
TypeError: invalid type on parameter #1 (0-based)
Reading more of the documentation showed that only certain datatypes may be
passed into the module, none of which are of int type. Is there something
I'm missing here? If not, is there a way to pass variables (i.e. image
width and image height) into a SourceModule?
Brad Zima
Hi list members,
I asked Andreas a question about the following bug (unfortunately directly
by mail) :
>
/usr/local/lib/python2.5/site-packages/pycuda-0.91-py2.5-linux-i686.egg/pycuda/_driver.so:
undefined symbol: cuCtxPushCurrent
I installed just PyCuda, so I have never used it, and I get this message
when I want to import the driver. Cuda works. Andreas told me to do this :
ldd
/usr/local/lib/python2.5/site-packages/pycuda-0.91-py2.5-linux-i686.egg/pycuda/_driver.so
which gives the following result :
linux-gate.so.1 => (0xffffe000)
libboost_python-gcc42-mt-1_36.so.1.36.0 =>
/usr/local/lib/libboost_python-gcc42-mt-1_36.so.1.36.0 (0xb7e57000)
libcuda.so.1 => /usr/lib/libcuda.so.1 (0xb7ba8000)
libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb7a87000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7998000)
libm.so.6 => /lib/libm.so.6 (0xb7973000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7967000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7950000)
libc.so.6 => /lib/libc.so.6 (0xb781d000)
libutil.so.1 => /lib/libutil.so.1 (0xb7819000)
libdl.so.2 => /lib/libdl.so.2 (0xb7815000)
librt.so.1 => /lib/librt.so.1 (0xb780b000)
libz.so.1 => /lib/libz.so.1 (0xb77f8000)
/lib/ld-linux.so.2 (0x80000000)
in my /usr/lib folder I have also a symlink libcuda.so...but I don't know
if you were talking about this. Anyway it was said that I might have
somewhere an older driver module of Cuda. Ok, but where, and how I tell
PyCuda to use the new one?
Thanks in advance.
Peter
-------- Original Message --------
Subject: Re: pycuda Frage
Date: Mon, 24 Nov 2008 10:49:04 -0500
From: Andreas Klöckner <kloeckner(a)dam.brown.edu>
To: Peter Schmidtke <pschmidtke(a)mmb.pcb.ub.es>
Hi Peter,
a) schick' solche Fragen nächstes Mal besser an die Mailingliste.
b) Ich nehm' an, dass Du gegen CUDA 2.0 kompiliert hast, aber noch ein
altes
CUDA 1.1 Treibermodul (libcuda.so) rumliegen hast. Versuch mal
ldd /usr/local/lib/python2.5/site-packages/pycuda-0.91-py2.5-linux-
i686.egg/pycuda/_driver.so
Viel Erfolg,
Andreas
On Samstag 22 November 2008, you wrote:
> Hallo Andreas,
>
> ich bin sehr an Cuda interessiert, habe in C auch schon meine ersten
Tests
> gemacht und wollte nun PyCuda ausprobieren, was ja doch ein wenig
> unkomplizierter aussieht (danke für deine Arbeit ! ). Allerdings hab ich
> einige Probleme mit der Installation von PyCuda. Jetzt hat alles ohne
> Fehlermeldungen geklappt. Ich kann auch PyCuda importieren in python.
> Allerdings sobald ich das Treibermodul laden will bekomm ich folgenden
> Fehler :
>
> Traceback (most recent call last):
> File "test_driver.py", line 2, in <module>
> import pycuda.autoinit
> File
>
"/usr/local/lib/python2.5/site-packages/pycuda-0.91-py2.5-linux-i686.egg/py
>cuda/autoinit.py", line 1, in <module>
> import pycuda.gpuarray as gpuarray
> File
>
"/usr/local/lib/python2.5/site-packages/pycuda-0.91-py2.5-linux-i686.egg/py
>cuda/gpuarray.py", line 3, in <module>
> import pycuda._kernel as _kernel
> File
>
"/usr/local/lib/python2.5/site-packages/pycuda-0.91-py2.5-linux-i686.egg/py
>cuda/_kernel.py", line 1, in <module>
> import pycuda.driver as drv
> File
>
"/usr/local/lib/python2.5/site-packages/pycuda-0.91-py2.5-linux-i686.egg/py
>cuda/driver.py", line 1, in <module>
> from _driver import *
> ImportError:
>
/usr/local/lib/python2.5/site-packages/pycuda-0.91-py2.5-linux-i686.egg/pyc
>uda/_driver.so: undefined symbol: cuCtxPushCurrent
>
> sagt dir das etwas oder muss ich selbst weiter stöbern?
>
> Danke im Voraus
--
Andreas Kloeckner
Applied Mathematics, Brown University
http://www.dam.brown.edu/people/kloeckner
+1-401-648-0599
--
Peter Schmidtke
----------------------
PhD Student at the Molecular Modeling and Bioinformatics Group
Dep. Physical Chemistry
Faculty of Pharmacy
University of Barcelona
Hi,
I have installed PyCuda on this system and while the test driver runs
successfully i experience problems with mem_alloc_pitch.
I can allocate memory on the GPU with mem_alloc but when i am trying
to use mem_alloc_pitch i get the following traceback:
Traceback (most recent call last):
File "cudamatch.py", line 183, in <module>
query_dev, query_pitch = cuda.mem_alloc_pitch(query_width*sof,
query_height, sof)
TypeError: No to_python (by-value) converter found for C++ type:
cuda::device_allocation
Is this a problem with my installation or a missing feature in the
code? My system is configured as follows: OSX 10.5.5, Python 2.5.1,
Ctags 5.7, boost-1_37, gcc 4.0.1
Kind regards,
Nicholas
Hi all, I've just subscribed this mailing list, I've seen several
messages on pycuda and errors in linking libraries on OS X.
I've seen that many libraries in /usr/local/cuda/lib are installed in
wrong way. Instead of changing your DYLD_LIBRARY_PATH it is better to
fix linking with the "install_name_tool" command. As example consider
libcufft.dylib:
$ cd /usr/local/cuda/lib
$ otool -L libcufft.dylib
libcufft.dylib:
@rpath/libcufft.dylib (compatibility version 1.1.0, current version
2.0.0)
@rpath/libtlshook.dylib (compatibility version 1.1.0, current version
2.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.0.0)
@rpath/libcudart.dylib (compatibility version 1.1.0, current version
2.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
the first step is changing the ID for this library (the first entry in
the list):
$ sudo install_name_tool -id /usr/local/cuda/lib/libcufft.dylib
libcufft.dylib
after that:
$ otool -L libcufft.dylib
libcufft.dylib:
/usr/local/cuda/lib/libcufft.dylib (compatibility version 1.1.0,
current version 2.0.0)
@rpath/libtlshook.dylib (compatibility version 1.1.0, current version
2.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.0.0)
@rpath/libcudart.dylib (compatibility version 1.1.0, current version
2.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
the id is now correct. The next step is changing the linking for all
wrong entries (i.e. the ones with @rpath/libname...):
$ sudo install_name_tool -change @rpath/libtlshook.dylib /usr/local/
cuda/lib/libtlshook.dylib libcufft.dylib
$ sudo install_name_tool -change @rpath/libcudart.dylib /usr/local/
cuda/lib/libcudart.dylib libcufft.dylib
$ otool -L libcufft.dylib
libcufft.dylib:
/usr/local/cuda/lib/libcufft.dylib (compatibility version 1.1.0,
current version 2.0.0)
/usr/local/cuda/lib/libtlshook.dylib (compatibility version 1.1.0,
current version 2.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.0.0)
/usr/local/cuda/lib/libcudart.dylib (compatibility version 1.1.0,
current version 2.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
Now this library has been fixed. You have to repeat this for all
libraries that are wrongly linked.
HTH
d
---
Davide Cittaro
daweonline(a)gmail.com
http://daweonline.googlepages.com
hey all,
i've compiled and installed pycuda just fine w/:
$ cat siteconf.py
BOOST_INC_DIR = ['/usr/include/boost/']
BOOST_LIB_DIR = ['/usr/lib']
BOOST_PYTHON_LIBNAME = ['boost_python-mt-py25']
CUDA_ROOT = '/usr/local/cuda/'
CUDA_INC_DIR = ['/usr/local/cuda/include']
CUDADRV_LIB_DIR = ['/usr/local/cuda/lib']
CUDADRV_LIBNAME = ['cuda']
CXXFLAGS = []
LDFLAGS = []
but when i tried to run test_driver.py i got this:
$ python test/test_driver.py
cc1plus: error: cuda_runtime.h: No such file or directory
E.cc1plus: error: cuda_runtime.h: No such file or directory
Ecc1plus: error: cuda_runtime.h: No such file or directory
E.Ecc1plus: error: cuda_runtime.h: No such file or directory
Ecc1plus: error: cuda_runtime.h: No such file or directory
Ecc1plus: error: cuda_runtime.h: No such file or directory
Ecc1plus: error: cuda_runtime.h: No such file or directory
E
[...] # every test fails
to fix it i exported "CPLUS_INCLUDE_PATH=/usr/local/cuda/include/" and
"C_INCLUDE_PATH=/usr/local/cuda/include/", and it worked.
so, my question is, is this something that i missed in the docs
somewhere? or, why did the "CUDA_INC_DIR" setting not get picked up?
thanks,
derek
After pycuda install on Macbook Pro Intel, NVidia 9600M GT,
with EPD 4.0.30002 python distribution from Enthought and
Mac OS X 10.5.5, I get the following error:
$ python ./test_driver.py
Fatal Python error: Interpreter not initialized (version mismatch?)
Abort trap
pycuda is from git. I installed boost two ways, 1.37 as
described in the pycuda docs and 1.35 using MacPorts. There
were no errors reported in the build process. My
{DY}LD_LIBRARY_PATH seems to be correct (otherwise, I would
get the same runtime errors as another post). Running the
numpy and scipy test suites returned no errors. CUDA is 2.0
downloaded from nvidia's site.
Here is one of my siteconf.py (adapted from post by wohlegemuth):
BOOST_INC_DIR = ['/opt/local/include/boost-1_35']
BOOST_LIB_DIR = ['/opt/local/lib']
BOOST_PYTHON_LIBNAME = ['boost_python-mt-1_35']
CUDA_ROOT = '/usr/local/cuda'
CUDADRV_LIB_DIR = ['/usr/local/cuda/lib']
CUDADRV_LIBNAME = ['cuda']
CXXFLAGS = ['-arch', 'i386']
LDFLAGS = ['-arch', 'i386']
I am unfamiliar with Mac OS, my 2nd day. A response to an earlier
post by Evan Wies suggested a fix if python was installed
using MacPorts. Does it apply here as well with EPD?
Thanks.
Hi,
PyCUDA looks great, thanks for making this great tool.
For some reason, the search in sphinx docs is broken. It finds stuff,
but the links omit the .html part of the url because line 13 in
search.html reads:
FILE_SUFFIX: ''
it should read:
FILE_SUFFIX: '.html'
I actually didn't have to make any changes to the docs in git when
building with the latest sphinx from their mercurial repo.
if updating sphinx isn't an option, you can try applying this patch:
diff --git a/doc/source/conf.py b/doc/source/conf.py
index bf9de5b..d49e756 100644
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -126,7 +126,7 @@ html_last_updated_fmt = '%b %d, %Y'
#html_use_opensearch = ''
# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
-#html_file_suffix = ''
+html_file_suffix = '.html'
# Output file base name for HTML help builder.
htmlhelp_basename = 'PyCudadoc'
...also, I all of the test I've tried so far seem to run fine for me,
except for test_driver.py, where I get this:
$ python test_driver.py
.....E....
======================================================================
ERROR: test_mempool (__main__.TestCuda)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_driver.py", line 239, in test_mempool
queue.append(pool.allocate(1<<e))
MemoryError
----------------------------------------------------------------------
Ran 10 tests in 0.218s
FAILED (errors=1)
I don't claim to understand what the test is supposed to be, but given
that it's a bit-shifting operation, I thought maybe it's an endian
issue, and the test passes for me (on x86-64) with the shift going in
the other direction like so:
diff --git a/test/test_driver.py b/test/test_driver.py
index 907bb49..802e10e 100644
--- a/test/test_driver.py
+++ b/test/test_driver.py
@@ -236,7 +236,7 @@ class TestCuda(unittest.TestCase):
for e in range(e0-5, e0-3):
for i in range(100):
- queue.append(pool.allocate(1<<e))
+ queue.append(pool.allocate(1>>e))
if len(queue) > 10:
queue.pop(0)
cheers,
Paul Ivanov
